Saturday, January 03, 2015

Three Common Struggles of Agile Teams

I have seen three common issues that many Agile teams struggle with. I will try and address them here for future references.

We need to increase our sprint length...

This usually comes up after a team has gone through a few months of sprinting. Most teams start with 2 weeks of sprint (you cannot go wrong with this choice for an established company/team). Some smaller teams, specially startups choose 1 week of sprint (highly recommend it for startups since product is usually in exploratory stage). However, most teams find themselves not being able to finish what they plan to deliver early on. While it is demoralizing, it is perfectly OK to find yourselves in this situation. Every team goes through this stage (if you hear otherwise, they are lying...:-)). A quick fix for this would seem to be increasing the duration of sprints, right? Wrong. Sprint length as the cause of the problem here is a red herring. The fallacy lies in the thinking that having more time would allow the team to finish everything they plan for. It is a classic fallacy as aptly captured by Parkinson's law- 

                           "work expands so as to fill the time available for its completion"

The issue commonly lies in estimation. There are a few things that cause estimation issue in an Agile environment:

       a. Not being able to break stories. Right sizing stories is tricky and requires experience (trial & error).
       b. Not taking into account other regular commitments (production support, company activities, non-project meetings etc) by team members
       c. Bug fixes, ad-hoc requests

All these and other similar activities are most likely taking team's time away from actual project work and not getting reported/visibility for the planning. Team needs to identify those and plug those leaks.

However, not being able to finish what a team plans to deliver should not come as a surprise at the end of the sprint. This should become apparent thorough the effective use of "Daily Scrum." If it is not happening for your team, revisit how Daily Scrum is being conducted.

The most important aspect of a good Agile team is to be able to proactively manage expectation and eliminate surprises. 

I cannot  contribute to estimation as a non-developer (e.g., tester, analyst etc)....

Relative estimation can be confusing for people coming from traditional project management. Heck, it is still a conundrum for many of us doing Agile for a while. We understand the basic idea of it. But, probably not comfortable effectively using it in practice. A common question comes up usually from the non-developers on the team is -

                 "I'm not a developer so I don't know how long it will take for us to implement."

That is a fair concern. However, this concern stems from the assumption that we are estimating only the programming (programmers) aspect of the development.  That is partial view of the estimation. The correct way of looking at it is-

How would you size this story compared to a known story for all the work YOU (not others) need to do in your role (e.g. tester, designer, analyst etc.)? 

For example,

A 5-point story means it is going to take approx. 1.5 time more work for everyone involved compared to the known story estimated to be 3 points.

Another important distinction of relative estimation from absolute estimation is that we Do Not Add up Points estimated by each role or individuals. We just pick the agreed upon point. Now we could use some heuristics in picking the point estimate after discussing the differences in our estimations. Examples of such heuristics are-

   a. Pick the largest one (it is a safe play).

   b. Pick the majority one (common in practice).

   c. Pick the one based on the nature of the story- e.g., if a test heavy story, give precedence to the estimates by the testers. If it is a design/UI heavy story, e.g., give precedence to the estimates by the designers/front-end developers. You get the idea.

Couple things to remember about relative estimation:

  a. It is important to be consistent with regards to how you pick the point estimates.

  b. Over time, the team will get efficient with estimation. So, do not worry if it takes longer in the beginning!


I don't understand why we need to break our requirements into smaller stories when we know we need the whole thing...

Product owners new to Agile inevitably find it difficult as well as frustrating to be required to break feature sets into stories appropriately sized for implementation in a sprint. While describing requirements as stories is intuitive, breaking stories into smaller stories yet maintain meaningfulness from a user/business perspective is not. It requires practice by trial and error. However, sometimes the importance of breaking large stories into smaller ones are not apparent to the Product Owners. Here are few important advantages of breaking large requirements into smaller stories:

      a. Allows you to roll-out the most important part of the feature set early and get feedback and adjust accordingly.

      b. Allows you to address business risk, or technology risk first with just enough time & money commitment.

     c. Allows the team and the customer/sponsor to maintain a high level energy & momentum derived from the  satisfaction of making steady progress (very important, but often neglected aspect of team dynamics).

     d. Avoids implementing unnecessary features. It may not be apparent what parts of a feature set are *actually* necessary. The only way to figure out is by delivering and validating them in small chunks.

Still not convinced? Would love to hear your particular situation and discuss in the comments section.