Having already discussed unit testing, continuous integration, and user stories (among other terms,) here are my final  Agile methods, defined: Velocity, Estimation using Planning Poker and Burnup Charts.

Agile Method: Velocity

The velocity of a team is simply the number of story points associated with stories that are finished over a given period of time, often 1 to 4 weeks. For instance, if the team completed 8 stories that were each 5 points during a four week period, then their velocity is 40 story points every four weeks. In a stable team, a team that is comprised of the same individuals working full time as part of that team, the velocity is a good measure of the overall throughput of the team.

Knowing your velocity helps with planning. For example, if you know that the velocity of your team is 40 points every four weeks, and you have 200 points worth of stories for a release, then you know it will take that team approximately 20 weeks to complete that release.

Agile Method: Estimation Using Planning Poker

Planning Poker is an estimation technique first described by James Grenning in 2002 in a paper by the same name. When I first heard about Planning Poker, I couldn’t help but chuckle. It seemed a bit silly to mix software development and poker. It wasn’t until I actually used it that I experienced its value. You may have a similar reaction. I would encourage you to invest the couple of hours it will take to do a trial run.  You will be surprised.

One of the biggest benefits of Planning Poker is the sense of team that it creates. The whole team is participating in the estimation. This creates a greater sense of team ownership and team responsibility for each story. Another major benefit of Planning Poker is that you leverage the collective wisdom of the whole team.

Planning Poker reminds everybody that the estimate includes all of the work that needs to be accomplished in order for the story to be considered done. It includes development, testing, documentation, and anything else required for completion. It also acts as a reminder that you are part of a cross functional team, and that nobody on the team gets credit for a job well done until the whole story crosses the finish line.

Agile Method: Burnup Chart

A burnup chart graphs the progress of getting stories done over time. The X axis is time and the Y axis is accumulated story points completed during that time. For instance, if the team finishes a story with 3 points on Tuesday and a story with 5 points on Thursday, the chart for the week, showing Monday through Friday, would display 0 for Monday, 3 for Tuesday and Wednesday and then 5 for Thursday and Friday. By using a longer time frame and drawing a line representing expected velocity, you can see how a team is progressing over time. If the number of story points accumulated is not matching the velocity, you know there is a problem and you can start asking questions such as “why aren’t any stories getting completed?”

Next Steps

You can read more about all of these practices on my blog and you can also browse our resources section. Many of these practices can benefit from modern tooling. Tools which support both Agile and traditional software development environments are the tools which are most likely to provide direct support for these practices, especially in a hybrid development environment. Look for tools that support both traditional concepts as well as Agile SCM, Agile Project Management, and Continuous Integration. There are also many classes available to learn more about Agile, Scrum, etc. If you are interested in taking a deeper look at the benefits of Agile or hybrid tooling or training, browse our web site to learn more, or contact us to start a conversation.

In the last few posts I have discussed some of, what I consider to be, the most valuable Agile methods for development.  The list is pretty long, so breaking the list up allows me to define each practice and include the individual benefit of each Agile method.  This post defines some hot terms right now- continuous integration, multistage continuous integration, and story points.  Enjoy!

Agile Method: Continuous Integration

How frequently have you merged your code with changes from the mainline, only to find that the result doesn’t build, or it builds but it doesn’t work? Monthly? Weekly? Daily? Hourly? Or worse, how often have you made changes that broke the build, requiring you to quickly correct the problem while getting flames from your team members?

A practice that has emerged to address the problems of integration is called Continuous Integration. The basic idea is that if integrating changes together and getting build and test results on a regular basis is a good idea, integrating and getting build and test results on every change is even better.

With Continuous Integration, all work from all teams is integrated into a single codeline as frequently as possible. Every check-in automatically triggers a build and usually a subsequent run of the test suite. This provides instant feedback about problems to all interested parties and helps to keep the code base free of build and test failures. It also reduces the integration headaches just prior to release.

Agile Method: Multi-stage Continuous Integration

