There are are no managers in Scrum
Thoughts on misunderstandings of roles
Does this sound familiar?
- Manager or team leads ask how long a certain task or feature takes. Gantt charts are filled with bars for indicating weeks or months
- Weekly status meetings, asking to update percentages on completion
- Frequently, management has new and more important tasks to tackle first
- Timelines aren’t met, explanations and analysis are done
- Management establishes metrics to measure efficiency and quality
- Development works in satisfying metrics
The vicious circle
Behaviors as described above foster an environment of mistrust and misunderstanding.
Developers feel restricted and burdened with stupid processes. They satisfy processes and metrics just for the sake of it. Timelines contain buffers to be able to cope with spontaneous changes — and to do what is really necessary.
Managers feel the need to control their team members. They ask and validate estimations + timelines and might establish additional metrics if things don’t work out or even go south.
The more time pressure, feature pressure, or quality issues there are, the more the need for metrics arises. This results in teams just satisfying processes and metrics, working around them, creating protective measures, and being demotivated.
A developer’s best time is night time, when no management is around — or management is on vacation.
And now comes Agile
Introducing Agile and Scrum is salvation to many teams. Scrum does not define any management role. The whole Scrum Team with Product Owner, Scrum Master, and the Development Team is responsible for the product. The Product Owner defines stories and priorities while Development Team pulls items into a sprint. There’s no outside power that defines what is done and how it is done. By applying engineering excellence, the team can do it just right and at constant pace, all as specified by the Agile principles.
These principles and the Scrum Guide are used in many arguments with people in traditional management roles like people manager, product and project manager, director, … . This is often also a result of an incomplete Agile transition of the company or divisions.
Cherrypicking: the team
The conflict mentioned can also be a result of an incomplete transition to Agile and Scrum by the Scrum or Development Team — caused by cherrypicking only a subset of the Agile principles.
Simplicity–the art of maximizing the amount of work not done–is essential.
— Agile principle 10
A team that suffers from experiences described above feels their needs addressed by Agile principles 5–12 in combination with a probable misunderstanding of principles 7 and 10. So they might say:
- “Working software means we need to have it thoroughly tested.”
- “Build a simple product means less features.”
- “Technical excellence requires us to build a very flexible architecture and a highly robust system.”
- “Trust us, we don’t have to explain why we do it like that and why it takes that time.”
- “We only ship when everything’s done.”
- “As a self-organizing team we don’t allow late changes.”
Cherrypicking: management
Management also tends to cherry-pick from the Agile principles. This limited view on the context adds more stress to the situation.
Coming from traditional management roles, the Agile principles 1 to 4, also in combination with a probable misunderstanding of principles 7 and 10, are the most appealing. So they might say:
- “Agile means to deliver something fast.”
- “We don’t need any refactoring, that does not create customer value.”
- “It’s Agile, so you should deal with changing requirements.”
- “Build something simple, don’t over-engineer it.”
- “It should always work, why do we have so many bugs?”
- “I thought it is done? Why do we have to continue working on it?”
Misunderstandings
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
— Agile principle 1
The limitation on a subset of Agile principles let both parties remain in their traditional roles. For completing the transition and benefiting from Agile, both parties have to accept some aspects.
Delivering customer value and delivering it early is everyone’s highest priority. This neither means transforming the team into a feature factory nor that a feature has to be perfect in all aspects.
Simplicity means fewer features, but also a simpler software or system architecture or level of quality (do you need 90% coverage on a Proof of Concept?).
“Done” includes the right features with the level of quality for the current scope. The next iteration adds new features and a new “done”.
Changes will always cost and some previous efforts might be wasted. Good architecture can reduce waste while an undone system with over-engineered architecture definitely increases it.
Imagine you want to build a data mining system which deals with vast amounts of data for millions of customers. The UI needs to be nice, the feature set complete to be competitive, the architecture flexible to add new data sets and reports, the system scalable and reliable. This can be big, and “done” would take ages. If you build and release it that way, there would be hardly difference to a Waterfall process. And now imagine a change late in the process or the customers don’t like what was built.
Agile suggests to deliver something early: so what about a small subset of the features to a small subset of the users? What about extending the features until customers are happy? What about extending the user base once you have the architecture ready? And what about scrubbing the project if you see that there will be no Return on Investment?
This should show that Agile needs all its principles to be applied to play its strengths. So while neither Agile nor Scrum defines any management roles, it requires the main responsibilities and motivators of traditional management roles to move to the Development Team as well.
The Development Team: the new management
Scrum has a Product Owner that focuses on and optimizes customer value, priorities, business requirements, and more. The Scrum Master, among many other topics, coaches the team in many aspects, removes impediments, and so forth. These two roles share some responsibilities and motivators with management in a traditional setup. But the Development Team needs to make these their own as well.
While Agile and Scrum gives more power to the Scrum Team and abandons traditional roles, it also pushes the responsibilities of traditional management in the Scrum Team. This is where both can play their strengths. The Scrum Team gets a much deeper understanding of the customer requirements, but also of business requirements. They can therefore work with both, impact them and build a better product. By knowing and understanding the context they are operating in, they can judge the consequences of technical decisions on customer value and business.
In traditional setups, decisions were often management driven while ignoring the technical side of it. Agile doesn’t proclaim it to be the other way around. Its principles describe an environment where decisions can be done with all aspects known, judging and weighing consequences.
What it should mean to you
Don’t replace one role-driven, process-fixated development methodology with another. Understand the meanings behind it and why you’re doing what you are doing. When really understanding and applying Agile and Scrum you get the most customer and business value — and then, you don’t need an explicit manager anymore.
