Agile Coaching

No Sprint Demo Needed

Over the years I’ve done lots of work with Scrum teams and I appreciate that Sprint Demo/Review meetings can be a useful way to give stakeholders visibility of features implemented prior to pushing out a product release. Teams that find this way of working helpful typically work in larger organisations, where they don't have the capacity to make frequent software releases due to restricted access to servers or a heavy reliance on manual regression testing. However, the ceremony of Sprint Review may be propping this system up allowing teams to work in a pseudo-Agile way placating stakeholders while delaying the release of valuable software.

Nowadays I work at Unruly with XP teams who don’t hold such demos because we practice continuous deployment. Code is deployed to live environment at the earliest opportunity and often in use within our business a couple of days after planning. Where we don’t want all of our users see new features, we can put in a toggle to restrict visibility. When features are already live, the ceremony of getting together in a meeting room with stakeholders is pretty pointless. Although we do ensure that stories are signed-off by business people, often a single story owner who we’ve been working closely with during development. 

How do our wider stakeholder group (Sales, Marketing teams, etc) know what product features are currently released and find out details of how they can be used? As each story finished, developers send a release email out to internal users and organise education sessions for whoever needs to know how the new feature works. We also took some inspiration from Joe Walnes’ Testing on the Toilet and Aimy (our product manager in New York) creates newsletter-style posters for our company washrooms to illustrate and explain new features now available. We have even tried Release-Email Driven Development for a few stories, where we write the release email before starting development to ensure we've thought things through from a user perspective.

The only situation we might consider holding Scrum style demo meetings is when we are working on a totally new unlaunched product. But even then, our practice has been to make a live version available to a restricted group of internal stakeholders so they can access the product and play around with it themselves. Last year, for our Unruly Analytics product we even integrated wireframes and sketches (see pics below) into the evolving product as placeholders for screens that had not been implemented yet to provide some context for the live features.

 

 

 

Sprint v Iteration

Chris Oldwood asked me about the difference (as I see it) between the Scrum concept of Sprint and Iteration in XP. Although the terms “Sprint” and “Iteration” are often bandied around as synonyms in Agile world with the basic meaning of a time boxed planning cycle used by a software development team, these terms started out with quite different meanings.

Here’s a quick brain dump of my thoughts on key differences.

The purpose of a Sprint in Scrum is to deliver a product increment - a coherent release not a hotchpotch of unrelated features.

When I learned about old-school Scrum (back in 2002 before Scrum Alliance existed), a Product Owner would work with the team to agree an achievable Sprint goal that the team felt they could commit to delivering in a month. The focus of the team was a achieving a goal defined around what the next product increment would be. The Sprint Backlog was simply a list of tasks defined by the team that would help them achieve that goal. Tasks could be added or removed during the Sprint but the goal remained the same.

Around this time, there was no mention in Scrum about user stories and complexity points, these techniques hadn’t been imported from XP yet. So key concepts in Scrum - a goal for the product, a commitment from the team and a release of a product increment.

Agreeing direction and empowering the team to achieve it removes interruptions during the sprint and allows the team to focus attention on the product under development. Although once a product is released there’s likely to be a stream of defects and support requests to be handled by the team which may slow them down later if they don’t pay attention to quality.

XP is a an approach for small teams developing software in the face of vague or rapidly changing requirements.

Back in the day, a team of developers sat down with their on-site customer to play the Planning Game. User stories were jotted on index cards are laid out on the table to be prioritised by value and risk. To quote Kent Beck "We make the plan quickly so there will be little inertia changing it"

XP does not need and end of iteration ceremony to demonstrate or review an increment because software is released as soon as it is ready. Each story has acceptance tests and is releasable independently of the other stories -- remember Bill Wake’s INVEST.

Teams applying XP are encouraged to “embrace change” to listen to user feedback. There is no sense that an XP iteration is frozen or locked down. It’s possible to make small adjustments to stories as they’re worked on and also to swap user stories in and out of the iteration, if we discover something more valuable to work on. XP teams use Yesterday’s Weather (planning poker and velocity) to help them avoid taking on too much work not to make a commitment.

