Being Agile

Velocity is a great tool for agile teams but it is easy to "over-engineer" the concept -- or even misuse it. Velocity is a mechanism to understand the pace of a team that uses story points to size their user stories.

First, a quick comment regarding story points – Leslie and I advocate the usage of “unit-less” sizings of user stories, meaning that story points are not associated with any measure of time.  Story points are simply an assignment of size relative to other user stories that a team works on.  Thus, a 3-point story should take approximately 3 times the amount of effort for the team as a 1-point story -- irrespective of how long it takes to complete either one.  Note that story point sizings are just relative sizings and they work no matter how long it takes to actually complete a given story of a given size.

Back to velocity…  Velocity, simply put, is the term used to describe a team’s observed capacity for completing work.  Velocity is calculated by taking the average number of story points a team completes each iteration.  For example, if a team completes 8 story points’ worth of user stories in its first iteration, 12 in the second, and 10 in its third, then the team’s velocity is 10 (the average of 8, 12, and 10).  Note that several iterations had to be completed first in order for the team to determine its velocity (we advocate a minimum of three iterations before starting to use velocity for project planning and tracking).

Even though the concept is simple, I’ve seen teams misuse velocity and, as a consequence, reduce its value.  I’ll address three of the most common misuses in the following paragraphs:

First, velocity is incorrectly used as a "report-card" each iteration.  Assume the example I used above where the team has a velocity of 10.  Let’s say that their next iteration they complete 6 story points.  In organizations where velocity is not understood, the team will likely be called on the carpet and asked to explain what happened (the thought being that their productivity dropped by 40%!).  Given that the assignment of story points is an estimation technique and not something to be measured to 26 digits of precision, there should be an understanding that the number of points a team completes each iteration will vary from iteration to iteration.  Perhaps in this iteration the team is working on a story that they underestimated.  Big deal…  Chances are in a subsequent iteration they’ll work on a story that was overestimated.  Over the course of several iterations, the team's velocity will average out.  Please do not use the number of story points a team completes in any given iteration as a report-card.  Use the average and save everyone a lot of headaches from micromanagement.

Secondly, and closely related to the first, is teams erroneously claiming "partial credit" for a story.  When teams are seeing the number of story points completed in a given iteration used as report-card, they tend to start trying to claim partial-credit for an incomplete story.  In this scenario a team might say, “We got the code done, so that’s worth 2-points out of this 5-point story.” Even though the testing, defect fixing, automation, etc., hasn’t yet been completed, they're just trying to boost the total number of points claimed in the iteration.  Unfortunately, this approach defeats a number of benefits of adopting agile.  First, it breaks down team synergy by reverting back to an us-vs.-them mentality.  When the whole team gets “credit” for completing a user story when it’s actually complete, then the team is motivated to help each other out.  If partial credit is allowed, then this can pit parts of the team against other parts.  The second problem with this approach is that it violates the agile principle of working software as the measure of progress.  Code that has been written, but is untested, is not “working software.”  Code that has been written and tested, but where defects haven’t been fixed, is not “working software.”  Working software should be the focus for the team…  And let me close this section with another simple example:  let’s say a team is targeting completion of two 5-point stories this iteration (their velocity has been ~10 points an iteration, so targeting 10 points’ worth of stories makes good sense).  Let’s say they complete the first story and are almost complete with the second.  If the team tries to take partial credit, they might claim 4 of the 5 points for the second story and, thus, their story point totals for this iteration would be 9.  Next iteration, they’d plan to finish off the last bit of the second story and then, most likely target and additional 10 points' worth of new stories (since they have been averaging 10 story points so far and they almost completed 10 points last iteration).  Let’s say they complete all that work in the next iteration for a total of 11 points.  What’s their velocity for the two iterations?  It’s 10.  Now let’s take the “no partial credit” approach.  The team would get 5 story points for its first iteration and 15 for its second.  What’s the velocity for the two iterations calculated this way?  Right, it’s also 10.  This is why focusing on velocity as an average is so liberating for teams – they’re not constantly under the microscope and don’t feel compelled to play games with partial credit.

