A successful Agile development process has the potential to transform a waterfall development organization from slow, mammoth releases to quick iterative release cycle. Once an organization has a firm grip on Agile basics, moving from a yearly release cycle to a weekly build-release cycle is not unusual.
Making 50 quick releases instead of one big one has several advantages. The development team is able to release value faster by getting important features in early releases. They're also able to change directions quickly when the requirements turn out to be wrong or misunderstood, rather than working for a year toward the wrong goals. While these advantages are important, they're not easy to realize.
Many project managers struggle with the basics of the Agile methodology as they move from an established development process such as waterfall toward using more Agile methods. If you have questions, you're not alone. Here are some of the more frequent questions we've been getting about Agile development basics.
Who drives Agile planning, design and requirements gathering?
According to industry analyst and consultant Mary Gorman, the person who steps up and leads in an Agile organization could be any one of a number of people. It could be a Scrum Master, if the organization is a Scrum environment. It could also be a Product Champion that comes from the business side and uses intimate knowledge of the business to bring different teams with different micro focuses together to work at the intersection of the business, customer and technology needs.
No one section of that trifecta is the obvious choice for the leadership role in every instance. An effort to re-platform a particular product, Gorman says, might be led by someone on the technology side, while launching a new product or adding new features would likely point to a Product Champion from the business side. Still, it could be a QA person who steps up and announces that there's not enough information, that the testers need more detail.
An Agile effort is a team effort that might not require any one leader. "What's needed," Gorman says, "is a framework in which anyone on the team can feel comfortable in stepping up and either guiding the conversation, asking more pointed questions or offering insights."
Does bringing in Agile mean throwing out documentation?
One of the four major tenets of the Agile Manifesto is to value working software over comprehensive documentation. However, it's important to keep in mind the sentence below those four tenets. "That is, while there is value in the items on the right, we value the items on the left more." Many newcomers to Agile (and possibly some experienced practitioners) mistakenly think that comprehensive documentation is something to be avoided in Agile methods. That's simply not true, according to Ellen Gottesdiener, the founder and principle analyst of EBG Consulting.
Rather than asking if the Agile team should produce software documentation (because of course the answer is yes), project managers should be asking "which is the most valuable kind of documentation for your project and when is best to produce it," according to Gottesdiener. The team should differentiate between product documentation -- "a high-value asset for selling, servicing and using the product," --and process documentation -- "the work-in-progress or handover information you use during discovery and delivery."
Where do story points come into the picture?
The use of story points is a basic way to measure the length of long Agile projects that will likely undergo a good deal of change. When developers start into a new project -- especially if it's in a field they haven't worked in before -- it can be difficult for the team to estimate how long each piece of the project will take to complete. On the other hand, it's fairly easy for the team to gauge how complex a requirement will be to fulfill, relative to the other requirements. In general, that complexity will map fairly well to actual delivery times once the team has gotten some experience with the new project. Story points are a way to make those relative guesses concrete and measureable at the beginning of the project, so that future guesses can be more accurate and the team's progress can be gauged.
Although they're used in other Agile methods as well, story points are particularly useful in the Scrum process. Agile expert and certified Scrum master Yvette Francino explains the use of story points in planning out projects that are complex and therefore difficult to estimate. At the end of each iteration, the team will have a certain number of story points completed. This number is called the team's velocity because it measures how quickly the team is moving.
The velocity may fluctuate a bit at first, but it will generally level out and become more stable as team members and project managers get more comfortable with what story points mean for their particular project. Francino says the story point system may start with a WAG estimate, but that's better than getting bogged down with determining an exact timetable when the specifics of the requirements will change and evolve from iteration to iteration.
What should a project manager do when an Agile project gets stuck?
There's no boogey man gobbling up all the man hours or slowing down the development cycles.
Despite our best efforts, even experienced Agile aficionados occasionally have a project that just gets stuck in the mud. Somehow it seems bogged down by dark shadowy forces. But fear not. There's no boogey man gobbling up all the man hours or slowing down the development cycles. If a project manager shines a light on the problem project with a keen eye and the right signs in mind, it's not too difficult to weed out what's wrong and start things moving again.
Product management consultant Scott Sehlhorst explains how a root-cause analysis can jumpstart a stalled Agile project. If the project is stuck, he explains, that means either the team's not producing anything or else the team is producing the wrong things. If the team is producing steady work, but there's still no progress, Sehlhorst says it's time to examine the key performance indicators (KPIs). If the team building toward the wrong goals they can't end up with the right product. Sehlhorst tells us a common pitfall is that "many teams measure what is easy to measure instead of what is important to measure."
How can a single person successfully manage multiple Agile teams?
When a project manager leads a pilot Agile team to success within an organization, they're often tasked with leading more teams so the organization can see more of that Agile success. But leading an Agile team is a time intensive role that can be difficult to scale out to multiple teams. Still, it can be done. Seasoned tester and experienced team lead Amy Reichert explains that the secret to successfully managing time when split between multiple teams is eliminating any outside distractions.
If a Scrum Master is going to lead two or more teams, Reichert suggests, she has to be focused only on the requests that come up from inside those Agile teams. Anything else, even a project that would improve the Scrum Master group, will take time and focus away from the teams she's leading. Some might say that minimizing distractions should be enough, but Reichert says that any one distraction will open the door for more distractions. Each distraction on its own won't affect the Scrum Master's ability to see to her team, but twenty such distractions piled on top of each other will ruin her ability to support multiple teams effectively.
This was first published in June 2013