The funny thing is that neither of these versions of Scrum or XP are commonly practiced nowadays. Perhaps that’s down to the proliferation of Agile training lead by people who haven’t implemented these older approaches and planning tools that place more emphasis on velocity tracking for project management purposes. I see the #noestimates movement as a reaction to the blend of Scrum and XP that bloats the ceremony around planning beyond original ideas.

Musings on Conway's Law and SOLID Design Principles

In 1967 Melvin Conway submitted a paper called "How Do Committees Invent?" to the Harvard Business Review. HBR rejected it on the grounds that he had not proved his thesis:

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

He got the paper published a year later in Datamotion magazine and it you’d like to read the original it’s available on his website here -- Fred Brooks subsequently coined the name "Conway's Law" when he wrote about this idea classic book "The Mythical Man-Month".

In his article, Melvin asks "Is there any predictable relationship between the graph structure of a design organization and the graph structure of the system it designs? The answer is: Yes, the relationship is so simple that in some cases it is an identity." and he concludes "a design effort should be organized according to the need for communication." The basic point he makes is that the shape of software reflects the communication patterns of the people making it.

When I've heard conference speakers, such as Michael Feathers and Kevlin Henney, invite the audience to consider Conway's Law, their focus is usually spotting problem areas resulting in the code layer rather than the people layer. The division of an organisation into teams and departments can create barriers and interfaces in the software. The effects are usually even worse when multiple organisations are involved and those organisations are in different countries around the world with time-delays introducing inevitable delays into communications. Many traditional software development organisations use “teams” that are a bunch of people reporting to the same line manager but each person taking responsibility for adding specific functionality. These software developers usually have different coding styles and rationale for design decisions. The resulting code can be like a patchwork quilt and hard to maintain due to inconsistent coding conventions.

Agile approaches to software development can be seen as a way of "refactoring" communication between people and improve the software they create. When we adopt XP practices of Collective Code Ownership and Pair Programming, we improve knowledge sharing and code consistency. On an XP team, any developer can work on any part of the code, code is created and reviewed in pairs, this helps the team to produce code that can be understood by any team member. XP seems to be a set of organisational design patterns that works for a small team. Sharing knowledge between teams working on the same code is a challenge so maybe we need to exchange people between these teams in the same way as an XP team does pairing swaps.

As an agile coach, I work more with individuals and teams than on the code. I spent many years as a software developer and enjoy “debugging” people and communication problems. In working with people to simplify and untangle process, I find myself applying concepts learned in software design, such as decoupling interactions and clarifying responsibilities. Information and work flows through a software, information and work also flows through a software development organisation. Are there any design principles that we regularly apply in software that could benefit how we design our organisations?

I thought it might be fun to revisit the SOLID design principles to see if any apply to the people domain. SOLID is a set of Object-Oriented design principles crafted by Robert Martin and the Object Mentor team in the early 00's to help teach OO design to C++ programmers who might be struggling to make the shift. Michael Feathers gets the credit for coming up with the acronym!

The SOLID principles are:

• Single Responsibility Principle (SRP)
• Open/Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

Let's look at each of these in turn to see whether they might apply in anyway in the people sphere, at the both the level of individuals and teams.

Single Responsibility Principle, an object should have only one reason to change. A class has a single responsibility; it does it all, does it well, and does it only. The purpose of this principle is to make it easy to understand the class and have a single place to make changes to this behaviour.

If we try to extend SRP to the people layer, this implies each person does a specialised job which is pretty much at odds with Agile software development concepts such as collective code ownership. We know that if we have a single specialist then they can become a knowledge bottleneck and we're in trouble if they get sick or go on holiday. This brings to the surface some constraints that we have to work with in the people layer - we have a limited number of people and they are not always available. In software we're used to a world with virtually no limit on the number of entities we can create with separate responsibilities.

However, we can go down the route of applying SRP for flow of information into the team by establishing a Product Owner to be the gatekeeper for new story requests and set priorities for the team. There is also sense in which SRP might apply at a team level, making one team responsible for all changes to a specific product. This is a core idea in Scrum, one team per product. We understand which team needs to make the changes and they have all the knowledge to make those changes.

On larger software systems, we end up with multiple teams and because of the various technologies involved component teams often proliferate. This may work where there's an even stream of work to keep all these component teams busy. But large agile projects often find that feature teams work better than component teams. So again in the P-layer we're concerned about levelling the workload and avoiding knowledge bottlenecks.

