The following article is a guest post to Zephyr from Rodney West, Senior Consultant and the Editorial Director at Isos Technology. Isos Technology is a partner of Zephyr and is the market leader in solving complex enterprise challenges from Agile adoption and QA to DevOps and they help teams improve quality and speed delivery.
As developers, most of us are quite comfortable with Agile software development. It is the de facto delivery model. We often take for granted how well it works and what it buys us.
This is not true for many of our non-technical friends. At some point someone you know will ask you, “our team is switching over to something called Agile. Have you ever heard of that?” You will smile and say, “of course.” At which point they will ask you to explain what Agile is…
… where do I start? Maybe you have always worked on Agile projects, or maybe it has been so long since you were on a waterfall (shudder) project that you don’t know what to say. You may not remember how daunting your first Agile project was. Now you are trying to figure out how to not scare your friend (more than they already are). You understand how exciting Agile can be when done right, and want them to feel the same hope.
Here are a few things I always point out when scaling Agile.
Find the patterns
How do I break my work down? Look for patterns first.
From a developer’s perspective, this is simple. Much or our job is finding patterns and codifying them. They are the puzzle pieces in our solutions. Breaking the world down into patterns and units is an aspect of the developer mindset… but not everyone thinks this way.
When explaining Agile to the non-technical novice, it is very important to understand they often approach problems. Maybe they focus more on goals than individual parts. Or maybe they don’t realize repetition is going on in items they consider unique. It is your responsibility to impart a need to find underlying patterns.
Why is this so important? It will make sprint planning easier. Once some basic patterns have been recognized, breaking down larger tasks into sprint tickets will be simpler. Take the example of an employee benefits communication. A pattern may be identified from past communications: (a) the first draft of text usually takes X days (b) graphics usually takes Y days (c) executive approval normally takes Z days. Knowing this pattern will help in scheduling tasks happen in while allowing for greater team utilization.
It is also important to convey the fact that a pattern is a guideline, not a rule. Patterns should be adjusted to help solve problems, not become impediments. Developers are intimately familiar with this concept, but it can easily get lost in translation.
The calendar can be your friend… or your enemy
How long should our sprints be? Just long enough, but not too long.
Unfortunately, while this simple answer is technically correct, it is also flippant. Even in technical projects, this is often a difficult question to answer when establishing an initial sprint cadence. We are often “fortunate” because we may have release windows that occur every X weeks or deliverable objectives with easily measured boundaries.
Non-technical projects frequently lack these clear boundaries. Additionally, there may be a wide range of independent objectives handled by the team with widely varying, and often erratic, deliverable dates and schedules. These conditions wreak havoc when establishing the initial sprint cadence. When giving recommendations to your non-technical friends, I would advise against initial sprints longer than two weeks.
Why two weeks instead of a month? Part of Agile is being able to deliver quickly and adapt to changing requirements and needs. Using a month, you will deliver slowly and have a harder time adjusting to new requirements. The longer the sprint, the more additional requirements will come in. Shorter sprints allow you to make more effective use of your backlog to prioritize items. It is much easier to tell the business, “we will get that into the sprint beginning next week” than it is to say, “it’s going to be three more weeks before we can prioritize that task.” If you want the business to stand behind the process (as you should), shorter sprints are key.
So why not go with one week instead of two? While you may adjust the cadence to one week sprints once everyone has become used to the new project management style, one week sprints often make your team members feel more rushed. This quickly leads to decreased performance as team members become burned. Two weeks gives breathing room to complete more tasks.
Under a microscope
As developers, we are often shielded from the micromanagement that frequently plagues others. Our directives are normally along the lines of, “find a solution to this issue.” In normal meetings, all most people are interested in is the high level solution (no matter how cool the details may be).
Unfortunately, micromanagement is rampant in other areas. Let’s look at our employee benefits communication example again. It can quickly fall into a spiral of micromanagement such as “this word should be bold” or “this bullet should be above this one” or “we need/don’t need subheadings”. And there may be conflicting micromanagement from sources with the same degree of authority. All of this will create blockers, quickly frustrating both those tasked with creating content as well as the business.
Dealing with micromanagement is much more difficult than finding patterns or deciding on sprint length. It requires a cultural change. Management must understand that team members need freedom to deliver. I’m not saying you need to remove all management from the process. Instead of inserting micromanagement into each task, add individual tasks for applying these lenses that do not disrupt flow.
What about emergencies
Emergencies are a fact of life. I am fully aware of the disruption caused by a P1. These can throw of an entire sprint (or in extreme cases multiple sprints). The beauty of Agile is it can recover from these disruptions. How do you schedule emergencies? The answer is you can’t. You deal with them, and if there is still time left in the sprint, return to what you were working on before the disruption… and if not, move the task to the next sprint.
Don’t be afraid, you can do it
The most important thing you need to get across to your non-technical friend is to not be afraid. While Agile can be daunting, when done right it can be very fulfilling. There is a great deal of satisfaction to be found in continually being able to show progress.
Author Rodney West: Rodney West is a Senior Consultant and the Editorial Director at Isos Technology. He has over 17 years of experience in Software Development, Software Architecture and Technical Leadership in a wide range of industries. His approach to software development focuses on the interaction between corporate culture and development processes in the delivery of software.