Q&A on The Agile Developer's Handbook

The book The Agile Developer’s Handbook by Paul Flewelling provides the fundamentals of agile and explores intermediate and advanced topics like metrics for delivery, technical practices, delivering value, team dynamics, building quality in, and becoming an agile organization. 

InfoQ readers can download a sample of the Agile Developer's Handbook. 

InfoQ interviewed Flewelling about applying agile frameworks, doing team liftoffs, defining success with metrics, breaking away from a culture of accepting bugs as the norm, walking through Tuckman's stages of team formation, new agile practices and principles that could become more prominent in the coming years, and benefits to quality which can arise from the practice of mob programming.

InfoQ: What made you decide to write this book?

Paul Flewelling: In my job as a coach I’ve worked with many teams. There’s a tipping point where the team transitions from “doing” agile to “being” agile; for each team it’s different. My aim with the book was to lay out this journey a little. There are many paths to an agile mindset; the hope is this book will help a team find theirs.

InfoQ: For whom is this book intended?

Flewelling: The book is roughly divided into three sections: the first half is for the beginner, and the second half looks at intermediate and advanced topics. Teams who have just started on their journey will benefit most from the first half. Team which have plateaued or want game changing ideas to take them to the next level will benefit from the the second half. To be honest everyone will be benefit from a better understanding of the fundamentals.

InfoQ: The first part of your book explores the Agile Manifesto and the frameworks Scrum, XP, Kanban and Lean. What are the major differences between the frameworks when it comes to implementing agile, and how does that impact the way that you apply them in organizations?

Flewelling: In a nutshell, Scrum and XP both use iterations which are a timeboxed amount of work, measured in weeks. A Scrum or XP team will focus delivering an increment of working software at the end of each iteration. The work is planned at the beginning of the iteration with the intention of creating an environment where the team is able to focus on a chunk of work with a minimum of disruption and interruption. 

Kanban doesn’t use iterations, instead the focus is on the continuous flow of work items through the system. With Kanban, increments of working software can happen at anytime, and practitioners will seek to deliver value with every user story. It offers more flexibility because priorities can shift from user story to user story. But it also requires discipline in order to develop a coherent feature set if using it for product development.

As a result, most organizations will use Scrum or XP to develop products, whereas Kanban is often used by teams who have to be more reactive (shifting priorities), such as operations teams. That said, Kanban can be used to great effect for product development because feedback loops can be much shorter; we don’t have to wait until the end of an iteration to review the working increment of software. With Kanban we can and should review it any time. 

The second major difference is Scrum and XP provide a framework for a team process, whereas Kanban just asks that you make your current process visible and then use that visibility to continuously improve it.

The final difference is that XP prescribes technical working practices such as Test Driven Development, Pair Programming, etc. Scrum and Kanban do not, and the team has to formulate their own.

In reality, most teams will start with Scrum for product development. They then discover they need to adjust their technical practices to deliver working software incrementally, so will adopt some or all of the technical practices of XP. Finally, they’ll start to focus on tightening feedback loops and so will look to Lean/Kanban principles so that they can focus on flow. As a result the need for iterations will eventually disappear and they’ll adopt Kanban.

InfoQ: What are team liftoffs and how can they be done?

Flewelling: A team liftoff or kickoff is used at the beginning of a new team formation or phase of work. It is used to “bootstrap” the team with the knowledge they need to get started as quickly as possible. A liftoff will consist of a series of sessions involving the whole team and will typically last anywhere between half-a-day to a week. 

Activities will include meeting the stakeholders, sharing the product vision, working with the product owner to understand the mission, and determining how we will work together to achieve the mission (our working agreement, including the agile framework we’re going to use and our definition of done). 

For teams new to agile, there will also likely be some agile fundamentals training.

InfoQ: You suggest defining what success looks like using metrics. How can this be done?

Flewelling: There are many factors to a team’s success, it’s much more multi-dimensional than just on time, within scope or to budget. For instance, we recognise that software needs to be delivered at a sustainable pace to avoid any quality issues. However if speed is critical to success, we need to know how to factor this in. One way to create a balance of delivering something of acceptable quality to a tight schedule, is to do no more than is absolutely necessary. We can achieve this by focusing our user stories and through the use of ruthless prioritization. 

These and other parameters will have an impact on how we work together and what kind of product we build. One way to identify the factors at play is to co-create the vision of success in a workshop, often with key stakeholders present (not just the business representatives; also include other teams needed for delivery - marketing, operations, etc). We use this as an opportunity to reduce the number of assumptions we might otherwise have around the product we’re about to build. 

In the book a simple workshop approach to defining success is described in which we survey the team and key stakeholders to determine what we think will contribute to a desirable outcome. Each piece of work will have a different objective in mind and this in turn will influence the success factors, e.g. an exploratory piece to validate an idea will dial down aspects of quality in favour of a rapid evolution of a proof of concept.

Once we have a list of the characteristics that define our mission success and once development is underway, we can use these as the basis to survey the team and stakeholders at regular intervals to see if we’re delivering to those mission parameters.

InfoQ: You talk about creating a no bugs culture where teams move to celebrating bugs as feedback from their users. How can teams best break away from a culture of accepting bugs as the norm?