Open/Closed Principle, a class should be open for extension and closed for modification. Again this is all about isolating changes. We can’t really extend or modify people so I’m not sure that there’s a way to apply this in the people domain. At the team level we can add, remove or consolidate teams and having some consistent process across teams makes this easier.

Liskov Substitution Principle, instances of an interface should be wholly substitutable regardless of implementation. Implementations of an interface should behave the same way from the point of view of the caller. They should not require callers to have any knowledge of implementation variances to do the same work. Perhaps this applies to the the communication interface to teams. For instance, those processes used when we send the team new support requests and introduce new requirements. If there is a team that handles support requests, we use the same process irrespective of the individual who is picking up the requests, this is in some sense applying LSP. The team can rotate who is on support duty but the interface is the same.

Interface Segregation Principle, several interfaces with specific purposes are better than one larger interface. It’s better to have many small interfaces than fewer big ones as this allows them to change independently. I think that ISP does apply for software teams, we need to identify the parts of the organisation that interact with the team and agree a pattern for these interactions. I’d say that this applies to cadence of meetings, such as demos, and having a clear agenda for specific regular meetings with different groups. This can be a big improvement on general management meetings that aim to cover several different things and involve one or two of participants in turn during one long meeting.

Dependency Inversion Principle, collaborators should depend upon abstract interfaces, not concrete implementations. Objects should be minimally coupled and know little to nothing about how their collaborators are implemented. I’m running out of steam here but perhaps DIP can be seen to apply to how Scrum handles the separation of the stakeholders and the development team. The team decide how they do the work and owns the Sprint Backlog, commitments with stakeholders are made on the Product Backlog only.

I’ve written this article for XPDay magazine as a recent topic I’ve been pondering and hope to discuss this topic at the Open Space there. I’m also posting this article on my blog because I’m interested to hear your comments. I've written this in rather a hurry and I'm sure that there are other ways that SOLID principles might be seen to apply to software development organisations.

Discover to Deliver

The art of product planning is to uncover what you need to build to the best product you can with the resources available to you - it's a balancing act. What makes this challenging is that essential requirements are often missed along the way. We'd like to avoid making major changes to our products late in the day and risk compromising the quality and integrity of our product. Taking an agile approach enables us to deliver incrementally, realising value at the earliest opportunity. An agile approach also enables us learn from each delivery and use this feedback to make a better product. As we practice frequent delivery, we also gain vital experience in our team capability to deliver - helping out team balance what's desired against what's realistically possible.

Where many teams struggle in applying an Agile approach to product planning is that traditional requirements analysis techniques don't seem to apply. Agile teams evolve requirements through meetings and aim to keep documentation to a minimum. Applying a lightweight approach looks easy but requires different skills. I often see teams in suffering long unstructured meetings trying to work with requirements written up in ways that don't help the team figure out what to build.

Discover to Deliver is a wonderful guide for teams who are new to an Agile approach that gives you practical tools to enrich your product backlog as a team. This book will help you discover dimensions of requirements that are not easily represented as user stories and at risk of being overlooked. The authors are experienced facilitators and unlike many books that focus on artefacts, they get to the heart of how you evolve them. You will learn how to bring structure to your conversations with tips on practical details, such as what questions to ask and how to document what you've learned.

What I like about this book is how carefully it has been put together making the contents easy to consume, each concept is illustrated with sketches and examples. The authors have clearly applied their own advice in creating a book that is pared down to valuable techniques and easy to navigate using the progress bar along the top of each page.

As an agile coach this book is great to give to new product owners. If they already have experience with traditional requirements analysis, they will find within the pages how these can be adapted for agile teams. But if they're new to requirements analysis and trying to fit everything into user stories, this book will open their eyes to dimensions of the product that they may have been struggling to express to the team.

Daily Standup: Yesterday I went to a meeting?

As an agile coach, I get the opportunity to observe many daily standup meetings. Often I see a team lead kick-off with a brain dump of everything they did yesterday including a summary of all the meetings, which they attended on behalf of the team. Lately I've been wondering if being the first person to talk sets the right tone. What signal does this give the team?

