An Outsiders View of Agile Software Development - Part One

Happy to publish this guest post. 

Joe Woods is one of the top SEO and Internet Marketing Specialists in the Southeast US and has worked with Agile and Scrum since 2007. Joe currently works with Version One and many of the industry’s leading Agile coaches to help IT teams and practitioners evangelize the many different process from Agile, Scrum, XP and Kanban.


This is my view of the agile software development process from an outsider’s perspective. Now I’m no agile expert, far from it actually. I was always told that we’re an agile shop or that we use waterfall (cringe). Ok, that’s fair enough. All that meant to me was that we do releases every couple weeks or weekly and I have to go to a bunch of team meetings. I also would have to write these things called stories and they couldn’t be too broad and being too narrow meant I missed some functionality. It always seems to be the case that the last place I worked did it wrong, so I always had to learn another way to write a story, how to assign points, and what I had to do to accept or reject a story. Not a big deal once you learn what’s expected.
Now, I’ve been in the internet marketing space for about 10 years now and have had the opportunity to work for many different companies from small start-ups to Fortune 100’s. I’ve had to wear many different hats in this time. Sometimes I was the marketing jack-of-all trades, other times I was the SEO guy, and more recently the consultant/project manager/product manager, slash this or that. Basically, I’ve always been a stakeholder in agile terms. I’ve worked in agile shops, waterfall shops and shops where there is no process. My job success has always been measured by how far I can take the business from points A, B, C and D. It’s vitally important that I get some quick wins starting out to prove my worth and then continue to move the ball or move the needle or get to the next level. Speed and buy-in are always a factor, results are a must, and time is of the essence.
Waterfall versus Agile
Working in a waterfall shop usually meant that I had to spell out all requirements for a typical request, bug, or functionality in great detail. All requirements had to be included and every detail accounted for. I find breaking it down to a very basic level seems to work best here without insulting anyone. Drawing a picture and placing arrows seem to work best to get the point across. Then everything had to go through a vetting process and get signed off multiple times. Waterfall releases were always planned months in advance and pretty much set in stone. This meant that if I started with a company right at the beginning of the new cycle, which always seemed to be the case, then I had months of waiting to get anything done. Even the simplest change took an act of God to make happen, if it were to happen mid-cycle or in the next release. Well, that’s never a good thing as mentioned above and I always knew it was a matter of time before I was gone. Later, I would watch my requests get worked in and the site become successful as a result. This is more of an issue with impatient management and managing expectations on my part than the process itself, but I think it points out the inefficiencies with Waterfall project management.
Fast forward to agile development success. I have to say that I really like agile much better. The reason I like it better is simple: speed. We have more releases which mean I can effect marketing changes and web changes much faster. Sprints can be planned out months in advance as well, but most times they are only planned a release or two ahead. There is also some flexibility in adding additional stories to the queue. So for me, getting a couple stories placed in a sprint or added if the points are available is always a good thing. Marketing things get done faster, numbers come in faster and everyone is happy. More importantly, I get to keep my job. However, agile isn’t without its quirks either.

IdeaPaint– A new dimension to Agile Workspace

Big Visible Charts, and collaborative environment are the distinct characters of Agile workspaces. Many researches have clearly indicated that visibility of information, posture of people and flexibility are the critical elements to enhance creativity. If you are interested to know more about how to improve creativity through a proper design of workspace, read the article here.

In my world, here is how we have used some tools in the past, and at the end, I have made an attempt to predict the future.

Past and present
Depicting/Sharing ideas has evolved over years.

1. We started with the black boards	2. Before moving to Flipcharts
3. To avoid marks on the walls, people paste the Post-Its on A3 sized sheets	4.Many teams use Glass walls to sketch thoughts
5. Cling on sheets was one of the effective ways to move notes from one room to another without scratching walls

The future

Nowadays,  many new organizations  have started making use of this innovative technology called “IdeaPaint”. 

According IdeaPaint’s website:



Titled IdeaPaint, it is available for half the price of an actual whiteboard and works just as well or better, leaving no marks behind when you wash down your work (and, without the rest of the infrastructure, it turns out to be greener, too).

Imagine the ability to write ideas, thoughts, designs and release plan on the white walls without getting worried about the office admin.

 