Flewelling: If we treat bugs as feedback, not only do we have an opportunity to fix the immediate problem, we also have an opportunity to shorten the feedback loop in identifying them in future - bugs generate rework, the sooner we find them in our process, the less time and money they will take to solve.

One of the simplest ways to stop a particular kind of bug recurring is to understand its root cause. Using a technique such as the five whys, we can identify and isolate the origin of the bug. For example, if the root cause was code complexity, not only are we able fix the immediate problem, we can also prevent this type of bug reoccuring by identifying and reducing code complexity. This can be through both direct and indirect means - coding standards, pair programming, TDD, test automation, code review (automated or otherwise), etc.

InfoQ: In your book you dedicate a chapter to the creation of high performing teams, walking through Tuckman's stages of team formation. How important is it that teams remain continuously mindful of where they are on this journey?

Flewelling: The intention in identifying the stage the team is at is to provide them with tools that will help them process that stage. If a team is in the forming stage, helping the team formulate its objectives and working agreement to set the boundaries that they are operating in will help them form sooner. If a team is in the norming stage, they will often feel like they’ve plateaued in their ability to deliver working software. Conducting experiments in continuous improvement will help them move beyond this stage to become high-performing. 

The most difficult stage for the team to process is the storming stage; it often generates conflict as the team tries to transition to working with each other in an agile way. More often than not, the issues at this stage are caused by a difference of opinion on how to do something. It typically happens when the team is put under pressure; some members will revert to what they know works, while others want to push forward with the new approach. When conflict occurs, an objective perspective will be required to help the team process it. To help this we can set up conflict resolution protocols as part of the team’s working agreement during the forming stage. These won’t necessarily prevent conflict occurring, but it will help the team recognise and process it when it does.   

It’s less about the team being continuously mindful of where they are at on the journey, and more about recognising the warning signs of each stage and giving them the tools to process it. They may flip between stages more than once.

InfoQ: You've also given mention to Tuckman's later addition of an adjournment phase, which is often missed from the model. What are the dangers of not recognising this phase as you wind down teams?

Flewelling: The impact on the organization is the loss of a functioning team and the knowledge that they’ve accumulated. The impact on the individuals can be a loss in both team camaraderie and also in terms of satisfaction of a job well done. Especially if the team feels they still have work to do, or knowledge to pass on.  Often we have emotional attachment to our work and our team, if the team disbands abruptly, it can trigger a sense of loss. This is why this phase is also known as “mourning”.

InfoQ: Your book recognises the evolution of practices in Agile knowledge work over the years and a journey from XP to mob programming, CD, #NoEstimates and #BugsZero. What new practices and principles do you see becoming more prominent in the coming years?

Flewelling: I think the biggest improvement bumps for software product development will come in the form of how we learn/obtain the information we need to do our jobs. 

As I mentioned in the last chapter of the book, high performing agile teams become very good at seeking the shortest path to the information they need, both in terms of the knowledge they need to get started, and in validating their ideas. 

The practice of “shifting left” aims to incorporate practices into our workflow much earlier than we have traditionally done; user experience, testing, integration, release strategies, etc.  

So, I think we’ll see an evolution in team learning strategies, taking the current hypothesis driven experimentation approach and evolving it further to enhance organisational learning. This will involve gathering a broader spectrum of data; analytics, operational performance, quality metrics, user feedback, etc. and using it to guide our decision making.

Also, agile is growing beyond its software team grassroots beginning, so we’ll need to consider how we move beyond the current isolated agile technology team structures and start to incorporate true cross-functional involvement from other disciplines such as marketing, insights and sales. 

It’s not that agile is necessarily spreading to non-tech teams, it’s that tech is becoming more prevalent in everyday life and our organisations are becoming more focused on the development of digital products; something that as we know agile lends itself well to. Co-ordinating product development at scale appears to be too complex for a hierarchical organisation to control, so we’ll see organisational structures start to shift to those which suit the digital economy.

InfoQ: Your book talks about the tight feedback loops and benefits to quality which can arise from the practice of mob programming. What advice would you give to teams interested in exploring this?

Flewelling: Look for a champion from within the team to help formulate an experiment. Find a suitable piece of work and create a hypothesis outlining what we think we’ll achieve by tackling this as a mob. To realise the full benefit, the chosen piece of work should be mobbed from start to finish - from the moment the team starts working on the requirement to when it’s available for the customer to use. Once the work is complete, review the hypothesis as a team and determine the outcome. Was the hypothesis correct, what did we learn?

The teams I’m currently working with have seen the benefit of keeping everyone in the mob engaged, and so have started defining roles beyond just the driver and navigator. For instance, they’ve created a facilitator role which amongst other things, manages the coordination, often scheduling group breaks, etc. They also ensure the roles are rotated regularly so that everyone gets a turn.

About the Book Author

Paul Flewelling currently coaches the product teams to transform New Zealand’s largest newspaper company into the digital economy. He speaks nationally and internationally on all things agile, shares coaching insights on his blog, co-hosts monthly meet-ups, and is often seen wisely stroking his beard.