Agility: What’s In It for Me?

Agile adoptions often generate this question from senior management and without a good answer, the adoption of agile practices and values on an organizational level will never happen.  What makes the answer hard is that many benefits of agile are less tangible than many senior managers are comfortable with.  So just why should senior managements care about agility?

I would suggest agility provides senior management three things: Effectiveness, Information and Control. But to get these, senior management needs to play its role too. Let’s take a look.

First, agility provides the promise that teams are working very effectively toward the organizations most important goals and priorities.  The better focused these goals and priorities are the more effective the team will be.  Senior management often does not push this information down far enough in the organization on the premise of “not needing to know” or in interest of “not causing a distraction from the current work”.  Both the premises are flawed.  Agile teams need to understand and believe in the organizational goals and the part their work plays in reaching them.  That we expect priorities to change is the exact reason agile teams need to be well informed.  If the team understands the strategic goals as well as the more tactical priorities on reaching them, they are in a better position to contribute to and feel accountable for the organizations’ success.  They are also in a better position to recognize why priorities change so they can adapt with the confidence that the work they are doing is both the right work to do today and that it adds value.  If senior managers keep their agile teams in sync with current business goals and priorities, they will be much more effective.

Second, agile practices provide improved information about the progress the organization is actually making toward its goals.  Good, bad or ugly, this information is the brutal truth based of the reality of the organizations past performance.  We can project how much work the team can accomplish in the next interval, because we know exactly what was accomplished in the last one, and those before that.  Progress is no longer based on fantasized, often politically shaped estimates that “this task will take three days… oh that’s too long; alright, it will only take two days”.  Teams have to have the courage to tell the unvarnished truth, and senior management has to have the courage to hear it.  Agile leadership must work to create an open, transparent, trusting, “safe” environment for everyone. Without this open and honest communication senior management is making decisions based on the wrong information, and that creates much of the waste that agile practices are trying to eliminate.

Third, agile practices give senior managers more control.  That might seem odd, since agile practices work to shift significant control from management to the team.  Senior managers are able, at iteration boundaries, to make better decisions based on clear and real knowledge of the actual facts.  They better know if the project is producing the expected value.  They better know if a project has gone astray and why.  They can more easily recognize a project that is providing good value versus a project that is not and take the appropriate steps.  Are the goals of the project not understood? Does the team need more information? Do we need different skills on the team? Have business priorities changed making this project less valuable than it once was?  Whatever the case, senior management is now in a better position to control the destiny of the organizations’ projects, and do so much earlier in the project life cycle eliminating further waste.

Agile practices can bring a better sense of order to today’s often frantic business environments.  The key to that is helping senior management recognize and perform its role in setting the path for the organization to always be focused on achieving the best possible result it can get right now in today’s reality.

 

You Want That When?

If you lead software development teams, then you likely have had this reaction to the management decree of delivering some set of software features by an arbitrary date. Sometimes that is followed by therapy and/or a quick update of your resume. In an agile world, project schedules that are derived from executive fiat will ultimately lower product quality and destroy the team, not necessarily in that order.  That’s what happens in the traditional world too, it just may not be so apparent.

Agile teams don’t predict progress based on intuitive estimates of “I think that takes 7 hours”.  Progress is projected based on the past history of the team.  In the last 5 iterations the team completed work of a certain relative size.  Based on that pace, it will take x number of iterations to complete the work currently on the product backlog.  An example; the product backlog has 150 points of work left and the team is completing 15 points per iteration.  It will therefore take 10 iterations to complete the work on the backlog. 

That sounds simple enough, but actually I don’t want a team to commit to completing certain features by a certain date, even if it is basing that commitment on their velocity against the size work remaining on the backlog.  That presumes a precision that likely is not reality.  Although we think the features on the backlog are 150 points, as we start doing that work we will learn more and realize that we forgot something when we sized the feature, or discovered that something else is needed to deliver a feature, or there is something on the backlog that we don’t really need to do at all. 

What I want to do instead is make the schedule a shared responsibility between product management and the development team.  Product management gets to say “what”; the development team gets to say “how fast”.  So I want to team to commit to a velocity, actually a range.  Once the team has some history, they can agree that their velocity shouldn’t fall below some number and is not expected to exceed some other number.  With some confidence it could say its velocity will be between 20 points and 30 points per iteration. In his book Agile Estimating and Planning, Mike Cohn advocates calculating these two numbers by averaging past velocities for the worst three iterations for the worst case, and of the last eight iterations for the most likely case. Armed with these two numbers, product management can then easily see that if 5 iterations remain before a desired delivery date, then the team can deliver somewhere between 100 (5 x 20) and 150 (5 x 30) points worth of features and can prioritize the remaining work accordingly.