If you are a truly Agile enterprise, it is high time to move towards IdeaPaints. I am convinced that, IdeaPaint is going to revolutionize the way people collaboratively work.

Here are few sample pictures of how people use IdeaPaint.

Watermelon Agile

We have heard about ScrumBut and Water Scrum Fall. On similar lines, I thought I would coin another term “Watermelon Agile”.

As we know, watermelon has green outside, and red inside. Similarly, the “Watermelon Agile” projects too show a greenness of Agile outside, however, they would still be “red” inside stuck with Waterfallish mentality.


Some of the Watermelon Agile practices include:

1. They will do Daily Stand ups,   but  team members are forced to do it.  It won’t stop there, blockers are screened before it goes to the blocker wall.

2. They will set up beautiful Kanban walls, but only to satisfy Agile coach or the management, who treat setting up Kanban walls means “Agile”.

3. The Scrum Master still drives the project in command and control mode. Some examples include, asking the team members to report to work at a certain time, micro-managing the team, cultivating blame-game culture within the team.

4. They will still do retrospectives, but team members have fear to expose anything negative about the project.

5. Team members are punished for doing any mistakes. This behaviour automatically pushes the team not to try new things, and in turn the project ends up with no innovation.

Do you know of any other Watermelon Agile practices ?

How to be an effective Scrum Master by understanding the Ego states

We are our behaviours, thinking and experiences. Wherever we go, we carry all our emotions and personality with us.  A question, do  you agree that the way we speak, deal with others are influenced by our past ?

Sarah Taraporewalla of Thoughtworks talked about different personality types, their impact on areas like communication and relationship with our colleagues at work.  She presented this topic during Agile Australia 2012 event, a few weeks ago.

She also explained some of the topics like Iceberg principle, TA and positions using her own example as Scrum Master and Agile coach. 

Transactional Analysis(TA) describes how people are structured psychologically. It uses what is perhaps its best known model, the ego-state (Parent-Adult-Child) model, to do this. 

Eric Berne, founder of Transactional Analysis, believed that each of us have 3 ego states (our Parent, Adult and Child). This is also called PAC model.

The Parent ego state is comprised of the behaviours, thoughts and feelings copied from our parents, or other parental figures.  The person with the Parent ego state will spend most of the time giving guidelines.  

Adult. 'Adult' describes our ability to think and determine action for ourselves based upon the 'here and now'. 

Child. This is the ego state in which individuals behave, feel and think similarly to how they did as a child. Person with Child ego is very emotional.  Could cry or get angry easily.  People storming out of the meetings, crying when you give a feedback are good examples of a person with Child ego state.

By being in Adult ego state, one could control both the parent and child ego state people. 
If you are a Scrum Master or a coach, you could observe the conversations between people, and understand their state.  Using the PAC model effectively, one could use appropriate communication mechanism to not only get the work done but also to maintain relationships.

During one of the feedback meetings, the employee I was chatting with started crying. I understood that, she is in the “Child” ego state. As stated earlier, one needs to be in Adult state to manage Child and Parent egos. Being in Adult ego implies, I need to be non threating (Physical posture), and should be in state of enquiry.

Sarah also recommended following books to learn more about Psychology

References:
Understanding PAC model
Transactional Analysis

How to choose a right Agile coach ?

I am sure you agree that no one is born as an Agile coach. People chose coaching profession based on their strengths. Knowing that, there is a great demand for Agile coaches nowadays, it is always beneficial to understand their journey. Finding an Agile coach is not so difficult, however finding a right one is.

After observing coaches since several years, I found a pattern among their journey. The following pattern could be used as a framework to identify a phase an Agile coach belongs to. If you believe they belong to first two phases, then it is recommended to have a Pragmatic coach to support them.



1. Novice phase: As the name implies, new to Agile coaching and diligently follows every step learnt from the past. Very eager to learn new facilitation techniques, and attends all the new training programs, conferences without fail. Very enthusiastic and very vocal about Agile methods in the company.

2. Passionate phase: I understand that, being passionate about something is always good. It carries a lot of good energy, but on the flipside, it could make one blind to the different/better options available.
This phase for an Agile coach is like being a teenager in life, a bit reckless.