Integration is tough enough when you are just integrating your work with the work of other folks in your small team, or the whole effort is being done by a small team, but when you are part of a large team there is also something called “Big-Bang” integration. That’s the integration of the work that multiple teams have been working on for long periods of time. In a typical project, this integration is done in a phase toward the end of the project. During integration, many problems are discovered for the first time which leads to delays and/or changes in scope.

The real question is, what is a good way to structure this integration so that it will scale smoothly as you add more people to the equation? A good starting place is to look around for a pattern to follow. What are some similar situations? I have found that everything your organization needs to do in order to produce the best possible development organization can be entirely derived from the patterns and practices at the individual level. This approach makes it much easier to understand and much more likely that it will be successfully followed.

As individuals we work in transient isolation to reduce the impact of work in progress on each other. Organizations isolate WIP by using only official versions of 3pty sources and by producing official releases for customers.

Multi-stage continuous integration (MSCI) scales CI to large distributed environments by isolating work in progress at the team level. Changes move from individual to team to mainline as fast as CI allows, but stop on failure. MSCI is particularly important in a distributed environment where fixes to problems exposed by CI can be delayed by a full day

Agile Method: Using Story Points For Estimation, Instead of Units of Time

In my experience, the best unit to use for estimates is story points. Two different people with two different skill sets or levels of ability in an area may take different amounts of time to perform a particular task. Estimating in hours mixes together the scope of the work that needs to be done with the speed at which a particular individual can do that work.

On the other hand, story points are a relative measure of the scope of a user story. Story points separates out the “what” from the “who.” For instance, if you have one individual that is stronger with .Net than with Java, they will estimate a Java story as taking more hours than somebody that is stronger with Java. But they will probably both agree that something that is twice as easy to implement will take half as long to do.

To use story points, you need to create a relative scale of scope. A simple approach is to find a simple and straightforward story that you use to represent a single story point. Then think of stories that are 2, 3, 5, and 8 times larger in scope. You should have a couple of examples for each story point value to take into account that some stories have more test than coding, more documentation than test, etc.

Story points are primarily used for planning, not for implementation. Story points are used to help determine the contents of release by calculating a velocity.

Next up: Backlog, velocity, planning poker and burnup charts.

In the last post I defined two Agile software development best practices I believe provide value to a wide variety of development teams.   Here I define three more practices that I believe are also important when transitioning to Agile Software Development; collocation, unit testing, and refactoring.

Best Practice for Agile Software Development: Collocation

Collocation is simply having everybody on a cross functional team in close proximity to each other. This compounds the coordination benefit of cross functional teams. This is orthogonal to outsourcing. Whether you are outsourcing or not, collocation only refers to whether a particular cross functional team is sitting near each other.

Best Practice for Agile Software Development: Unit Testing

Unit tests are simply tests that exercise small amounts of isolated functionality. That is, if you have a function that adds two numbers, instead of depending on running a user function that eventually calls the function, exercise the function directly. This often requires the use of mock objects that pretend to be things that the function needs in order to test the function in isolation from other functions that it depends on.

The cost of unit tests is in writing the tests themselves and refactoring code as new functionality is introduced to keep the unit tests testing at the right level. The benefit is that you can easily test changes quickly to find simple problems before doing more thorough and slower testing. It also provides a good safety net for refactoring, gets developers more involved in testing, and usually improves the design of the software.

Best Practice for Agile Software Development: Refactoring

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. That makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code. Any change has the potential to reduce the maturity and stability of the product, especially if you don’t have adequate testing in place. That’s why refactoring is usually paired up with unit testing and together these are frequently combined with continuous integration.

Over the past ten years, a number of Agile software development process “guidelines,” or best practices, have formed and are now becoming widely adopted.  Terms used to describe these best practices are sometimes new to developers, so I defined the practices that I believe provide the most value to a wide variety of development teams in order to create a highly functional, unified software development process.  I have by no means compiled a full list, but over the next few posts I will introduce you to some ideas that you may find worthy of further investigation.

Agile Software Development Process: User Stories

Consider the following requirement and sub-requirements.

• 3 Simplified Purchasing