The last abuse of story points and velocity that I’ve seen is that teams get their velocity "dictated" to them.  They’re told to achieve some level of velocity before even knowing what their velocity is.  Remember, as mentioned at the opening, velocity reflects the team’s observed capacity to complete work each iteration.  Typically, when teams are dictated a velocity, its in “fixed content/fixed date” projects (which are anathema in agile).  Teams wind up working tremendous amounts of overtime to meet their dictated velocity (which is also anathema to agile).
 

Finally, there are legitimate ways to go about increasing velocity, as well as illegitimate ways.  The most prevalent illegitimate way is forcing a team to do overtime – this is not sustainable and will only cause problems down the road.  The legitimate ways to increase velocity is to pursue what I call “enabling” practices:  increasing test automation, improving builds by adopting continuous integration, adopting test-driven development and pair-programming, automating provisioning of test environments, automating deployments, and many others.  Yes, putting effort into maturing these practices may mean you slow down the amount of functionality you produce in the short run, but the long-term benefits (such as sustained velocity improvements) will be well worth the initial investment. Velocity is simple - keep it simple. Increasing velocity is where the hard work is.
 

Scott and I are thrilled to tell you about our new book called Being Agile: Eleven Breakthrough Techniques to Keep You From Waterfalling Backward. You can click on the link below to get access to the book or use the handy link in the Links section of this page.

Our goal for the book is to help teams that have adopted the standard practices and call themselves agile, but have not gained the real benefits that agile promises. We believe that adopting agile requires a change in thinking, not just adopting a set of practices. When teams don't get immediate results, they often fall back into old habits that will reduce their chances of success. Our book offers eleven breakthrough techniques to help overcome reflexive thinking so that you will start to respond with an agile mindset that prioritizes delivering customer value, ensuring high quality, and continuously improving.

The book consists of eleven chapters that focus on some of the critical topics for agile success. In each chapter we discuss the basic principles that are the foundation for the topic followed by the corresponding practices. Each chapter closes with a breakthrough technique to help teams achieve the real benefits of the aspect of agile covered in the chapter. It was not our goal for the book to be an agile primer or even to cover all of agile thoroughly as there are much better references for that. Our goal was to focus on principles critical to agile adoption with which teams struggle and for each area, give them the means to succeed via using an agile mindset.

Scott and I have both had our breakthrough moments and so have the teams that we have lead and coached. We share experiences from those teams to provide a real world context to the ideas. Most of what we have learned came from working with numerous teams and it is our hope that we continue the conversation with you. Please share your "A-ha!"  moments on our blog so that we can all continue to learn together.

Being Agile (IBM Press)

When teams complain that they “do not have enough people”, that may be a sign the team composition has not resulted in an agile whole team. Agile’s mandate for working software requires that teams be composed of the right set of people to deliver on this goal. That generally means developers, testers, writers, user experience experts and so forth. That also means that there are team members from each of the component technology disciplines so that, as a team, they can deliver end-to-end functionality.

Large teams moving to agile often have to form several smaller agile teams with each team delivering completed user stories. Teams that have traditionally been organized by technology or by discipline, are reluctant to move to a cross functional structure because there may not be enough technical and domain knowledge in each of the resulting teams. What they discover quickly is the majority of the knowledge and skills in the team resides with very few people.

The solution to this problem is to cross train the team members so that they are better able to deliver product capability with the right set of skills and domain knowledge. Many teams resist this solution because it requires upfront costs and will slow the team down for a while. In fact many teams are so convinced this will not work that they do not make any effort to cross train and end up with teams that cannot deliver working software. This is what leads them to believe that they “don’t have enough people”.

