Many organizations aim to be agile. However, only few succeed in becoming truly agile and gaining the benefits out of it.
Let’s take a look at what are the common mistakes in the journey on becoming agile and how to avoid them.
Common mistakes to avoid:
- Doing agile (just) because agile is trendy
- Putting no time and effort to implement changes especially when people are involved
- Not forming tribes around the value
- Thinking doing scrum ceremonies is being agile
- Filling calendars with meetings = no time for real work
- Making only teams agile but not concentrating on the mindset and prioritization on company level
- Having product owners as team output owners
- Having product owners doing everything else but what they are actually supposed to do
In this blog post I’m covering the scrum related mistakes.
Other parts of the series:
Making agile work: Avoiding change related mistakes
Making agile work: Avoiding challenge with the product owner’s role
4. Thinking doing scrum ceremonies is being agile
Couple of definitions that are good to keep in mind:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” The Scrum Guide
“Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment. Ultimately, Agile is a mindset informed by the Agile Manifesto’s values and principles. Those values and principles provide guidance on how to create and respond to change and how to deal with uncertainty.” Agile Alliance
To summarize, agile is a mindset and scrum is a framework. Having scrum ceremonies, such as demos, dailies and backlog refinement sessions, does not equal being agile. It is actually possible to have scrum ceremonies with an old mindset which means no change to agile has happened.
Here’s a million dollar tip: When doing an agile change, make sure that people change their ways of thinking and do not just start having demos and dailies. This requires time and effort, and a learning path for agile for each role. Good practise is to have a learning path of 2 months in the beginning with 1-1,5 hours long weekly sessions, and then go to a continuous life-long learning mode.
Being agile means having these four things in place: Customer-centricity, self-directioning, collaborative networks and experimentation. You can read more about these on Walking the Talk’s report on agile culture.
5. Filling calendars with meetings = no time for real work
People often feel that agile is just having lots of meetings in the calendar which leads to having no time for actual work anymore because of all the meetings.
“This cadence is killing me! I do the actual work in the evenings.”
“I get good improvement insights in the coffee room, but in our retro nobody says anything.”
“We have all these meetings, but still we are missing some relevant information from others that affects our work schedules and planning.”
First of all, if you are having too many meetings, there is a big possibility that you are in a “product owner being a team output owner” -mode, because in that case you probably have lots of status and reporting meetings that you actually should not have.
Fixing that takes time and requires changes in the organization to get the real Product Owner (PO) in place, so let’s take a look at what you can do in the meanwhile. However, these tips also apply when you are in a real PO and scrum mode and want to minimize the time spent on scrum meetings.
Don’t have meetings that bring no value to you
If you have a retro where no one says anything, stop having retros! If you get the same info from the coffee room, then use the coffee room discussions as retros and remove one meeting from your calendar. Remember, the scrum ceremonies are not self-evidently making you agile.
The purpose of the retro is to get improvement ideas and continuously improve your team work. If you reach that goal in some other way, you don’t need to have a retro session. Don’t just have retros because the boss is telling you to have retros. (Bosses, don’t ask teams to have retros. Ask them to continuously improve the teamwork and show continuous improvement mindset.) You can always start a meeting again, if by stopping the meeting you realize the value of it.
Ensure that everybody understands what is the purpose of the meeting
Keep the goal always in mind and use meetings only to help you to reach it. For example, the point with cooperative meetings is to get the relevant info that affects your work schedule and planning and leads to working more smoothly together with others. The point with retros are to continuously improve the way your team works to be better and better at your work. If you are not reaching these goals with respective meetings then the meetings are not bringing you any value and should be either improved or stopped.
Improve your meetings in general
Go through all the meetings in the calendar on company level and check that there are no overlappings. Check all the purposes and participants and make the meetings as optimal as possible. The goal is to spend minimum time possible for the meetings.
Even tough the agile values and principles say:
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
“Individuals and interactions over processes and tools”
This does not mean that you need to have lots of meetings with everybody and half of the people wondering why they are even there. Nor it means that you have to have lots of status meetings with lots of people there. If somebody wants to get a status info, ask this person to join your demo. It is also good to keep in mind that you can use technology to get all kinds of information that can be used to have a face-to-face meeting with relevant people when it is really needed.
Notice! If your meetings are leading to solving issues, getting a better understanding of what you should do, reducing the amount of waste and creating better value for the customer faster, I would say that the meetings might be an essential part of your actual work.
6. Making only teams agile but not concentrating on the mindset and prioritization on company level
One very typical way of seeing the change towards agile is that management asks agile coaches and consultants to “make our teams agile”. However, as we have learned, agile is not the same as teams doing scrum. Agile is a company level mindset. If we want to make the whole company agile, it includes everybody. Even the highest management has to be involved with the change and change their way of thinking and lead by example.
In addition to concentrating on the mindset on company level, the first concrete step I would do to start the change would be to fix the company level prioritization. To be honest, making teams agile is not making your company agile if you don’t fix the prioritization issues. At the end, the more you can concentrate your resources on making one thing ready at the time, the faster you are getting something done.
As long as you have 100 things as priority 1 items and must do’s you are not getting anything done since you are doing too many things at the same time. In this case, it doesn’t really matter how agile your teams are if they are not having clear priorities. Understanding the meaning of prioritization and fixing it is demonstrating real agility.
Here is what you should do:
- Ensure everybody is involved with the agile change, also management is supporting the change and leading by example
- Ensure the agile mindset is present in the whole company and the agile mindset is leading the actions and decisions
- Start the change by fixing the company level prioritization as a first concrete step
- Create clear company level criteria and collaboration practices for prioritizing work
Putting a PO in place is not fixing your prioritization issues in company level unless you really give them the power to do business related decisions. If not, you need to fix the prioritization above the PO, in the portfolio level.