The purpose of daily standup is not to account for time spent yesterday but to make a plan for today. Some things that happened yesterday may be important to consider but many are not relevant to this purpose. Remember that the meeting should have a forward focus. This may not be the best time to share updates from meetings because team members might want the chance to discuss those issues and ask questions (but hold back as they feel the standup isn't the right time to ask questions).

Consider starting the standup by hearing from the team members who've been in the thick of the work rather than on the periphery. Model the behaviour you'd like to see from all team members - show your respect by paying attention to each person and listening to them. Open your ears for new information, this is an opportunity to pick up whether they're running into problems perhaps they need support or are drifting onto work that's not in scope for the current iteration. An essential part of making a plan for the day is to understand the state of play - this is your opportunity to hear from all the players.

If your own report is regularly about meetings and discussions that the team wasn't party to, it's possible that you may be isolating the team from conversations that they ought to hear and contribute to first-hand. Sacrificing your time as the "meetings buff" may spring from good intentions -- to save them from unnecessary meetings -- but the cost is they depend on information filtered through you and lose an opportunity to build their own relationships with stakeholders. While you're playing team spokesman, you end up away from the team and risk becoming detached from the daily work.

So next time you're tempted to start the daily standup with your meeting updates, think about whether you really need to share these first and whether more people on the team should be involved in spreading the burden of meetings. Thoughts?

Busy Burning Down Sprint Tasks

Yesterday, I attended a daily standup meeting run by a Scrum Master/Project Manager. He was holding a red marker pen and, as he went around the circle, he'd ask the developers what time was left as he wanted to be able to "burn down" each development tasks by crossing out the original estimate and putting time left. His focus was on whether the tasks each of them was working on would be finished rather than whether features were actually Done. If a developer said "Yes" then he'd say "Great!"  When he got to the last developer, she said boldly "I told you it would be 2 days at about 3:30pm yesterday afternoon so I haven't even had a full day on it yet."

After the development tasks were burned down, it was the testers turn to speak - of course their tasks were not on the board. There were half a dozen feature cards that had been moved over into QA column because the developers had just made a build available. No questions were asked about time left here. Even though testers raised some blockers, such as needing test kit and wanting to understand what scenarios were completed in previous sprints, they were left to resolve these with developers.

The focus of this meeting seems all wrong. The whiteboard that this team was standing around was very cluttered and I don't think anyone could tell from it what would be done at the end of the week. There was a Blockers area on the board but it seemed unused. The system seemed to have been put together in a hurry and left to get untidy, serving only as a prompt in standup meetings rather than an information radiator of sprint progress.

As getting to Done didn't seem to matter, why burn down tasks at all? My guess is that the Scrum Master wanted to make sure everyone knew they had work to do but surely the team already knew that. Instead of gathering progress and making sure everyone is busy, a Scrum Master should be listening out for blockers that are slowing down the team. Being busy is not the goal, delivering working features is.

Where does this idea of burning down tasks come from? Well, Scrum does indeed encourage teams to be aware of time left by creating a Sprint Burndown chart. But a sprint burndown chart should contain all the work remaining on the sprint backlog not just development tasks. Even when constructed correctly a sprint burndown doesn't really tell you much about where the work is, in my opinion these trend lines are pretty useless. A sprint burndown can mask a team working waterfall-style with nothing made available to test until the end of the sprint. A sprint burndown can also mask a team that is spread widely across a number of features rather than swarming to get a few features complete before starting on the next. It's for these reasons that sprint burndowns have largely dropped out of use across the industry. They take time to maintain and don't give you a lot of information. Nowadays, most teams visualize their work by moving cards across a team board to Done.

To get a richer picture of what is going on I recommend establishing swimlanes so it's easier to see features move across the board. You can also generate a Cumulative Flow chart, basically a tally of the number of items in each column, see below. This can give you a view of where the bottlenecks are and understand cycle times. It's also simpler to update because you total the number of items in each column rather than adding up estimates.

For example, table below shows a list of the number of items in each column from the team board, recorded on a weekly basis.

This table can be used to generate this chart:

One last point is that, once teams get good at slicing backlog items, they often stop doing task breakdown in sprint planning. Consider bringing tasks back into these meetings, if there are misunderstandings about what needs to be done. 

I'd be interested to hear if you've seen similar misunderstandings of burning down tasks in sprints and look forward to your comments. I aim to write a separate blog on product backlog burndown charts and velocity soon so please save comments about product/release burndown or burnup charts for that. Thanks!