During this phase, coach continues to carry a big Agile hammer around all the time. As the saying goes “When you are a hammer, everything looks like a nail”. Whether the customer needs a particular practice or a methodology, the coach will go ahead and push the customer to practice them.
As and when the coach comes across something new, he/she wants to put that into practice immediately on the projects. The coach in this phase strongly believes that Agile/lean practices are silver bullets, which in reality are not.


3. Pragmatic phase: Coach has spent several years working on small/medium and large scale projects. Has gained enough experience working with different clients solving challenging problems. Good thing is, It is easier to identify a pragmatic coach. When you meet one requesting for help, he/she won’t tell you to go, and apply Scrum or Kanban or any popular practices. They would encourage interviewing the key stakeholders,they will also try to understand the issue from an enterprise level before suggesting any solution. These coaches will try to understand the root cause, and provide solutions accordingly.

As I said before, finding the right Agile coach matters. Coaches could influence the bottom line of the company, and having more pragmatic coaches who are not carried away with the hype are always beneficial.

Value and Culture over practices and processes

On Day 1 of Agile Australia,  Sandra Dalli  and Sarah McAllister of Bank West shared their experiences adopting Agile at  BankWest.  BankWest is into the beginning of their 3rd year of its Agile adoption and bringing Agile into the organisation has involved so much more than delivering Agile projects.

During this session, the speakers shared not only their success but their failures during the journey of Agile adoption.  One needs to appreciate the fact that, they didn’t paint a rosy picture saying their journey was easy.  One of the triggers for the bank to adopt Agile was the massive failure on a water fall project. The team on the waterfall project spent several months writing requirement specifications and design documents burning the project budget, and at the end realizing there is no money to build the software.

Before sharing their journey, let me share my experiences of Agile adoption in large organizations.

Based on my past experience, an organization goes through the following phases during Agile adoption. As shown in the picture below, there are 3 key phases. 

1. Learning and Experimentation
2. Initiation
3. Matured 

The details of these phases are explained below mapping BankWest experience.

1. During Learning and Experimentation phase, the enterprise typically takes following actions to initiate the Agile adoption:

             a. Identifying a point of contact to run the Agile show
             b. Form a team or group to drive Agile related activities
             c. Hire or get Agile coaches on contract
             d. Create training programs and start enrolling employees into this
             e. Start one or more pilot projects and experiment applying Agile methods

BankWest went through steps similar to one mentioned above ending this phase successfully. Another key reason for their success so far is the support from the top management. I could clearly see that they had applied Top-Down Agile adoption  strategy.

When the speakers were given the baton to start Agile adoption 3 years ago, they spent nearly three months going through various websites, and documents researching everything about Agile. They also wrote a lengthy manual for everyone to read, which they made fun of as they realized later that this is not the right way. 

Regarding Agile coaching, I think they took help from Lonely Planet.

2. The initiation phase is all about embracing Agile as much as possible.  The BankWest speakers shared the way they brought testers and developers collocated as part of their journey. They were serious in bringing Agility to their company, and they followed every recommendation given in Agile books and ones shared by Agile coaches.  

As we know, implementing a new practice or skill across organization takes anywhere between few months to years. It is always recommended that new practices should be encouraged to be adopted incrementally than in a big bang way.  

Incremental learning
BankWest took 5 practices(Daily stand up, retrospective, showcases, etc)  as priority and encouraged all teams to practice only one at a time for a month, before moving onto the next one. At the end of 5 months, they saw most of the projects well versed with some of them.  The entire organization was amazed to see this transformation happening in front of their eyes.  

Read more about Agile adoption phases and the J-Curve effect here

Currently BankWest seems to be at the end of this phase.

3. Matured Phase: During this phase, pretty much all the infrastructure needed to do Agile projects should be available handy.  Matured Enterprises start looking at Agile adoption beyond software delivery, and starts including HR, Finances, etc.  Some of these activities could be started during the second phase itself depending on the size and maturity of the organization.

During the conference, I listened the journey of BankWest, NAB and other companies. My own experience of Agile transformation in past companies combined with this clearly shows that, there is no secret recipe to succeed in the journey of Agile adoption. Every company has it’s own culture and DNA. Don’t try to copy set of practices of another company with the hope that you would succeed. 