Going a step further, we could also calculate a best case by averaging the velocities of the best three iterations. Consider the iteration history shown here.  The average velocity of all eights iterations is 17 points; that is the team’s most likely velocity.  Best case is 20 points (average of 21+19+20) and worse case is 13 points (average of 11+16+13). Assuming the product backlog started at 250 points.  That allows us project a release burndown as shown here.

 

Through iteration 8 the team has 132 points remaining. The team may be done with this work as early as iteration 15, as late as iteration 18, but most likely at the end of iteration 16.  

Now in partnership, product management and the development team can both act responsibly to align the delivery date to meet the business needs.  If the team is not finishing earlier enough, we can either work on removing whatever impediments that are not allowing the team to move faster, or we can remove some lower value scope from the release.

Either way the team is working at a sustainable pace, product management understands what is being delivered when, and that therapy session can be saved for another day.

 

The Art of Burndown

If you are familiar with Scrum then you will recognize this chart as an iteration burndown.  One line is the ideal pace for completing the work planned, the other is pace at which the team actually completed its work, and the chart is intended to communicate the progress of the team during an iteration.

If you were the product owner, or other stakeholder for this project, what would this burndown actually tell you?  As in all burndowns, the remaining work line always reaches zero, but how did the team actually get there?  How much work did the team really complete compared to what it expected to complete? Should you be pleased with the progress of the team?  Did you see the visible, predictable progress that we hope to achieve by working in iterations?

Experienced agile teams will know the answers to all those questions, but not particularly from the burndown.  A team that is collaborating well will be in sync with the rhythm of the iteration and can interpret the burndown in context of what they already know.  The iteration review and demo will just confirm (and celebrate) that.

Those new to the ways of agile teams however may struggle to understand the burndown and the iteration review and demo could be a significant shock to the project stakeholders; not the openness and transparency agility aims to achieve.

 

Consider then an alternative; actually an iteration burnup that provides some more information to communicate how the team is progressing. 

 

 

 

 

 

 

 

 

First the legend:

• Red – the hours the team collectively expected to have available to work during the iteration.
• Black – the work the team initially planned.
• Blue – the revised plan as the team either discovers new tasks to complete that were not initially planned, or removes tasks not needed or that will not be completed.
• Green – the work team actually completed.

Note the completed line is not actual hours worked; it is the sum of the original or revised hours estimated for the tasks completed.  Tracking actual hours is tempting, particularly for traditional project mangers, but it is not at all helpful in determining the pace or progress of the team.  Knowing that it took 15 hours to do a task I thought was only 8 doesn’t help me understand how much work I have left to do for the iteration.  Nor does it help me assess the accuracy of any of the other estimates.

I want to know what work is complete and what work remains.  From that I can better forecast what work will be completed for the iteration based on the reality of the team’s progress.  The only interest I have in actual hours worked is to discourage the team from working significant overtime to meet the iteration goal.

So what can I deduce from this burnup?

• First, the team is likely overly optimistic about the hours they are really available to do productive work for the iteration.
• Second, the team is not adjusting the work in iteration based on the reality of their progress. It was clear from day 2 forward that the iteration goal was in jeopardy, even as work was being added to the iteration, but the team did not react to it until day 9.
• Third, the team is completing work at an erratic pace. Work completed actually varies from 9 hours on day 6 to 48 hours on 4.

Certainly there are a number of circumstances that could cause these results, but now I have a clearer picture of the questions to be asking as the team plans future iterations.

• Does the team feel safe in stating their true availability for the iteration?
• Does the team know enough about the work they take on?
• Is the team breaking the work down into small enough tasks to accurately estimate?
• Is the team empowered to say no to new work being added to the iteration?
• Is the team able to assess their day-to-day progress and make good decisions about what work they can really complete?

Simply completing the number of hours of work intended during an iteration is not the goal however.  That’s just a means to an end.  The end is for the team to routinely deliver working software at the end of every iteration that adds the new features or functionality deemed most important by the product owner.  A team that can accurately access the work involved, and monitor it closely throughout the iteration can then also decide how to achieve the best possible result for the iteration.  That may be to set aside some work to complete later to ensure that at least one new working feature is delivered for the iteration; or it may be the discovery that more can be achieved that initially thought and another feature can be added and delivered.

No tool will make a team adopt better agile practices.  Finding ways like this to help the team understand why they achieve the results they achieve however, will help the team make better decisions and grow into those practices.  That’s what agile leadership is about.

 

Advanced Citizenship

Being a member of an agile team is not like being a member of just another project team.  Traditional project teams are generally not accountable for meeting business goals, they are instead responsible for doing work they are told to do; i.e. following the plan that someone else derives.  If the plan does not actually lead to meeting the business goal, this is not so much the team’s problem as management’s problem.

