A Product Manager’s Guide to Agile Software Development

Deciding to go agile is one thing. Implementing a truly agile process is another

Using an agile software development methodology is a no-brainer for any product manager who wants to produce better software as efficiently as possible. Among other things, it helps teams focus their efforts on the things that will provide the most value to customers.

But deciding to go agile is one thing. Implementing a truly agile process is another.

It takes discipline, teamwork, transparency and, above all else, true dedication to continual improvement. It also requires a process. This is where the agile methodologies come into play.

The two major agile software development methodologies in practice today are Scrum and Kanban. They provide constraints and guidelines to enable agile software development. They are both “lean” in the sense that they create more value for customers with fewer resources, however there are a number of differences between them I’ll discuss shortly.

But before I do that, let’s take a brief look at what it means to be “agile.”

What makes a team “agile”?

“Agility: the ability to quickly change direction while traveling at a high speed.” — Donald G. Reinertsen, Principles of Product Development Flow

A team is agile if they:

• Deliver working software frequently, in a sustainable manner
• Are focused on simplicity, technical excellence and good design
• Ship in smaller increments, so they gather feedback sooner
• Welcome changing requirements
• Hold daily meetings
• Are self-organizing (meaning they decide how to get the work done within the constraints of the process)

How does Scrum work?

• Work is completed in time-boxed “sprints.” The industry standard is two weeks.
• Defined roles: “scrum master,” “product owner” and “development team.” The scrum master is responsible for ensuring the rules of Scrum are followed. The product owner is responsible for prioritizing the backlog of work (split into what’s called “user stories”), as well as representing the end user and other stakeholders.
• Before each sprint begins, the product owner and team hold a planning meeting, where they negotiate which user stories will be “pulled” from the backlog and included in the sprint.
• Team commits to delivering a fixed set of user stories from the backlog at the end of a time-boxed “sprint.” This commitment can’t change mid-sprint; the only way to make changes is to end the sprint and start a new one.
• Team conducts daily meetings.
• Estimation isn’t required; however teams commonly measure a story’s relative size using “story points” (for example: Fibonacci sequence of 1, 2, 3, 5, 8, etc.) rather than time.
• Teams often benchmark their “velocity” using total points completed each sprint, thus improving their ability to predict delivery times.

How does Kanban work?

• Kanban means “sign board” in Japanese and is a scheduling system for lean production.
• Its goal is not to change your existing processes, but rather to visualize your existing workflow and expose areas for improvement (for example, bottlenecks).
• No prescribed iterations (in other words, sprints); the workflow is continuous. New work is “pulled” into the system when there’s capacity.
• No defined roles.
• Requires that you set an explicit upper limit for each step in your workflow.
• No prescribed planning event, however most mature teams conduct on-demand planning when there is capacity to select new items for development. Other teams conduct scheduled, recurring planning sessions.
• Estimation isn’t required; the focus is on predictability. However, teams often benchmark their performance by tracking “cycle time” for an average item (time from when you begin work on a item until it is completed). This focus on cycle time often leads to a reduction in batch size, which results in faster feedback and a reduced defect rate.
• Teams generally conduct daily meetings, however, it is not imposed.

The difference between Scrum and Kanban in practice

To demonstrate the difference between Scrum and Kanban, let’s take a look at how a team using each methodology would respond to a request from their stakeholders to build something.

I’ve used “stakeholders” to represent both internal stakeholders, the most influential of which are senior management, and external stakeholders, which includes the most important group of all: end users.

I’ve also assumed the Kanban team uses on-demand planning.

Finally, to keep things simple, I’ve represented stakeholders as making definitive demands at a particular point in time. Recall, however, that in an agile team, we welcome changing requirements. Thus, in reality, these demands take place in the context of a fluid, ongoing dialogue with stakeholders. If requirements were provided up front and never changed, then it would be a waterfall process, not an agile one.

Scrum

Stakeholders: We’d like you to ship A, B and C.

Product owner: Based on the value they will provide to our users, I have decided to rank the priority of these items in the backlog as C, B, then A.

Development team: Last sprint, we completed 15 story points. We estimate C is 10 story points, B is 5, and A is 3. So we commit to delivering C and B by the end of this sprint, two weeks from now.

Kanban

Stakeholders: We’d like you to ship A, B and C.

Development team: We just shipped two new items, which means there are two slots available in the “In Progress” column on our Kanban board.

Person or group responsible for prioritization: Based on the value they will provide to our users, please fill those slots with B and C.

As I noted above, there is no formal “product owner” role in Kanban. However, in my opinion, to create great products using Kanban, it is necessary to have a person or group fulfilling the product owner function. For this reason, I’ve included it in this example conversation. For further discussion, I recommend this article.

Final thoughts

An agile development process can do wonders for any team, but it’s not a silver bullet. Adopting an agile methodology, whether it’s Kanban or Scrum, doesn’t guarantee you’ll produce something customers will love. If you don’t put the necessary time into market research and strategic planning, it will simply mean you work on the wrong things faster.

Finally, it’s important to keep in mind that, when it comes to selecting an agile methodology, there is no right answer, and you should be cautious of anyone who tells you otherwise. Different methodologies or combinations of methodologies (for example, Scrumban) are going to work for different teams.

The most important thing is that you focus your energy on building a team that is truly committed to being agile. This may sound simple, but there is a huge difference between paying lip service to agile development and actually doing it. If your team is truly focused on solving customers’ problems in the most efficient way possible, then the sky is the limit.