Every organization has to invent and carve a path for themselves. Teams will fail many a times. However, as long as they are learning from their mistakes, they should be encouraged and supported in their journey.   One thing is clear, identifying the right group of people to steer the journey, and hiring good Agile coaches during the beginning makes a lot of difference. 

How to build a high performing Agile team ?

 

Building a high performing team is a dream of every Agilist. Agile Australia event had a track on this topic too.  Mike Bromley of NBN covered this topic on Day 1 of the event.  As part of building a high performing team, the first step is to hire talented people.  According to Mike,

                   Culture is a driving force behind performance, and people = culture.        

He also mentions that 9 key traits of a good performer. I have put together the traits in the screen shot below.

As one could see, it is difficult to find all the talents in one single person. One needs to carefully chose people so that, they complement each others skill. Some of the talents mentioned above(courage, innovation,etc) cannot be identified using the typical interviewing (Q&A) technique. Special techniques are needed.

Here are some of the special techniques

• Microsoft interview process
• SOARA technique
• Uncovering soft skills
• Interview beyond technical skills
• Different interviewing techniques

Agile Australia 2012– Successful event

 

Two days of Agile Australia 2012  ended last week. The organizers had put a lot of effort in making this event a success.  The key notes on both the days were inspiring, and the topics during the event not only touched upon Agile methods, but also included  leadership and case studies from various companies. 

Food was good by the way, the weather wasn’t bad. Since the venue was within Melbourne city, the commute was easy.

I would be summarizing some of the learning in the next few blog posts.

Agile Australia 2012

 

Looking forward to attend the Agile Australia sessions starting tomorrow.  Looks like the venue is running with full capacity with conference tickets sold out.  

We have so many good tracks running in parallel, and it is making me difficult to decide the sessions.

Feel free to follow the conference using the Twitter hash-tag  #Agileaus.

Litmus test for an Agile company : practicing Sustainable pace

 

      Nowadays with the advent of  blackberries and smartphones, the work hours are no more restricted to 9 to 5.  These devices can download emails any time any where, and in turn has enabled professionals to work as per their wish. 


According to a recent survey by Neverfail, a software company specializing in data protection,

83 % of professional workers say they check email after work. 
66 % take a smartphone or laptop with them on vacation and
more than 50 % report that they send emails or texts during a meal with family or friends.

It is obvious that checking work related emails at home carries the mental pressure associated at work to private life.  This in turn has triggered more questions than answers. They are..

is this a healthy way of living/working ?    
Should an individual take responsibility to balance work and life ?  
Is there a role that an organization can play here, if so, do they get any benefit out of it ?

Even though the individual has a key role in finding their own work/life balance, I feel that employers have an equal role to play as well in this era of globalization.    Let me share a few researches to support this idea.

Firstly, according to a study by Dov Eden of Tel Aviv’s University’s, 

Employees who feel compelled to be at the beck and call of work at all times are unlikely to recover from the ill-effects of chronic job stress. This is a causal chain that eventually gets internalized as psychological and behavioural responses that can bring on serious chronic disease.

The employees checking emails during their vacation, will come back to work to get burned out more rather than a relaxed vacation. Burned out employees in turn are less efficient and less productive draining companies resources.

Secondly, as per the famous Predictable time off experiment conducted by BCG, the consultants who had time off felt happier and better at their jobs than those who did not. They were also more efficient. One of the teams that participated in this experiment decreased its average workweek from 65 to 58 hours while accomplishing essentially the same amount. Isn’t this more efficient for the company ?     Today, BCG teams that join the predictable time off program meet regularly to work out schedules so that every member can take an official break from e-mail one night each week, not including weekends.

Keeping in mind some of the above mentioned issues of  workers getting burned out, Volkswagen has programmed its e-mail servers to stop sending messages to many of its German employees after their shifts end.  Isn’t this a good move by such a large company to help their employees and in turn themselves ?

eXtreme Programming(XP) introduced Sustainable pace a long ago. Now it is turn for the truly Agile companies to introduce  programs like Predictable time off, shut down email servers during the weekends to help employee burn out and improve the productivity.  I truly believe that supporting the idea of Scrum or XP or Kanban is not going to make a company Agile, but introducing above ideas is the true litmus test for an Agile company.

New Skills for the Agile Team