This is not the expectation of an agile team.  An agile team is accountable for meeting the business goal, and continually adapting the plan to get there.  This is the point of growing self-organizing/self-directing teams, and that makes being a member of these teams advanced citizenship.  It also means that not just any random group of people will make it as an effective agile team.

In his book Go Put Your Strengths to Work, Marcus Buckingham poses three myths that are very appropriate to consider as we think about forming agile teams:

• As you grow, your personality changes.
• You will grow the most in your areas of greatest weakness.
• A good team member does whatever it takes to help the team.

While these three statements appear sound on the surface, Buckingham eloquently explains that they are not actually true.  His conclusions instead are:

• As you grow, you become more of who you already are.
• You will grow the most in your areas of greatest strength.
• A good team member deliberately volunteers his strengths to the team most of the time.

When thinking about developing effective agile teams then, these three truths have some profound implications. Team dynamics trump all else for an agile team. To be effective the team has to be comprised of the right individuals interacting in the right way (see additional musing on this subject). This is inherent in some people and a struggle for others.  Buckingham’s first two statements suggest that if this is an area of weakness for a team member, the person may improve with good effort and appropriate coaching, but is unlikely to develop team dynamics as an area of great strength.  That does not mean this person is defective in some way; its means the person has ended up in the wrong role.

An effective agile team is like a sleek sailboat with its sails full of wind. As teams begin to develop and their sails begin to take the wind, responsible leadership needs to be wary of team members who remain an anchor in the water forever dragging the team down.  Agile leadership cannot fail the team in these instances. It must act to remove the drag on the team and assist these persons to find more suitable roles in or out of the organization.

The third statement is even more intriguing. Many agile enthusiasts believe good agile teams are made up of generalists willing to contribute in any way needed; well-rounded teams are comprised of well-rounded individuals. Buckingham’s third truth is quite contrary to that notion. His belief is that the members of an effective team are not individually well-rounded at all.  Each is deliberately contributing in the areas of his/her greatest strength most of the time.

Isn’t that what we really want on our teams?  Don’t we want people doing those things that they are really good at and not just pitching-in to do things they are only adequate at?  Again the challenge for agile leaders is not to find well-rounded individuals, but to build teams around people with good team dynamics and that complement each other with significant strengths pertinent to the work at hand. The result is a well-rounded team whose sails are full and that has both the ability and awareness to take full advantage of the changing winds around it.  That’s advanced citizenship at its best.

What else does this mean for agile leadership? For an agile team to develop and prosper it needs organizational support. It needs an environment in which it feels safe to self-organize and self-direct.  It needs an advocate to help the broader organization understand how the team is working.  It needs guidance to stay focused on ever changing business objectives.  It needs a protector who will deflect distractions. Above all it needs leadership that sets an example of the advanced citizenship required to succeed; a leader who acts by coaching, not directing; asking not telling; advising not mandating; teaching not doing.  At times it also means letting the team fail, so that it can learn how to succeed.

Agility is often thought of as an undisciplined free-for-all by those uninitiated in its values and practices.  In reality, agility is practiced by highly disciplined individuals exhibiting the leadership and team dynamics that free them to soar far beyond the bounds of traditional project teams.  Advanced citizenship is required.

 

Individuals and Interactions

When I think of the four value statements of the Agile Manifesto, it is hard to think of any one of them as more important than the others.  It is easy however, for me to think that “Individuals and Interactions” serves as a good foundation for the rest.

Getting the right individuals interacting in constructive ways is not a new idea, nor one suddenly born when thinking of software development.  Consider Dan Pompei’s recent article Small wonder Colts, Pats excel in NFL Draft for MSNBC.com.  Of the 79 draft picks Indianapolis Colts owner Bill Polian has made over the years, 38 players have become starters, and more than 11% have become Pro Bowl players. Bill Belichick and Scott Pioli of the New England Patriots have had similar success.  Are they just lucky?  Are they just picking the big stars? No and No.  What they are doing is picking the players that best fit their systems and then developing them; and one doesn’t have to be much of a football fan to recognize these two teams have had a bit of success. Looking at good companies that became great, Jim Collins (Good to Great) expresses the same idea as “First Who… Then What”; a discussion that has led to the often quoted “get the right people on the bus”.  Collins goes on to say that once the right people on are the bus, then you can worry about what seats they are in.

This notion of getting the right “fit” is an important consideration when forming agile teams.  Agility recognizes the importance of collaboration and expects more from the team.  How the team works together, how it communicates, how it collectively finds solutions are all far more important than the individual contribution of a single team member.  Some believe agility calls for a team of generalists that are willing to do “whatever the team needs done” and “whatever it takes for the good of the team”. I believe this diminishes the team and removes too much of leadership’s burden to form teams that fit well together, i.e.; get the right people on the bus. 