• 3.1 Customer Identification
  • 3.1.1 A web “cookie” shall be used to uniquely identify visitors
  • 3.1.2 Each customer shall be associated with a cookie
  • 3.1.3 Cookies shall be stored in an RDBMS
• 3.2 Sale presentation
  • 3.2.1 Each item for sale shall have a button marked “buy” next to the item
  • 3.2.2 Selecting the “buy” action shall trigger an order placement action
• 3.3 Fulfillment
  • 3.3.1 By default, all orders shall use the on-file default shipping information
  • 3.3.2 If available, all orders will use the customer’s default payment method
  • 3.3.3 It shall be possible for the customer  to cancel any order for up to 4 hours after they place that order.

This set of requirements is for something called “simplified purchasing.”  Take a moment or two to consider how you would sum it up in a single plain-English sentence.

The requirements called “simplified purchasing” describe the user’s desire for “one-click purchasing.” In terms of a user story this would be phrased as “As a user I want one-click purchasing.” User stories are a description of what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome.

User stories are different than requirements. When using requirements, it is likely that the developer implementing the requirement will be presented with an implementation task or a design document and be constrained to implementing as specified or as designed. A user story removes invisible constraints by focusing on the outcome desired by the user. The developer doing the work will see the user story, will be able to better understand what the user needs, and will be able to participate in or even own the specification and design of that story. User stories provide engineers more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

A user story does not necessarily replace requirements documents or other documents. A common scenario is that the user story is the unifying high-level description for the work that needs to be done to make sure that everybody involved has a common understanding of the work, from customer to developer to tester to doc writer and back to the customer.

Agile Software Development Process: Cross Functional Teams

A cross functional team is a small group of people (7 + or – 2) that works together towards a common purpose, where time is primarily spent as part of the team, and, as a team, has all of the skills needed in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, project manager, etc. The intended benefit is that you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects.

Next best practices I will explore? Collocation and Unit Testing.

AccuRev has been down in Orlando at Agile 2010 for almost a full week now, and if you haven’t stopped by the booth to say hello to us yet, I encourage you to do so!

Damon Poole, AccuRev CTO, wrapped up a series of three Agile sessions today, and was pleased with the outcome.

“I think the sessions went really well, people were excited for them, I was excited for them, but ultimately I hope everybody learned something valuable” said Damon.

His presentations were titled “Scrum and Kanban- Like Chocolate and Peanut Butter,” “Getting Managers and Agile Teams Out of Each Others Hair,” and “Managing Growth Pains on the Way to 40 Scrum Teams.” (See “Three Days with Damon Poole on Agile Development and its Components” for more info).

Damon’s first session at Agile 2010, “Scrum and Kanban- Like Chocolate and Peanut Butter,” attracted a large crowd, and unfortunately several people were turned away.  But as he promised, we are posting all of his presentations in the AccuRev blog.  You can download Damon’s presentation of  “Scrum and KanBan- Like Chocolate and Peanut Butter” here.  Enjoy!

AccuRev hosts educational Agile methodology seminars called “Agile Comes to You,” which reach audiences nationwide and focus on teaching best practices of Agile software development.  The seminars have been quite successful, and regardless of their organization’s level of Agile adoption, I know attendees have learned some great information from these sessions.

AccuRev doesn’t host the Agile methodology seminars alone, and generally presents in conjunction with partners Rally Software, Urbancode (the makers of AnthillPro), and Coverity. The seminars consist of a keynote with extensive Agile experience, educational presentations, and a short tools demonstration. The format has been so successful that we have used it for over a year, and you might even notice similarly-formatted seminars from other organizations as well. (Imitation is the most sincere form of flattery, right?)

The Agile Methodology Workshop

We try to focus on making our seminars as educational and relevant as possible by giving attendees access to the real life Agile experiences that presenters bring to the table.  So in addition to presentations focused on benefits of the Agile methodology and best practices, we came up with the concept of an “Agile Workshop.”

The Agile Workshop  allows each attendee to discuss their most difficult challenge in transitioning to Agile with other attendees in small groups, as well as with our Agile experts.  We do this for two reasons:

1) It gives the attendees a chance to exchange thoughts and solutions regarding their Agile migration.

2) It allows the attendees to interact with the panel of experts on how to solve these difficult challenges.

Once the group has discussed the challenges each individual faced during a transition to Agile, they then agree upon a top challenge that they ask the panel of Agile experts to comment on and offer advice.

For example, at a recent seminar in Toronto, this was the attendees list of top challenges:

We have been seeing this same pattern across most of our seminars, and I believe it gives us good insight into the state of Agile adoption.  It is amazing to see that even across very different organizations, the challenges that arise with Agile adoption are remarkably consistent from seminar to seminar.  It seems that no matter who you are, or what stage of Agile adoption you are in, many are facing the same challenges when moving towards Agile development. There is some comfort in numbers, knowing that you are not alone in facing hurdles.

While I won’t take the time to answer every one of these challenges here today, I plan on commenting on each one of these issues in the coming months, in hopes that sharing my experiences and alternatives help you in solving these difficult problems.  I would also like to invite some of our Agile experts, as well as our attendees, that are internal to AccuRev or our partners to comment or blog on some of these topics to share some of their experiences.

While the “Agile Comes to You” tour is taking a short break for the summer months, be sure to look for us in your city this September or stop by and visit us at Agile 2010 Conference in Orlando.  Have a great summer!

While many experts push for Agile adoption throughout organizations, a different trend within organizations is emerging.  Organizations are taking smaller steps towards Agile by focusing on specific Agile techniques and applying them to their individual development processes. By adopting certain techniques, organizations still receive some benefits of Agile without “going Agile”.  After all, it is possible to do Continuous Integration without time-boxing and still reduce integration problems.

Getting Benefits of Agile Software Development

For those interested in gaining the benefits of Agile through smaller and more targeted techniques, there are a number of possibilities.  Below are recommended readings on Agile techniques, each focusing on one specific area, while detailing the processes and outlining the benefits.  Here is a great place to start when looking to gain the benefits of Agile software development.

User Stories Applied: For Agile Software Development, by Mike Cohn.

The Agile equivalent of requirements is User Stories, and this book is the definitive guide to creating and using them.  Readers will not be disappointed with Mike Cohn’s practical advice on User Stories, as the information offered is easy to read and apply. Valuable topics discussed include why to use User Stories, when they are appropriate, and how to monitor progress.

Continuous Integration: Improving Software Quality and Reducing Risk, by Paul M. Duvall, Steve Matyas and Andrew Glover.

This is a great resource for Continuous Integration. The authors stress the importance of integrating early and often using CI practices and provide detailed results of a successful CI implementation (including reducing risks, better visibility and reducing repetitive manual processes). Another important element of this book is its companion Web site, www.integratebutton.com, which provides updates and code examples.

The Art of Unit Testing: With Examples in .Net, by Roy Osherove.

This is one of the best on the topic of Unit Testing, partly because of RoyOsherove’s experience and passion about the subject, and partly because of his practical delivery. His book covers important areas of Unit Testing, including writing maintainable test code, code review and adopting Unit Testing in an organization.

Refactoring: Improving the Design of Existing Code, by Martin Fowler, Kent Beck, John Brant, & William Opdyke

This book offers important technical insight into the process of changing code to improve internal structures without changing external behavior and is a highly recommended resource on refactoring and improving design of existing code.

To get more benefits of Agile without going Agile, try JUnit Recipes: Practical Methods for Programmer Testing by J.B. Rainsberger, and Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck or visit AccuRev’s Agile Resource Center.

When we think of hybrids, we generally think about cars and going green.  There are also a handful of other hybrids that come to mind, hybrid bicycles, hybrid golf clubs, and even hybrid dogs (this was a new one to me…).  In general, hybrids are the union of two similar functions that have a different focus combined to do one thing really well, meant to give you flexibility and adaptability without sacrificing quality.  Let’s take a hybrid golf club for example; it’s a combination between a fairway wood and a long iron. It gives you the ability to hit a golf ball long distances with pinpoint accuracy, and often from a tough lie.  The best of both worlds.