Agile development teams live and die by their code. Many have found in practice that “good” agile code is extensible, low-defect code with the simplest robust design that will work for the features currently implemented. Among the agile methodologies, Extreme Programming (XP) goes into the most depth concerning how programmers can keep themselves and their code agile. Below are some new skills that agile teams need to embrace.

Simple Design

Agile teams are under pressure to deliver working, tested code at the end of each iteration and their code must be capable of turning on a dime at any moment. So agile teams place enormous value on the extensibility of their code: the extent to which they can easily maintain and extend it. The other key component of extensibility is design simplicity. Extensibility seems to be inversely proportional to design complexity.

Refactoring

Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Agile teams are maintaining and extending their code a lot from iteration to iteration, and without continuous refactoring, this is hard to do. This is because un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, way too many responsibilities per method or class, duplicate code and many other varieties of confusion and clutter.

Breaking Down Work

Agile methods promote taking large projects and breaking them down into a coordinated series of smaller projects developed by smaller, cross-functional teams. The various teams’ work (i.e. code) is integrated at least every iteration in order to reduce risk and ensure functional and technical compatibility.

Continuous Planning

An incremental approach to planning allows for initial planning at a high level, and iterative planning at lower levels as more knowledge is gained. As teams begin to learn what they can deliver on a daily, weekly and monthly basis, they become more accurate at both their short- and long-term planning abilities than they ever were with traditional planning approaches.

Providing Input

Collaborative decision-making techniques are important because agile requirements definition involves more than just the Business Analyst and the Product Owner. Agile encourages input from all team members to create a more robust solution that meets the needs of the business and helps create a strong sense of confidence that the solution can be delivered to market.

These are just a few of the new skills agile teams need to embrace. Learn more about other Agile Programming Practices.

7 tips to hire and manage Agile coaches

Large organizations transitioning towards Agile take the first step of hiring Agile coaches.  Many business leaders would be under pressure to hire one as quickly as possible to speed up the process of Agile transformation. Many a times, due to this pressure, they end up making a mistake, hiring a wrong one. 

Based on my past experience working with large organizations and different coaches, I have put together the following 7 points to help business in making good decisions.

1. Try working with 2 or 3 coaches before finalizing one.
2. If you are planning a short term consulting role from a coach, then hire some one who has already built a good credibility as a coach. You may not have enough time to experiment.
3. Ensure to have only one Agile coach on a project.  Having 2 or more could end up wasting time/resources, as two Agile coaches rarely agree, especially if they are from different companies.
4. Ensure, coaches have skin in the game.
5. Ensure that Agile coaches know how to use available tools/technologies rather than just hung up on using Post-It notes.  Let me share my own experience working with one of the best Agile coaches Craig Larman.   While working with Craig, I noticed that, he not only used  Post-it efficiently,   Craig encouraged us to use different tools like  Cling-on sheets, White boards, Flip-charts, Projectors,etc.  Many Agile coaches nowadays don’t think beyond post-it notes.
6. I have observed that newbie-coaches who are on contracting roles tend to buckle up under organizational pressure. They may not push for changes to happen. An Agile coach who fearlessly pushes for transformation is better.
7. If you have hired an Agile coach, then observe the coach during their assignment for few days to understand their areas of strength.
   
   

Top 3 Myths of Agile Development

 

Agile development is an umbrella term for a number of iterative and incremental software development methodologies such as Scrum, Extreme Programming (XP), Lean and Kanban. With agile, all aspects of software development – planning, designing, coding, integrating and testing – are combined in short, frequent iterations.

Agile software development is not a silver bullet, but it has forced many to rethink traditional approaches to software development and apply new ideas and techniques in an effort to build better software faster. As with any significant industry shift, a tremendous amount of fear, uncertainty and doubt generally accompany the transition.

Myth 1: Agile development is undisciplined, cowboy coding.

Fact: Continuous delivery of running, tested software every few weeks could be characterized as the ultimate software industry discipline.

Myth 2: Agile development isn’t predictable.

Fact: Agile teams are constantly planning, prioritizing and delivering against the plan and have a much better sense of where the project actually is and what can be accomplished.

Myth 3: Agile development is just another fad.

Fact: Many industry leaders have embraced and promoted agile. Agile adoption has moved from small co-located teams to large divisions and software organizations of enterprise IT.

