Key takeaways
|
Agile is not easy. It is arguably one of the most potent approaches to productivity and innovation, so almost every company will want to make use of it. However many seem to never get the real benefits of the agile approaches. The reason for introducing agile often is to be able to release products earlier and to focus on the most valuable work for a business - other reasons could be to improve productivity or quality, or to increase employee engagement. No matter which one of these you are aiming for you take a risk of getting none of those outcomes, and even worse conflict and burn-out, if you’re not ready to make the effort as a manager.
In my experience as an agile coach transforming traditional IT departments I have seen both good and the bad examples. One of the most common reasons why agile fails is insufficient support from the levels of management closest to the teams and sometimes failures are directly caused by impediments created by the same managers.
Often this seems to come from not being of aware of which actions strengthen or weaken the teams and their workflow. To help to all those teams I decided to present my general recommendations, which I would like every manager of an agile team or a department of agile teams to know.
Dear manager, this is what you should look for to make sure all your agile teams are successful:
Limited work in progress and clear priorities
In the traditional setting work comes from the manager (line, project, process, etc.). It is clearly defined, how much time it will take it is already estimated, and the manager will receive the result - or at least get a notice that it's done as instructed. In the agile setting work does not pass through the manager in the same way. The loop to the customer is short-circuited and we have thrown out the wasteful practices of waiting for the next task assignment and estimating every piece. This means that the manager does not see all the work that the individuals execute and when there is no manager as a gate-keeper a single individual or team might get overwhelmed with requests.
Work could come from a number of different sources, often in an informal manner. This means that the normal mechanisms for saying no to work are bypassed, both formally and psychologically, and commonly the work starts immediately. When an individual or a team starts work directly when it arrives, the unfinished work which has been interrupted starts piling up. Efficiency goes down and already started work gets late. After a while a vicious cycle has been created where all work is late and everything with a little more priority is painful to squeeze in.
To counter the vicious cycle and to create the opposite virtuous cycle you will need to prioritize and limit what will be done, both by limiting work in progress and only doing the most valuable work. Expect and accept that not everything in the backlog will be done. Have a clear vision for your product and a product owner who is accountable for ensuring that only the most valuable work items are presented in a replenishment meeting or sprint planning. Expect the team to take responsibility for deciding how much work they can commit to.
No matter if you use Scrum or Kanban, learn to see how your teams are limiting their WIP and help them to keep that limit. Good things to do:
- Direct new requests to the product owner, not to individuals in the team or directly to the kanban board.
- Ask the team why they exceeded the WIP limit on their board, to increase their awareness of the situation and to encourage them to honor their agreements.
- Protect the scope of a sprint if you are using Scrum. A short term fixed scope helps efficiency and reduces stress.
- Encourage the team to follow and interpret their process through Cumulative Flow diagrams and Flow Debt diagrams. The CFD helps you to understand how the process in general works over time. Flow Debt specifically measures added work compared to finished work, so situations where delivery is hurt by taking on too much work are more easily identified.
It's easy to fall off, but easy to get back on track if you notice right away. The longer you go unlimited, the longer the recovery will be.
Respect the need for feedback loops
A common but naïve view of work is that if you put more hours in you get more output from a team or individual. This seems logical, but the less intuitive consequences are that you get no chance to learn how you could have done better. Most managers know this in theory, few encourage their employees to take time for retrospectives, process improvement work and experiments with alternatives. The shortest route here and now is encouraged both intentionally and unintentionally. After a while productivity stagnates or even diminishes because of bad morale and fatigue.
In knowledge work, like software development, there is an almost infinite amount of new stuff to learn and therefore an infinite potential to get more productive. Just using some of this potential will get you far. A team getting together every week or two in a safe space to discuss what works or not will find the most productive ways to work together. A product developed through exploring different possible solutions, will more likely be the one that's even better than you thought in the beginning.
One way you can start is to make sure there is slack in the process. By slack we mean time that is not dedicated to specific work and what the time is used for can be decided by either the team or a team-member when the slack time occurs. Slack can be created by e.g. not filling a sprint with work for 100 % of the team capacity or by not starting new work when a WIP limit is reached in kanban. This unstructured time is very suitable for learning and experimenting.
When there is slack the team can decide on a number of different activities to learn and improve. Having retrospectives will almost always give you a great start, because good retrospectives help the team to grow trust and find better ways to collaborate. Another outcome of retrospectives are ideas for experiments for improvement of the process and product of the team. So when you have created slack it is a good idea to make sure a few of the team members know how to facilitate a retrospective.
Another practice you should encourage your team to use for feedback is to let a couple of people design one draft of architecture or user interface design each, in parallel. The team can then compare the results and then implement the best one, or even combine them into an improved version. From this you spread ideas among team-members, get a potentially better design than if just one version was done, and the individuals doing their designs will get valuable feedback on their work. By doing no more than the drafts in parallel this practice is both safe and cheap for the amount of learning it provides.
Another category of feedback, but very important and often overlooked, is that a problem a team can communicate to their manager for handling at the proper level, will more likely be dealt with swiftly and undramatically. A common anti-pattern in a traditional organisation is that problems escalated to management stay there and are not handled.
This kind of feedback loop can be strengthened substantially by having both formal and informal channels for communicating impediments from a team to their manager. If a problem is solvable by the team with some help from the manager, this communication helps both the team and the manager to see how they can solve the issue by interaction. If not, the manager has the ability to escalate to their manager or use other resources he or she might have access to.
Some companies even have policies that a problem a manager or a team has not been able to solve by themselves in a certain time period, is automatically escalated to next level in the hierarchy. This is not a way to punish those not solving problems, but a way to show upper management what kind of problems the organisation can’t solve today and need help with. Whether issues are automatically escalated or not, giving feedback about problems to the next level of management should be welcomed, as only the problems we are aware of are possible to solve.
These practices do take some time and effort, but when carried out the right way they give back exponentially. Getting feedback and improving is a very important part of the agile processes. Make sure that you're not the one stopping them from working. If you notice that teams are not having retrospectives, not trying alternatives or don't tell you about their problems it is time to set a limit on the "real work".
Protect and support shared goals and shared responsibilities
Agile work is teamwork. It is possible to work in agile fashion as an individual, but it is at the team level that the true leverage of agile methods appears.
Common traditional management methods center on setting clear individual roles, measuring individuals against each-other and organising around personal responsibilities and personal accountability. When adopting agile methods there is common anti-pattern that comes from this. Teams and team practices are introduced, but personal responsibilities are kept just the way they were.
One way of undermining the team is allowing an individual "special treatment" so they don't have to follow the practices the team has decided on. This could be telling someone they don't have to attend planning meetings or retrospectives, letting them avoid sharing work or giving them personal assignments that the team should be able to decide how they handle.
If you find yourself in the situation where an individual doesn’t want to work the way the team has agreed to do, you as the manager need to do the exact opposite of the special treatment mentioned above. That is not to say that you should tell the team or individual to solve the problem themselves and then walk away. You do this by helping the individual raise their concern within the team or ask the team lead to work it out with the entire team. Sometimes you will have to stress to the individual that they will have to change their ways if the team is going to come to an agreement.
When you see that the team is trying to solve it together, then you can take a step back. But until both the team and the individual are ok with the situation you should keep reminding them that the issue is unsolved, they have to solve it together and it needs more work.
Other things that show up are (for example) double backlogs in teams with mixed responsibilities and no clear mutual goal. Some work is neglected and the connection between company priorities and tasks gets harder and harder to keep track of. Some things that the team was expected to take care of somehow are not done. "Shared responsibility is no responsibility" is a common mis-truth often spoken by line managers or project managers. Putting it that way you will never trust that a team will be able to be responsible together and chances are the prophecy will become self-fulfilling.
Having a clear purpose and clear expectations for each team is imperative to make individuals let go of their job titles and work for the team. It also follows that you should not measure individuals in a team against each other. Expect the team to decide their way-of-working and encourage team members to follow through on their own agreements.
By letting team members self-organise you help to create a work environment based on ownership and commitment. Your employees will be more motivated to solve a problem and deliver on time, compared to when they are just doing what they are told. The self-organisation also comes with benefits from increased learning and information sharing within the team. Chances that the team-member has the right information when making a decision is increased, compared to when the manager or the team lead makes the decision individually.
All teams are not the same
Teams have differing sets of personality types, skills and abilities, work with different customers and different solutions. Also their paths to their current state have been different, so the tools and processes they depend upon are combined in unique ways. A common approach from managers of teams is to act just like every team has the same working conditions; expecting them to have the same output (e.g. in story points), use the exact same tools or technologies and the same process. This is a special but very common case of impeding the feedback loops of the agile processes and, as stated above, without the feedback loops a lot of the benefits of agile go away.
To improve productivity across the board you can have principles you wish every team to follow, you can have standardised tools available for the teams to choose from and you can measure the productivity of an entire department or company. But it is often best to avoid trying to force teams to use a detailed process, force teams to use a tool they haven't chosen for themselves or compare internal metrics from different teams.
There are a couple of practices that are much more important than what tools or methods the teams choose. While you let them decide in some matters, these are thing you should expect from a team:
- Close collaboration with their stakeholders and customers.
The vision for a product and quality expectations for a product are always conveyed best through direct and recurring communication. Hand-offs are always a waste. Transparency builds trust. There is almost never a reason to keep a distance between a team and their stakeholders. - Keep their own metrics and make them visible
By tracking their metrics a team gets additional understanding of what works and what does not. The probability that the metrics will be useful is increased if the metrics are owned by them and not the manager, so let them decide how and what they measure. Also, being transparent with the metrics helps collaboration and grows trust between teams and stakeholders. - Practice continuous improvement
When a team knows their performance through their own metrics the step to continuously work on improving the process is short. Working with small steps and small experiments the results add up. Performance is improved and probably also morale, as it is both fun and fulfilling to see your efforts lead to a change.
On top of this, listen to your teams. When asked properly they will be able to describe what their impediments are. Removing those that the team can't fix themselves will almost certainly be the right thing to do to improve the output.
Conclusion
I hope you took the time to read this far and have some ideas on what to try next. These are not solved overnight, but keep trying and I guarantee you will see great results over time.
For the time-pressed manager these tips can be condensed to a short list or something you could print out as an everyday reminder until it sticks:
- Expecting a limited WIP accomplishes more than a culture of always saying yes
- In the long run respecting the need for feedback loops always beats doing more "real work".
- Having shared goals and shared responsibilities needs support, don't undermine this by managing individuals
- Different teams, different environments; allow for different ways-of-working and output
What have you tried that helped your teams deliver more value?
Reach out to me on twitter (@dahlbj) or write a message in the comments below.
About the Author
Johan Dahlbäck is an engineer with a passion for efficient software delivery. He has extensive experience both from leading teams and projects as well as a coach in several agile transformations. With a solid background as a database and web developer he has a deep understanding of the dynamics of software development and maintenance. Through working both with teams and organisations he has acquired a broad practical knowledge of patterns and techniques for enhanced teamwork and delivery. Johan has been an avid user of agile methods since 2009 and helped others use them successfully in both small and big enterprises.