It is a very hard sell but cross training your teams so that they can deliver a greater range of product functionality is well worth the upfront costs. Software engineers usually have a product area in which they prefer to work or a technology that they favor. But good software engineers have the skills to learn new technologies as required. And it benefits a team when engineers do expand their skills because not only are they able to help complete additional work, but their expertise and perspectives are beneficial when building new software and solving problems.

It is important to let management know there will be a short-term slow down (maybe as much as several months) when cross training team members. But when teams are willing to cross learn in a results oriented way, they become more productive and tend to move faster.

There are ways to cross train and continue to move forward at the same time. Pair programming is a great way to introduce a developer to a new technology or a new area of the code. Developers can also try to fix defects in an area outside of their domain, and then request a code review of the completed fix before it gets checked in. Figuring out how to fix a problem really forces one to learn about how the code works. Engineers can also test and write test code outside their current domains so that they learn additional areas of the product. There are no doubt many other ways you can come up with and we would love to hear your ideas.  But teams that are not willing to take this step will struggle to make agile stick, and will continue to complain that they “do not have enough people”.

A lot has been written about how many of the agile practices contribute to helping teams and organizations become more efficient.  And this is no surprise since agile is built on top of many of the Lean principles that helped manufacturing become much more efficient.

In addition to the tremendous impact adopting agile practices can have on efficiency, another benefit (and one that doesn’t get quite as much “press”) is the reduction of risk that accompanies agile.

First I’d like to address how risk is significantly reduced by adopting the agile practice of “small batches.”  When teams move to coding/testing/deploying small batches of functionality on a regular basis, they typically find defects much earlier than they would have had they still been using large batches.  Many of you will likely recall the old waterfall days when tens of thousands of lines of code were written before the first test against the code was ever executed.  Back then, when testing began, typically large numbers of defects were found in a short period of time and it would take a very long time to get the list of defects fixed.  With the adoption of small batches, defects are often found within minutes of the code being checked in and the impact of any defect that is found, as well as the impact of the time required to fix the defect, is minimal since the code is fresh in everyone’s mind, and more code hasn’t been written that gets in the way of actually fixing the defect.  The risk reduction is significant on just this point alone.

Another risk-reduction benefit of adopting small batches is the ability to get faster feedback from customers due to the fact that the new functionality is made available much faster than it would be if lots of different functions were packaged together into a big batch and released/deployed only once in a while.  If a team puts out a small improvement, or a new feature, and gets feedback from customers that it doesn’t meet their needs, then the team has gained some valuable insights very quickly and their current investment is small.  With large batches, if customers don’t like something, the team won’t know about it for quite some time because of the length of time from when the feature was built to when it was released/deployed along with all the other features in the big batch.  Big batches are very risky due to the delay in getting feedback, as well as the increased costs of making changes (just think of all the additional testing that would have to take place if a change needed to be made and the batch contained ten features vs. just one feature).

The last risk-reduction benefit of adopting small batches concerns the pressure to add features.  If only large batches of features are released infrequently, then typically product management wants to cram as many new features as possible into the current plan because, if the additional desired features don’t make it into the current plan, then it could be a very long time until the next plan is completed and the additional desired features are finally made available.  Adopting small batches allows for continual re-ranking of the backlog of requested features based on customer feedback, new technologies, and market conditions, thus significantly reducing the pressure to cram tons and tons of stuff into a “big batch plan.”

Another agile practice that results in a significant reduction in risk is the adoption of “whole teams.”  By “whole teams” I’m referring to teams that are comprised of cross-discipline and cross-functional responsibilities.  While this is certainly nothing new in agile, understanding how adopting a whole team approach can reduce risk is something that doesn’t get discussed much.  For example, when team members used to go off into their own little silos for months on end, and rarely interact with other team members, it was very difficult for anyone on the team to have any insight into what was being done by anyone else.  And if one of the team members suddenly had to be away for a period of time (e.g., due to an illness or a family emergency), it was almost impossible for anyone else on the team to immediately pick up that person’s work.