What’s Hot: Agile Development

· Teams constantly delivering benefit to the organization every quarter, month, week or even day

· Small, cross-functional teams that communicate and collaborate on an on-going basis

· Planning projects upfront at a high level with detailed planning happening throughout the project to efficiently adapt to change

· Using historical information to plan work incrementally and predict progress

· Quality software is always ready to be delivered

What’s Not: Traditional Software Development

· Teams delivering new features once or twice a year and often missing release dates

· Large teams that meet infrequently and are too big to have meaningful collaboration

· Extensive, up-front planning crammed into the beginning of a project that doesn’t account for inevitable change

· Using speculation to plan all work upfront and “predict” progress

· Passable software is delivered late

Learn about more myths of agile development.

Does a Scrum Master need technical or functional background ?

 

Do you expect your Scrum Master to understand  Java coding standards ?  Should the Scrum Master have a deep understanding of  differences between the four products the customer is building ?

There are people supporting the idea of Scrum Masters with strong knowledge in technology/programming skills. I feel that, knowing a specific subject whether it is technical or functional is never going to hurt. However, in the context of being a Scrum Master, I strongly believe that it is not a mandatory skill.

As long as the Scrum Master appreciates the value of technical practices, and importance of having a good technical debt in the project, one can always take help from a technical/functional coach or expert to implement the practices.  

Fundamentally, I see that following skills are essential to succeed as a Scrum Master

1. Ability to identify the technical or functional experts within the team (or the lack of)
2. Finding ways to get the help for the team
3. Skill to remove the impediments/blockers
4. Appreciate the value of good technical practices
5. Asking the right set of questions to get the answers
6. Empowering the teams to succeed and build self organizing teams

Let us take a look at an example. Consider a scenario where in a developer shares a blocker saying
                                               The message to TIBCO server is failing.

The Scrum Master(SM) need not know how to fix TIBCO server issue. As long as SM asks the right questions, the impediments could be removed and one could succeed in any project.

A SM could ask following questions in the context of above TIBCO server issue (not in any specific order)
1. Is this a new one or the one occurred in the past ?
2. Who are the TIBCO skilled experts in the team to be invited to investigate this issue ?
3. Do you really think it is TIBCO server issue or something else ?
4. What is the criticality of the issue and who should be informed ?
5. What is the fall back plan ?
6. What is the impact of this issue on delivery timelines ?
and few more questions…

In the end, the SM could do a retro (if it is major issue), and apply 5 Whys to identify the root cause.

Agile testing Vs Traditional QA

 

Exploratory testing   : Business requirements on an agile project may not be as concrete as requirements on a traditional project; agile methods accept that change is a healthy and real part of software development. This means that test case generation may not be as cut-and-dried as it was in the past. Exploratory testing is an essential skill to uncover additional considerations for the product owner to evaluate.

Automation

Agile emphasizes automating as much as possible, but many teams struggle with when, how much and what tools to use. While continuous integration (CI) is an accepted developer practice, agile testing takes the lead on incorporating automated acceptance tests and creating regression test plans as part of CI.

Communication

Traditional QA engineers tend to rely on documents. Agile testing QA engineers don’t get a big requirements document as a basis for test cases and don’t get three months to write test cases before they see a working piece of code. They jump into the communication stream, which may be verbal, written or virtual, and assimilate the information they need.

Challenges with Traditional QA:

· Significant delays between when software is written and development receives feedback

· Defects found late in the process can have major implications when changed

· Changing business requirements affect test cases that have already been developed

· Siloed communications create risk that different groups may have different expectations of the final product

· Quality suffers and many QA activities get left out when testing is the last activity before a fixed release date

Benefits of Agile Testing:

· On-going feedback to developers allows testers to ask the right questions at the right time.

· Early identification of dependencies, technical or testing challenges and roadblocks.

· Embraces change as a healthy and real part of software development.

· Team collaboration helps everyone work together toward a common goal.

· Quality comes first because final acceptance criteria are established prior to the work beginning.

Learn more about Test First programming, and how to transition from traditional testing to agile testing.

Agile and Post-Its

