July 2013 Archives

5. You have no Product Owner.  Having a Product Owner as an integrated member of the team is critical to success.  Your Product Owner is the person telling you what's the most important thing to work on next, and he or she is also the person providing you feedback during your iteration and during your demos about whether what was produced was what was envisioned.  You cannot alter course if necessary without someone navigating, and that navigator is your Product Owner.  Similarly, if you only saw your Product Owner once, at the beginning of your release cycle, and he or she just dropped off a giant pile of requirements, you are doing Waterfall, not Agile.

4. You have exactly one Release on the horizon.  Nothing is a bigger indicator that you're in a waterfall model, even if it has short bursts of activity, than having a plan for only one Release.  If you haven't built anything until you've built everything, this is a clear sign that your user stories haven't been written properly.  Ideally, you should be delivering some kind of functioning system with every release, even if the functionality is very limited in the first release, but becomes more elaborate with every release that follows.

3. Your release date is fixed.  Your features are also fixed. Everything is the top priority.  If you're in this situation, then your planning meetings have no room for negotiation.  Your velocity, if you know it, doesn't matter, because you have to do everything, and you have to do it by a certain date.  There is no ability to prioritize.  This kind of behavior is often indicative of trust issues coming from the Product Owner or his or her superiors.  They do not trust the development team to work hard, plan judiciously, and to deliver incremental value with each Release, or they do not want to be involved enough to evaluate multiple incremental releases.  (See #3.)

2. Someone tells you your velocity, you don't know your velocity, you don't use your velocity in planning, you measure velocity in "real hours," or you use velocity to measure performance.  These are typically symptoms of a team or of a management hierarchy that does not understand the concept of velocity.  Velocity is a measure of team throughput, and it lacks a necessary 1:1 correlation with time.  This is because the team will take into account mitigating factors like risk and uncertainty in addition to effort in producing an estimated size for a story or task.  Because we work as a team, not as individuals, we don't adjust up or down expected velocity by a percentage as team members take vacation, are out sick, or leave or join the team; rather, we wait for the end of the iteration and look at what the velocity actually did, expecting it to average out over time.  It's a measure of reality, not a measure of expectation, and we use that measure to estimate how much we think we can take on for the next iteration.

1. Your iterations are more than two weeks long or you have many tasks with very large estimates.  Fundamental to Agile development is the ability to react to changes and to react to unexpected disparities between estimated effort and actual effort, and these reactions typically will take place on iteration boundaries when planning occurs.  If you only have an opportunity to make a course correction every 3 or 4 weeks, your agility is severely hampered.  Moreover, if you're trying to establish an average velocity-- something that normally requires at least 3-4 data points to establish a trend-- the longer your iterations, the longer it takes in real time before you can begin to make meaningful estimates.  If your iterations are one week long, that means three weeks for a velocity trend.  If your iterations are three weeks long, that means nine weeks before you know your velocity... and many entire releases won't be that long.  (See #3.)

So what do you do if you live in a world of one or more of these signs?  (After you're done wallowing in despair, I mean.)

First you need to have a serious discussion with your management chain.  Feel free to bring this document as a visual aid. I've come to believe that a team can only be successful implementing agile if both the team and its management chain really buy into the idea and support it.  It's easy to give lip service to Agile methodology, but unless actual behavior changes on an organizational level, success will be limited.  You need organizational support.  You also need your own team to self-organize and support the process.  Without it, people will consciously and unconsciously sabotage your efforts.

Secondly, and I suspect somewhat more commonly, you can try to fake out the system.  This is more common when the team wants to implement an Agile methodology, but management doesn't really believe in it.  You can start working on your release early, before a release date is committed, and try to strongly suggest a likely release date based on the velocity that you've already figured out, before the organization itself has actually committed to doing any work.  You can create your own internal releases that will never see the light of day, but which give your team milestones closer to the horizon to to work toward.  You can have someone playing "proxy" Product Owner if necessary.

The problem with the second approach is that ultimately your team, your Scrum Master, your proxy Product Owner, and your management chain will feel dissatisfied with the approach.  Your team feels that its input isn't valued and that it isn't trusted by management.  Your Scrum Master feels he or she isn't supported by management or appreciated by the team.  Your Product Owner, lacking any real direction, feels accountable for the outcome without really having any true direction in making decisions.  And your Management chain gets the impression that Agile is one gigantic uncoordinated mess, but of course, what you did wasn't really particularly Agile in the first place.

Good luck.

---Nick