Working agile means you need to be more disciplined, not less! Think it’s one of the main reasons why is it so difficult to implement Scrum in a team (not speaking about whole organization). Here are several aspects:
- Estimation and planning
- Iteration planning with clients
- Daily follow-up with a whole team
- Iterative reviews of results and further adjustments
- Team work
- Definition of Done: list of requirements that all team has to contribute to – qa and capacity testing, documentation, presentations, monitoring.
- Time boxes
- Team has to deliver best possible results in a limited time. Requires lot’s of focus and determination
- Team is seeking for improvements at the end of each iteration. Normally each two weeks!
- Results must be presented to clients or main stakeholders at the end of each iteration
p.s. Stumbled upon the same topic in InfoQ – The Importance of Discipline in Agile
Previous post about Decision making can be found here. Let’s continue comparison.
Long term vs Short term planning
When you watch teams playing serious tournaments every game is not played like the Finals. In addition world-class teams participate in more than one tournament. Do you think it’s possible to win Bundesliga, domestic Cup and Champions league when you plan only one game ahead? If you don’t “save” your players and “force” them play at maximum level in every game you will not achieve such results.
For sure football coaches care about every game, but trend is more important for them. Last game might be an exception or just a bad luck. As the result all games are analyzed keeping in mind the whole tournament: how many games are played? how many games are left to play? what is the result of recent 3 games? ant etc.
What you can often see with software teams that sprint results are discussed without taking into account the whole roadmap. This leads to short-sighted actions or local optimizations, which is not necessarily the best choice. Good Scrum Masters must bring attention to this and make sure everybody recalls that team wants to win the “tournament”. What is your “tournament”?
Either i was lucky when was playing football at young age or it happens everywhere, but even kids coaches analyze games afterwards. So i bet that professional teams also do that. Game analysis is the only way to improve and learn from mistakes. And I was really surprised when found out how much time and effort is spent on that in football (including various kind of software and hardware that gathers necessary information). Of course various visualizations and statistics are not the ultimate answer to all the problems, but in good hands it can give you very good insights on how to continue.
No (powerful) retrospectives is the first signal that team is not improving, stuck or fell into a comfort zone. It means that Scrum Master is not doing his work and not focused on improvement. To have powerful retrospective team needs input, problems or results visualization, but it’s often teams are scared of any kind of metrics. Because of often abuse, when metrics are used by management to decide on salaries and bonuses, but not as additional information for the team to notice where to improve.
Football vs Software Development
Is it because football has predefined rules all these good practices are in place? Is it because Scrum is incomplete we have so many things depending on team’s maturity and Scrum Master’s experience? How do you handle that?
p.s. full presentation is available here. I will go through it in further posts.
Protection can lead your team to a comfort zone instead of desired process improvement. Who is better to get your team out from comfort zone? Market or ScrumMaster?
What is “Comfort Zone”? Wikipedia says:
The comfort zone is a behavioural state within which a person operates in an anxiety-neutral condition, using a limited set of behaviours to deliver a steady level of performance, usually without a sense of risk
So, you definitely don’t want your team to be in that condition.
This person is often considered a coach for the team. And the goal is to make sure that team does the best work they possibly can. To do that there are tons of tools that can be grouped like this (at least from my point of view, suggestions for more tools are welcome :)):
- Gamification: e.g. playing scrum with lego
- Power questions during retrospectives
- Visualization techniques + 1000 sticky notes and colourful pens
As you might understand all this requires a lot of determination and patience at least from Scrum Master. You often get natural resistance when you want to introduce something new or challenge a status quo. This process is not necessarily effective because it depends on a lot of factors and mostly on experience of a Scrum Master. And for “experienced” teams it’s very easy to stay in comfort zone and defend their beliefs.
It’s much easier here! Either you satisfy your customer and provide value for him or not. You know what will happen If you stay in comfort zone:
- they will laugh at you, if you are lucky
- client will not get back to you, if you are not lucky and they have this possibility
You might still need to educate your client to work according your process: participate in planning and reviews, give feedback.
Don’t protect your team from end-users/market, and enjoy watching how your team achieves hyper performance!
Problem: most SMs are really only meetings facilitators, which is not cool and not effective; it also doesn’t allow reusing all power of Scrum framework.
Goal: Make SM a person who challenges the team and helps them to improve.
Actions: Happiness index metrics, with approach of implementing improvements (or problems solving) in next sprints as highest priority; Re-energizing retrospective of retrospectives: looking for new formats, enabling scrum masters to make decisions.
Expectations: it’s a long and interesting trip of a cultural change 🙂
Retrospectives play important role here. But what is retrospective and how should it happen? Is retrospective a meeting where you list what went well, what didn’t, and what you want to change? E.g. “A team member might say he felt he had to complete work that should have been completed by another team member. Or a team member might say she received emails constantly which prevented her from getting any work done….”
While a retrospective may help you solve this type of problems or improve the way you work, not all problem-solving or process-improvement is a retrospective. I think there is no need in a retrospective to solve daily problems; it can be done on every day basis.
To make company better place to work following concepts must be kept in mind while doing retrospective on different levels:
Building a shared picture
- Different people notice different things, even when working together in the same environment
- As representatives from different teams and different point of views we can form a joint perspective of what is happening and what is now possible. It doesn’t mean we all must agree, but different points of views should enable us to learn and look for opportunities
Taking actions/Making decisions (the thing that we are missing sometimes)
- It is not about only “fixing problems”. It’s about decisions based on join learning, which might be making experiments to try out something new, or maybe even to decide not to change anything for a while.
Remember! Scrum Master is not the one who only organizes daily stand ups, planning and review meetings. He is the person who challenges the team and helps them to improve.
I hear one interesting sentence today. No problem is the biggest problem. You are in trouble if you notice following in your team:
1. no impediments
2. velocity is not changing (growing)
There is always room for improvements. Make sure you are not in stagnation and keep seeking for change.