In his book Go Put Your Strengths to Work,  Marcus Buckingham talks about highly effective teams and declares “A good team member does whatever it takes to help the team” to be a myth.  His truth is “A good team member deliberately volunteers his strengths to the team most of the time.“

That is a significant difference.  A highly effective team is a well-rounded team, but that does not mean each team member is well-rounded, doing whatever the team needs done.  It means that as a member of the team I recognize that I am best suited to do some of the work the team needs done; that other team members are best suited to do other work for the team; and because of that the team will be more successful.  Certainly we want team members to occasionally step in for each other, but their primary focus should be their areas of greatest strength. I play the piano, some say pretty well.  While I will get better if I practice hard and study with some good teachers, I will never be a concert pianist.  Placing myself, or being placed by others, in a position of needing to be a concert pianist is not going to lead to success for me or anyone around me.  The team is much better off if I allow someone else who has those skills to be the concert pianist.

I believe Buckingham’s truth, but it has serious implications for both team members and team leaders. Team members must have vivid self-awareness of their strengths and the focus to steer their work toward them. Team leaders must have the ability to recognize a person’s significant strengths and select team members who complement each other and can collectively become a well-rounded, highly effective team.  Neither is a small task, but achieving them puts us on a good path toward Individuals and Interactions.

 

What is Wrong with Waterfall?

Agility is often thought of in terms of “fixing” the ills of the sequential, step-wise, plan-driven methods that have come to be known as “Waterfall”.  So the question begs, just what is wrong with waterfall?

The short answer is nothing is wrong with waterfall methods.  We’ve all done good work using these methods and I expect that we will all do more good work with them as well.

Let’s look a little deeper though.  In his book Agile & Iterative Development; A Manager’s Guide, Craig Larman describes two broad categories of projects:

• Predictive - You can define all the work for the project upfront, put a plan and schedule together to do that work, and then execute that plan with reasonable confidence that things won’t change much beyond the normal rigors of running a project.
• Inventive - The project has a high degree of uncertainty and change and you cannot derive estimates or schedules from previous similar projects. As work on the project is completed, you learn more about what is required and the resources and effort needed to deliver it and adjust accordingly.

Waterfall techniques address predictive projects very well.  Because the work is well-known is it possible to set the correct path for the project and then use traditional waterfall methods to maintain that path. That is what these techniques are all about.  Change is acceptable but only after some rigorous validation that it is the best thing for the project.

Agility on the other hand is best suited for inventive projects. Because the work required is not well-known, these techniques focus on the expected business value.  Change is not only acceptable, it is expected as we learn more about the business objectives and the work required to achieve them.  As a result these methods readily adapt to change in a receptive, but disciplined manner.

So while there is nothing wrong with waterfall methods, what is wrong  is mis-applying them to an inventive project.

As professional project managers we have an obligation to recognize (and help our stakeholders recognize) where our project falls in the predictive-inventive spectrum and adopt the project management methods that offer us the best chance for success.

Waterfall and Agility are both valuable toolsets.  Every project manager should have both in his or her tool belt and know when and how to use them.

 

Requirement Truths

Consider these four statements about software development requirements:

♦ You can discover all the requirements upfront.

♦ You can minimize requirements changes early in the development cycle.

♦ Once you select a set of requirements you can precisely estimate the effort to deliver them.

♦ The fact that a requirement has been defined is an indication that the requirement will be delivered.

Are these statements true or false? How you answer that might be a good indication of the project management methods best suited for your project. 

If you think that these four statements of mostly true, then a traditional, step-wise, plan-driven (read “waterfall”) method is likely appropriate and has as much chance of succeeding as anything else.  On the other hand, if you think these statements are mostly false, then that same plan-driven approach is likely to be problematic.  Instead a more agile approach that re-evaluates requirements at iteration boundaries has a much better chance of success.

An agile approach embraces the notion that we don’t know everything upfront.  Changes in requirements are not only expected, they are often seen as a good thing. They keep us on a path that is delivering value.  Developing software should not be about delivering some fixed set of features by the desired date.  Developing software should be about making the business bigger, better or more efficient.  It’s alright that we don’t know all the details about just how to do that upfront.  Agile methods let us start with something we know and build on to that based on what we learn along the way.  Frequent feedback validates the work we have done, identifies changes that could make that work better, and discovers new ideas that couldn’t be seen before.  Managing this level uncertainty and change is uncomfortable to traditionally trained project managers, but doing so provides our best chance for success.

Successful businesses are not static; they constantly evolve as they adjust to changes in their market, the activities of their competitors, fluctuations in the economy and many, many other things.  We should not think that we have a static playing field when developing software in these business environments.