So how does this apply to adopting Agile across the enterprise?

Real World Agile as a Hybrid Process

Well, let’s say that we’ve already gone through and had a successful Pilot Team, and now we’ve started to scale Agile across the enterprise.  As this process begins to take shape any large organization will likely have a mixture of teams; some that already adopted Agile, some that may be in the process of migrating to Agile, and others still running a more traditional (waterfall) approach to software development. You may also find organizations that will always have a need to use the traditional approach. Many of the Agile purists out there may not agree, but there will likely always be projects or products that people feel are not a good fit for this methodology. Having these two processes coexist seamlessly in your development organization would fit the definition of a “Hybrid.”

With that in mind, the ability to support a Hybrid Process, or a term we’ve used lately – Real World Agile, is extremely important to being successful at your Agile implementation. We see this impacting three areas of your Agile adoption:

• Support ongoing waterfall development alongside Agile development
• Support transitioning to Agile as adoption spreads across your enterprise
• Support changes to your Agile methodology as you inspect and adapt

So let’s talk about each one of these in a bit more detail.

Supporting two different development methodologies requires the ability to enforce a structured, traditional, waterfall approach while also being able to adapt to a more dynamic Agile approach.  In order to deliver a single product, this requires parallel support for the methodologies of both teams. Facilitating the integration of stories from the Agile team and integrating that with the code from the traditional team are necessary for this delivery. You must also be able support the tools that support both of those methodologies; for example a newly implemented Agile project management tool and an in-house issue tracking system, coexisting in this heterogeneous environment.

To aid in the transition to Agile, we also need flexibility to migrate a traditional development team and their traditional process to an Agile development methodology cleanly, quickly and easily. Taking them off a very restrictive branch and label-based tool, which might put constraints on how they are implementing your process is going to impact and impede that adoption from an Agile methodology perspective.

Lastly, we’ll need an ability to support a variety of processes with multiple development staging areas to accommodate work-in-process, code reviews, testing, and accepted work of the Agile team. Each one of these staging areas will need continuous integration functionality, one of the practices adopted very early in the migration to Agile. And as we know from one of the key Agile principles, inspect & adapt, we need to be able to change this process as we decide what works and what doesn’t work during our retrospectives.

Support for all three of these process variations will not only determine how easy or how difficult your migration to Agile goes, it may very well determine the success of your Agile adoption across the enterprise. And as the use of Agile methodologies continue to expand throughout the industry, the need to support a hybrid process inside organizations will become more prevalent. Without the proper principles, practices, and tools, the methodologies of Agile and waterfall will not coexist as seamlessly as the functionality of my #4 Hybrid club. Fore!

Amazing fact: The lookout crews for the RMS Titanic were without binoculars. Due to a last minute change in personnel, the team member who was in charge of spyglasses, binoculars and other optical equipment was not on board the ship, and all of this equipment was unfortunately locked away, crew members unaware of the location.

We all know the rest of the story; by the time that the lookout crew saw the iceberg, the opportunity to change course already passed.  There was not enough time for the crew to respond to the problem and correct it. They had no visibility (literally).

Agile is about adaptation. It’s not about sticking to the plan; it’s about exposing and responding to change in your development cycle. But how can you respond to problems if you don’t know what they are?

Our last blog post was about “inspecting and adapting”, and I don’t want to get these 2 success factors confused. The real point that I’m trying to get across is that visibility in an Agile environment allows your teams the ability to inspect and adapt to impediments.

Why is Visibility in an Agile Environment Important?

Information in an Agile environment is viewed more often, and scrum teams  need to see this information on a daily basis in order to change course if necessary. Visibility in an Agile environment allows teams to use information in their stand-ups, sprint reviews, demos and retrospectives.

Visibility also needs to happen on a large scale, and everyone needs to be involved. Just think, if we gave only one pair of binoculars to the entire look-out team on the Titanic, it would have been much less effective than if each team was equipped with the proper visibility gear. Everyone needs to be aware of the problem in order to change courses.