With whole teams, not only is there regular communication and sharing of knowledge, but if a situation comes up where someone does have to be away for a lengthy period of time, the impact of the absence will be far less than it would be otherwise because others on the team will have a much better understanding of the work that person was doing and will be able to pick up the work with much less difficulty – thus reducing risk.

In conclusion, I would urge teams to include a focus on risk reduction as part of their regular reflections – it’s part of agile’s focus on continuous improvement.

Please feel free to comment on other areas that you’ve seen where adopting any of the agile practices has led to a significant reduction in risk.  Thank you!

Teams migrating to agile from waterfall have a significant learning curve to overcome, so they tend to adopt some of the easier to manage practices first (like the daily standup, time-boxed iterations, and reflections to name the some of the typical ones). If they do not tackle practices like regularly having working software, getting to "Done!" every iteration, and not accumulating debt, then the benefits realized will likely be somewhat minimal. Stated a different way, if a team's agile adoption does not produce some clear improvements in a timely fashion, then the team is not likely to make the effort to continually get better.

A sure sign of this "stagnant" situation is teams who are doing "waterations."  Waterations are iterations that look like mini-waterfalls. They typically start with design in the first couple of days, then proceed to coding for a number of days, then followed by testing, and so on.  Teams that operate this way don't normally get to "Done!" until the last day of the iteration (if they get there at all).

To get real benefit from adopting agile -- and make sure that it "sticks," teams should move beyond just the basics and continually look to adopt the more rigorous practices.  For example, keeping debt at or near zero throughout a project, a concerted "whole team" focus where progress is measured at the team level instead of at the individual level, coding and testing being done throughout an iteration instead of being separated into phases within an iteration, having comprehensive "Done!" criteria and sticking to it, as well as others will help teams realize more significant benefits.  We'll be addressing each of these topics in future posts.

One of the primary reasons that agile teams are “more productive” is that they work together closely to complete small batches of work frequently and continuously. The better the team is at working together, the better their productivity. However, teams struggle to improve their ability to work together, and so this becomes one of the most significant barriers to real agile success.

If you think about how work goes in a typical waterfall project, usually the first thing that happens is that the team decides what they are going to do and then very quickly they split into separate sub-teams to do the work. Generally the team does most of its coordinated work at the end of the project when they have to make it all work. This is the "hockey stick" effect of waterfall. From my days in waterfall I remember long hours, nights, and weekends working through problems with the rest of team. In fact I remember reconnecting with people that I had not worked closely with since the last “end of project march.”

Agile breaks this pattern by working closely together from the beginning of the project. The “end of project” style of coordinated team work in waterfall happens throughout every iteration. This is what makes agile so productive. However, “getting there” can be hard because working where your domain knowledge and skills are the strongest is where you want to work and where you know you will be the most productive.

As the software industry has progressed, software projects have become larger and more complex. With size and complexity, specialization typically follows. We have been encouraged to specialize in order to capitalize on our personal strengths and then use those strengths to produce better product capabilities. Specialized skills are critical so that we build the right solutions. However, learning new skills and increasing your technical breadth is also important. To make an agile team more productive, team members needs to be willing to broaden their skills so that they can help the rest of team get to “Done!” in addition to completing their own work.

This does not mean you have to become an expert at everything or even offer your help when it is not needed. When I was in school getting my Computer Science degree, our professors told us that “You are not a <insert favorite software language> developer, you are a software engineer.” We have to remind ourselves that, as engineers, we need to continue to expand our skills and knowledge, and be willing to try any job that needs attention. If everyone on the team assumes this attitude, the team will become more productive.

Here is the analogy that I think of when I am trying to explain this behavior. In the movie Apollo 13, after the initial oxygen explosion happens and disaster ensues, the mission commander asks that his team leaders to call in everyone on their teams to help figure out how to get the crew safely back to Earth. In the movie, teams that have not worked together are given hard problems to solve fast -- and they do solve them. This is the way very productive agile teams work together throughout the project.