In this series by organizational problem-solving expert Johanna Rothman, uncover the mystery behind agile project management. What is it? How does it apply to your workplace each day? Why should you be looking for technology candidates with agile experience? See how separating decisions, prioritizing projects and tackling one thing at a time produces a smoother, more ‘agile’ process in tech.
Part 1 in Dice's Agile Series You've heard about agile project management. As an HR professional or recruiter, you're supposed to source professionals with agile experience. It's the "in" thing these days for software development. But what exactly is "agile?" The Origins of Agile
For years, technology teams tried to manage software development as if it was just like a traditional engineering project. But software is ephemeral, and software is a design process, not a manufacturing process. Software doesn't fit traditional engineering models well. For example, when building roads or houses: you can estimate them by the mile or the square foot. But software? Even the most sophisticated models are off by 20-400% at the very beginning of the project. You have to iterate, regardless of the project life cycle we use. Andy Hunt, in his Pragmatic Thinking and Learning, postulates that software projects are the most challenging work that people have ever attempted. No wonder traditional project approaches didn't work! But that didn't mean software projects can't be managed. In response to the problems of thinking like software as civil engineering, many teams have decided to consider agile as a new way of doing business. The Two-Minute Introduction to Agile Here is your two minute introduction to agile. In agile, a cross-functional team, composed of all of the roles required for a project come together and produce a small chunk of potentially shippable product. The team then demos the chunk of work, asking for feedback. They do this again and again and again. Do a little work, get a little feedback. The small chunks are the increments. The team works in iterations, specific time boxes of a fixed duration. That's the iterative part. How do they know what to produce? They have guidance from either their customer or a product owner. That responsible person ranks the features in a backlog. The team works off this backlog. Only the product owner or customer can rank the features in the backlog for an iteration. Anyone can add to the product backlog before the iteration starts. But, once the iteration starts, only the product owner can decide on the contents of the iteration. In agile, you separate the decisions of what gets done from how the work gets done. The product owner decides what gets done. The team decides how to do the work.
Common Approaches to Agile You'll hear many teams say "We use Scrum," or "We use two-week iterations." Scrum is a very common approach to agile. It has a specific role, a Scrum Master (who is not a project manager), who facilitates the team's process, and helps the team plan the iteration, gather the team's metrics, and clear the team's impediments. The Scrum Master makes sure the team has a standup meeting every day where the team makes micro-commitments to each other. These rituals work well for a 5-7 person geographically collocated team and would be difficult for a larger or a distributed team. Agile Builds Trust Why do teams transition to agile? Agile approaches build trust. When product owners or customers see demos or a releaseable product every week or two, they start to trust the team that builds the product. In turn, the team that builds the product trusts the product owner or customer to write requirements that are small enough for the team to implement in a short time. When you start trusting each other, great things can happen. You don't need to define all the requirements up front. Instead, you can let the requirements evolve. You don't need to define the architecture up front. You can shepherd the architecture, evolving it. Why This Matters You've heard about the "software crisis" for years, right? That software projects are late, over budget, and don't meet their requirements? We've had Chaos Report after Chaos Report tell us that. Or maybe you've been on a project where you asked for something and the team delivered what you asked for, but it wasn't what you needed. Agile is not a silver bullet. However, when the people who create the requirements (product owners) work directly with the cross-functional teams who build the software, and quickly iterate to release small chunks of business value, it now changes the equation. All of a sudden, desired dates are met. Instead of throwing all kinds of requirements at a project and hope that some of them stick, a team has the opportunity to work in business value order. That means product owners have to make difficult decisions, constantly throughout the project. That's hard. And, necessary. And, worth it to the project. Because what happens? The team starts to meet milestones. And, the team releases the product at frequent intervals. All of a sudden, projects start to come in on time---maybe even early!---and because many teams have many automated tests and other built-in quality mechanisms, their defect levels are quite low. These products look great and they work. The projects don't need lots of long testing after the development is done. No more software crisis. Where We Are When software teams successfully transition to agile, they are able to release valuable chunks of work rapidly. These chunks of work are small. Because the chunks of work are small and the team completes the work in rank order of business value, the product owner can change his or her mind. Agile is not really about speed of delivery per se, it's about the ability to change. When a product owner or a customer sees the chunk under development, and can see what the team is delivering, the product owner can say, "I see what you are doing. I know I asked for that. Nuts, that's not going to cut it. Oh boy. Let's do some brainstorming about what I really need." Now, if a team has spent six months on a feature, they aren't going to be happy about brainstorming. But six minutes? They will be happy to spend an hour working on it. Even if they've spent six hours total, they will be happy to spend more time to get it right. Project teams want to get the requirements right. They also want the right requirements, and there are agile approaches to do that. Conclusion: Start Small We’ve taken a look at what a small team can accomplish using micro-goals in short blocks of time, and how that method of breaking up the bigger picture is proving to be a very valuable tactic for tech productivity. However, moving to a program – that is, a collection of projects – is totally different. If you have to recruit for a program manager, we'll discuss that more in-depth in a future post. In the next post, we’ll take a look at how agile actually works and how long agile-based projects take.
Agile Terminology Acceptance criteria: How you know the user story will be accepted. Backlog: The product backlog is the entire list of features for the product. The iteration backlog is ranked list of features for the next iteration. Iteration: A specific timebox. For agile projects, that time is normally one to four weeks. Many agile teams work in a one or two-week iteration. Product Owner: The one responsible person who ranks the features for the next iteration. Timebox: A specific amount of time in which the person will attempt to accomplish a specific task. User story: A way of defining requirements, primarily used in agile projects, focused on a specific user, not the system. To read more about agile, see the Agile Manifesto.
Part 1 in Dice's Agile Series You've heard about agile project management. As an HR professional or recruiter, you're supposed to source professionals with agile experience. It's the "in" thing these days for software development. But what exactly is "agile?" The Origins of Agile
For years, technology teams tried to manage software development as if it was just like a traditional engineering project. But software is ephemeral, and software is a design process, not a manufacturing process. Software doesn't fit traditional engineering models well. For example, when building roads or houses: you can estimate them by the mile or the square foot. But software? Even the most sophisticated models are off by 20-400% at the very beginning of the project. You have to iterate, regardless of the project life cycle we use. Andy Hunt, in his Pragmatic Thinking and Learning, postulates that software projects are the most challenging work that people have ever attempted. No wonder traditional project approaches didn't work! But that didn't mean software projects can't be managed. In response to the problems of thinking like software as civil engineering, many teams have decided to consider agile as a new way of doing business. The Two-Minute Introduction to Agile Here is your two minute introduction to agile. In agile, a cross-functional team, composed of all of the roles required for a project come together and produce a small chunk of potentially shippable product. The team then demos the chunk of work, asking for feedback. They do this again and again and again. Do a little work, get a little feedback. The small chunks are the increments. The team works in iterations, specific time boxes of a fixed duration. That's the iterative part. How do they know what to produce? They have guidance from either their customer or a product owner. That responsible person ranks the features in a backlog. The team works off this backlog. Only the product owner or customer can rank the features in the backlog for an iteration. Anyone can add to the product backlog before the iteration starts. But, once the iteration starts, only the product owner can decide on the contents of the iteration. In agile, you separate the decisions of what gets done from how the work gets done. The product owner decides what gets done. The team decides how to do the work. Common Approaches to Agile You'll hear many teams say "We use Scrum," or "We use two-week iterations." Scrum is a very common approach to agile. It has a specific role, a Scrum Master (who is not a project manager), who facilitates the team's process, and helps the team plan the iteration, gather the team's metrics, and clear the team's impediments. The Scrum Master makes sure the team has a standup meeting every day where the team makes micro-commitments to each other. These rituals work well for a 5-7 person geographically collocated team and would be difficult for a larger or a distributed team. Agile Builds Trust Why do teams transition to agile? Agile approaches build trust. When product owners or customers see demos or a releaseable product every week or two, they start to trust the team that builds the product. In turn, the team that builds the product trusts the product owner or customer to write requirements that are small enough for the team to implement in a short time. When you start trusting each other, great things can happen. You don't need to define all the requirements up front. Instead, you can let the requirements evolve. You don't need to define the architecture up front. You can shepherd the architecture, evolving it. Why This Matters You've heard about the "software crisis" for years, right? That software projects are late, over budget, and don't meet their requirements? We've had Chaos Report after Chaos Report tell us that. Or maybe you've been on a project where you asked for something and the team delivered what you asked for, but it wasn't what you needed. Agile is not a silver bullet. However, when the people who create the requirements (product owners) work directly with the cross-functional teams who build the software, and quickly iterate to release small chunks of business value, it now changes the equation. All of a sudden, desired dates are met. Instead of throwing all kinds of requirements at a project and hope that some of them stick, a team has the opportunity to work in business value order. That means product owners have to make difficult decisions, constantly throughout the project. That's hard. And, necessary. And, worth it to the project. Because what happens? The team starts to meet milestones. And, the team releases the product at frequent intervals. All of a sudden, projects start to come in on time---maybe even early!---and because many teams have many automated tests and other built-in quality mechanisms, their defect levels are quite low. These products look great and they work. The projects don't need lots of long testing after the development is done. No more software crisis. Where We Are When software teams successfully transition to agile, they are able to release valuable chunks of work rapidly. These chunks of work are small. Because the chunks of work are small and the team completes the work in rank order of business value, the product owner can change his or her mind. Agile is not really about speed of delivery per se, it's about the ability to change. When a product owner or a customer sees the chunk under development, and can see what the team is delivering, the product owner can say, "I see what you are doing. I know I asked for that. Nuts, that's not going to cut it. Oh boy. Let's do some brainstorming about what I really need." Now, if a team has spent six months on a feature, they aren't going to be happy about brainstorming. But six minutes? They will be happy to spend an hour working on it. Even if they've spent six hours total, they will be happy to spend more time to get it right. Project teams want to get the requirements right. They also want the right requirements, and there are agile approaches to do that. Conclusion: Start Small We’ve taken a look at what a small team can accomplish using micro-goals in short blocks of time, and how that method of breaking up the bigger picture is proving to be a very valuable tactic for tech productivity. However, moving to a program – that is, a collection of projects – is totally different. If you have to recruit for a program manager, we'll discuss that more in-depth in a future post. In the next post, we’ll take a look at how agile actually works and how long agile-based projects take.
Agile Terminology Acceptance criteria: How you know the user story will be accepted. Backlog: The product backlog is the entire list of features for the product. The iteration backlog is ranked list of features for the next iteration. Iteration: A specific timebox. For agile projects, that time is normally one to four weeks. Many agile teams work in a one or two-week iteration. Product Owner: The one responsible person who ranks the features for the next iteration. Timebox: A specific amount of time in which the person will attempt to accomplish a specific task. User story: A way of defining requirements, primarily used in agile projects, focused on a specific user, not the system. To read more about agile, see the Agile Manifesto.