But here’s the real trick. Centralize this information, make it visible to everyone and all your tools.  If you do this, you can integrate with all of your processes. This guarantees the information in the tools is correct. For example, if you have an integration in your SCM tool to your project management tool, you can see what changes correlate to what iteration, guaranteed. You can also integrate your build, test and deploy tools to provide tractability on all levels of the stack. Centralization also provides a single place where everyone can see what’s happening. Scattering the information against multiple tools that aren’t “Agile aware” will only confuse the process.

So having a global visibility can help re-route a ship that’s traveling on a disastrous course. It can also help your development teams change course when they need to.

Wouldn’t it be beneficial to get your whole team some binoculars?

Way back in my first job out of university, I was working in Washington, DC, as a Navy contractor, helping manage changes to an electronic countermeasures system.  Ah, those were halcyon days, when I was young and innocent green and scared of my own shadow.  There was this one person I had trouble getting along with, not so much because he was a mean person, but mostly because he would make wild statements and push the team in directions that didn’t seem logical to me.  Sometimes, he would advocate for decisions that seemed to me obviously to be bound for failure.  He was overbearing and he was old.

(Actually, he was about the same age I am now; a disturbing thought as I look back.)

Because he was old and I was uncertain, I couldn’t bring myself to disagree with him out loud.   I eventually was able to describe the situation to my boss, who responded with a statement that has never left me.  He said, “There are people who have 20 years of experience, and there are people who have one year of experience repeated 20 times.”

Culture of the Agile Process

The big difference between the two kinds of people is that the latter have lived their lives, reflected upon the things they’ve gone through, and learned from it all.  We often talk about Agile processes as being “empirical.”  What I mean when I say that is a team makes its commitments, and structures its delivery model around reality.  We don’t commit to delivering five times more in the next week than we’ve ever delivered in a week before.  We don’t abandon a practice just because we’re bored with it.  But the only way this reality-based planning and execution can work is if we go back and look at the reality we’ve experienced, review what worked and what didn’t and work to enhance the former and minimize the latter.

An excelling Agile team is continuously improving, and to do this it must be continuously inspecting.  We expect scrum teams to perform retrospectives at the end of every release and at the end of every sprint.  I encourage teams to also get into the swing of considering that every morning’s answer to the questions “what did I do yesterday?” and “what am I going to do today?” includes the implicit assumption that reflection on what you did yesterday informs what you are going to do today.  I am advocating for daily retrospection.

In rolling out Agile, foster a culture of continuous examination of what you are doing weighed against what you are trying to accomplish.  In addition to encouraging review of sprints and releases, continuously review your roll-out itself.  As you roll out new processes, regularly hold retrospections with the teams that are implementing and being affected by the roll-out, so that you can learn from their successes and help other teams avoid their mistakes.

Inspect and Adapt

The buzz phrase for this kind of behavior is “Inspect and Adapt.”  I see a lot of teams go through the motions of inspecting, but many of them don’t follow through with the second part.  Don’t bother to inspect something if you aren’t prepared to act upon the results.  An extended gripe session is nice to let off steam, but a team isn’t going to be enthusiastic about returning to the same old gripes sprint after sprint after sprint.  This is what happened to “lessons learned” meetings in the olden days: somebody diligently wrote up a report about the things we supposedly learned and then tossed the result in a filing cabinet and we would return at the end of the next project with exactly the same complaints.  When you are leading a team through retrospection, be prepared to act on the results (and make sure the team is empowered and resolved to act, as well).

However, if we come out of the retrospection with a prioritized backlog of improvement, we can plan that improvement into our practices and pull items off the backlog as we implement solutions.  We can all make commitments to the non-development activities that might be necessary to make our environment a better place.   If the backlog seems like it is filled with impossibly large problems, well, what do we do when stories are too big for our sprints?  We break them down.  Encourage the team to think of the smallest possible change they could make to improve their process.  Then encourage them to break that down smaller.  Then implement that first.

In this way, we can start being a team that has experienced 20 sprints instead of team that has experienced one sprint 20 times.