For many,  Agile projects and Post-Its are synonyms, and do you agree this is a misconception ?.
This misconception has gone to such an extreme that, some believe that if you are not using post-it notes then you are not Agile. This looks funny for many Agilists, but this belief is true with many newbies.  One might be interested to understand the origin of this misconception.  Let us start with Information radiators.

Information Radiators

Information radiators are not a new concept. Lean thinkers and Toyota teams have been using this from many years. This concept was popularized in the Agile world by  Alistair Cockburn through his book Agile Software Development.   Since Post-its are handy and easy to use they became popular as information radiators across the globe.

In my opinion, Information radiators are just like any other tools. As the Agile manifesto says,
“Individuals and interactions over process and tools”.   So, one needs to be cautious of using the tools appropriately.

Now we know that Post-Its are just like any other tools. One should be cognizant of their usage in Agile projects. Even though, I have taken the example of using Post-Its here, this is applicable to all tools. Let us see some uses of Post-its.

Teams use Post-It notes to display

• the status of User Stories (Analysis, Design, Build, testing, etc)
• the quality stats
• Impediments/Risks/Issues
• etc.

My experience says that teams reject tools or the tools become unusable if

• wrong tools are used even in the right context
• If the right tools used in a wrong way

Especially, tools play a key role in large scale and long term Agile projects.

Large Scale and long term Agile projects

In the long term projects, over use of Post-its leads to what I am terming as “Post-It Noise”. The wall not only gets cluttered, but people will stop updating the walls.  There are a few who have reported stress due to the cluttering of wall due to unplanned growth of Post-its on the wall. 


I am not against using the Post-it notes  however one needs to be cognizant of  maintainability of them on the walls.  A wall with a beautiful display of Post-it not only adds value but gives a pleasant look.


  http://ericlefevre.net/wordpress/2007/11/17/reflecting-on-our-open-space-technology-event/

Summary

• Use Post-It notes based on need. If the teams are comfortable using flipcharts, White boards, let them use it. Don’t force people to use Post-It notes for every task.
• Arrange Post-its or cling on sheets in a pleasant way
• If you find the teams not updating the wall, do a retro and see if the wall is really adding value

Useful resources

• Visual Display of Quantitative information provides an overview of communicating the data effectively in a graphical way
• Visual Management of Agile Teams
• Trusting a yellow sticky ? Good luck with that
  
  
  
  

Velocity : Myths and Misconceptions

Velocity is one of the simplest but powerful tool to predict the future completion date of the project.

What is Velocity ?

Velocity is the capability of a particular team to deliver certain set of requirements within a specified duration.

It is very important to note that, this is true for a particular team with a fixed duration.  If the team and duration changes then the velocity changes automatically.

Based on my past experience interacting with several teams, I found that following misconceptions misguide the teams.   As an Agile coach or Scrum Master, it is very important to help the team to understand the true meaning of Velocity and drive away the myths and misconceptions.

Myths and Misconceptions 

Wrong	Right
Velocity is productivity	Remember,  Velocity is not productivity.  Productivity is how busy your team is. When some one is measuring productivity, they don’t measure the value generated out of it. Productivity is also measured against a standard.  However, Velocity is for a particular team, particular context and in a specified duration.  Velocity could be tied to business value.
Velocity Standardization	Many leaders think of standardizing velocity across multiple projects and sometimes throughout the organization.  This is totally wrong. As said before, each team is different, trying to enforce velocity of one team on another results in increased stress, loss of morale, productivity and finally loss of value to the customer.
Converting Velocity measured in Story Points to an absolute number in Person days	I have seen many Scrum Masters trying to convert the Velocity measured in Story Points to Person days. For example, 80 Story Points = 60 Person days.  Again, this is wrong. The above conversion basically freezes the delivery capability of the team upfront.  If the team is new to a technology or a business domain, the capability to deliver would be less. By freezing the story points upfront, the new team would struggle a lot and will get stressed out.
Comparing Velocity among teams	Since Velocity is specific to a team and within a context, it does not make sense to compare the velocities between teams.  A team comprising of Oracle Experts working on Oracle technology obviously will fare well as compared to a team of  fresh out of college put on a similar Oracle project.  Velocity of both the teams would be different. Never compare velocity between teams

Large Scale Agile development– Key danger and few tips

The biggest danger to large scale Agile development spanning multiple releases  is complacency, and especially around following Agile practices.
For example: After doing the same daily stand-up for hundreds of times, a few teams get bored. They start skipping the daily stand-ups or try to tune in their own way.  
It becomes Scrum Master’s responsibility to ensure that the team gets back on track by identifying the team issues.  I have always found that talking to the team in a non-hostile way helps in identifying the root cause.
It is very important for Scrum Master not to force the practices but sell the idea through discussions and by empowering the team.
Here is a good article summarizing few key ideas for empowering the team.

Coming back to the point of complacency, how to avoid one ? 

Here are few tips 1. Change the structure or time or the location of say Daily stand-up after few months.  Instead of doing at 9 AM in the morning, you could do it at 3 PM. 

2. Identify and rotate the leaders to run some of the Agile practices.  Rotate the anchors. Give a chance to the back bencher to anchors the practices.  

3. Add or rephrase the questions for the daily stand-ups.

4. In one of the large scale Agile development I was leading, initially teams were using the questions “What is working well and Not working well” as part of Retrospective.
After a few months, I changed the questions to “What is working well and What we should do differently ?”
We started using Ideaboardz  for some time and switched over to “Discussion boards”.

5. Do a retro on these practices to get feedback from the team to assess their energy levels

One cannot avoid complacency in large scale and multi release Agile projects, however, by keeping the eyes and ears open, one could mitigate the risks.
Photo courtesy: http://www.freedigitalphotos.net/images/Ideas_and_Decision_M_g409-Solution__p23490.html

Impact of different cultures on Scrum meeting and Retrospective

Scrum meeting and retrospectives are the two key Scrum practices. These two practices provide an opportunity, for every team member to express themselves.  Expression is not only the key message here; the team is allowed to share the impediments, bottlenecks, risks, issues and what is not working well for them.

Photo courtesy:http://www.freedigitalphotos.net/images/Other_Objects_g271-Traditional_Chinese_Knots_p59170.html
Silent Cultures
Some cultures don’t encourage expressing negative feelings in public.  Even when there is terrible issue in the project, the team members will keep saying everything is working fine until the issue becomes so big that it is not solvable. It is not that they want to hide anything, it is just that, they want to silently solve it by themselves.  This cultural problem aggravates if the team is working in onshore/offshore mode.  The onshore members have to rely on the voice or emails, when they cannot see the body language of offshore team.  If you are working on one of those projects, then one would see a no-issue period for few iterations and then a huge panic after that.

Even during retrospectives, one would see a big list of all the good things, and a small list of improvement areas.

Impact: Continued suffering by project members and since issues are detected at a very late stage, additional effort and stress gets added.

Expressive Cultures

Team members from expressive cultures would challenge every issue and bring out impediments upfront.  This provides an opportunity for all the stakeholders to address concerns upfront.  If you are working on one of those projects, one would end up having a long list of impediment issues and retrospective items to cover.

 

I see more pros than cons here. Some times decision making becomes difficult as the team members would end up spending a lot of time debating issues.

Photo courtesy: http://www.freedigitalphotos.net/images/Mature_Men_g217-Expressive_Old_Man_p46710.html

Hierarchical Cultures
Hierarchical cultures have a  strong command and control style of leadership. Typically, a lead represents the entire team and makes all the key decisions.  The team members just follow the directions from the lead with no questions asked.  The team members will be like “Blinkers” on horses eyes.  They can only see or hear few things from a window given by the lead.

Impact
>>  The team members will only share impediments/blockers that are allowed to be shared by the lead.
>> The team members find it difficult to make decisions on their own
>> The impediment list from Scrum meeting and the feedback items from the retrospective will have a pattern of certain issues only. Because, these are the only patterns that are allowed by the lead to be shared to the outside world.

Photo courtesy: http://www.freedigitalphotos.net/images/Other_Business_Conce_g200-Organisation_Chart_p36927.html

Let me know if you have other stories about the cultural impact on Agile practices. Am happy to publish it.

Top 200 Blogger

I found out recently that  My Agile Blog has been rated as one of the Top 200 Blogs on Agile. 

Check this link out: http://agilescout.com/top-agile-blogs-200/

Right now I am on 155 .   This number could change depending on so many parameters.   I am excited though.