A couple of years ago, I got a call from a project manager. He wanted to introduce Scrum to his team. The company wanted to introduce a new internal software, therefore they wanted to use Scrum.
My first question was: Why do you want to use Scrum? He answered, that they needed faster feedback. And that they don’t have time to wait, they needed to start immediately. Ok, I said. Let’s go.
Welcome to another "crash & burn" story.
A) You prepare thoroughly. An Agile Coach starts training and coaching the Product Owner, clarifying the product vision, goals, success metrics, road map, personas. It always depends on how much time & the experience the new Product Owner has. At the same time the new Scrum Master receives coaching: What does it mean to be a Scrum Master? How does Scrum work? What does self-organization or self-managing teams mean? What’s different from being a project manager?
This coaching might take some weeks, depending on the availability of the people. The Product Owner also creates some artifacts along the way, to sharpen his or her own (hopefully passionate) vision of the product. Maybe there also needs to be more clarification with stakeholders within in the organization.
When the right people for the Scrum teams are found, there’s typically a vision & product backlog refinement & working agreement workshop. The people decide on the Sprint cadence, and off they go.
B) Another approach would be: The product vision & goals are clarified first, then it needs to be decided, who needs to be on the Scrum team. A vision & product backlog refinement & working agreement workshop is scheduled and they just start. They use their Daily Scrums and Sprint Retrospectives to adjust. The disruption might be higher, because there is so much to learn in the beginning: How to be a Product Owner, Scrum Master. How to avoid old micromanaging habits. How to use the events effectively. Typically, this requires the support of an experienced Agile coach. It also requires the openness of everybody to reflect and learn.
I tend to like this approach a bit more. The roots of Scrum are described in the paper „The New New Product Development Game“ (/1/). The authors describe a „Built-In Instability“ characteristic: A broad, extremely challenging goal or a general direction is signaled without handing out clear-cut concepts. Wide measures of freedom are offered to the teams.
This freedom is a precondition for self-organizing teams. If there was no freedom, the teams don’t self-organize. Why should they? If everything is arranged for them, like it is typically done in many organizations to avoid a disruption, there is no need to change behavior. Hence, there will be no more active participation by the team members.
Both approaches work way better, when the participants volunteer for using Scrum.
Back to the project: Since they wanted to start immediately, they decided to use the second approach. We did a Scrum training for the Scrum Master & Product Owner, some workshops about the product vision, the risks, the team setup. Some working agreements about the scheduling and flow of the events.
Just enough Product Backlog was prepared. The Sprint Planning was running and then - they stopped. They prohibited the active involvement of an Agile coach. They kept sprinting, but they demanded, that the coach should watch the events and could give feedback after the events. Or some notes about the preparation of the next events, which were moderated by the new and unexperienced Scrum Master.
Here’s why: The Product Owner, the project manager who contacted me, had the scope already in his mind. Reducing scope or finding out which features were necessary and which were obsolete, was no option for him. It wasn’t the feedback of the end users, which was important for him. He needed the feedback of some future users from different departments of the organization, who were now part of the team. He just wanted them to answer many design questions. These were the increments in the Sprint: answered questions by the team about the design. No working product or software at the end of the Sprint.
Their project plan, which was set up in advance, included some weeks of getting the design done, then a few weeks of implementation, then some weeks of testing. The one and only goal for them was to meet the deadline.
They were quite effective in getting the design done. They even improved, because they had a dedicated team in the first time of the history of the project and they got feedback about the progress every day.
The feedback sessions with the Agile coaches got shortened or canceled pretty soon. It become harder to give feedback. The Product Owner and Scrum Master were open for minor changes and tactical improvements. But they refused to change fundamentally. In one conversation, the last one, one said, they rather would do „hybrid agile“ instead of doing full Scrum.
Besides, why? What are the reasons, to introduce this „hybrid model“? Maybe because there are some internal impediments in the organization, that prohibit being Agile. But what is the value of this? You live with these impediments and therefore they never go away. What will be the longterm consequences, if an organization doesn’t face their impediments?
In the above example there was no necessary reason to use a „hybrid“ approach. It was just, that the Product Owner and functional manager, who micromanaged the team, enjoyed this way of working.
At the end, the organization decided to cancel the coaching for this team. The organization wanted to become more Agile and this team was using Scrum in such a wrong way, that it could scare off others from doing Scrum.
My first question was: Why do you want to use Scrum? He answered, that they needed faster feedback. And that they don’t have time to wait, they needed to start immediately. Ok, I said. Let’s go.
Welcome to another "crash & burn" story.
There are probably many ways to start with Scrum. I’d like to highlight briefly two:
This coaching might take some weeks, depending on the availability of the people. The Product Owner also creates some artifacts along the way, to sharpen his or her own (hopefully passionate) vision of the product. Maybe there also needs to be more clarification with stakeholders within in the organization.
When the right people for the Scrum teams are found, there’s typically a vision & product backlog refinement & working agreement workshop. The people decide on the Sprint cadence, and off they go.
This approach is very useful, when organizations have a little bit trouble with openness and their ability to learn. The initial disruption is low, when they start sprinting, because everything is well prepared.
I tend to like this approach a bit more. The roots of Scrum are described in the paper „The New New Product Development Game“ (/1/). The authors describe a „Built-In Instability“ characteristic: A broad, extremely challenging goal or a general direction is signaled without handing out clear-cut concepts. Wide measures of freedom are offered to the teams.
This freedom is a precondition for self-organizing teams. If there was no freedom, the teams don’t self-organize. Why should they? If everything is arranged for them, like it is typically done in many organizations to avoid a disruption, there is no need to change behavior. Hence, there will be no more active participation by the team members.
The „built-in instability“ forces everybody to engage. It is a bit more exhausting in the beginning, but Daily Scrums and Sprint Retrospectives are properly used to establish a learning habit. The tension creates more creativity. The product is also more innovative. Isn’t that the reason why so many organizations try Scrum?
Both approaches work way better, when the participants volunteer for using Scrum.
Back to the project: Since they wanted to start immediately, they decided to use the second approach. We did a Scrum training for the Scrum Master & Product Owner, some workshops about the product vision, the risks, the team setup. Some working agreements about the scheduling and flow of the events.
Just enough Product Backlog was prepared. The Sprint Planning was running and then - they stopped. They prohibited the active involvement of an Agile coach. They kept sprinting, but they demanded, that the coach should watch the events and could give feedback after the events. Or some notes about the preparation of the next events, which were moderated by the new and unexperienced Scrum Master.
Here’s why: The Product Owner, the project manager who contacted me, had the scope already in his mind. Reducing scope or finding out which features were necessary and which were obsolete, was no option for him. It wasn’t the feedback of the end users, which was important for him. He needed the feedback of some future users from different departments of the organization, who were now part of the team. He just wanted them to answer many design questions. These were the increments in the Sprint: answered questions by the team about the design. No working product or software at the end of the Sprint.
Their project plan, which was set up in advance, included some weeks of getting the design done, then a few weeks of implementation, then some weeks of testing. The one and only goal for them was to meet the deadline.
They were quite effective in getting the design done. They even improved, because they had a dedicated team in the first time of the history of the project and they got feedback about the progress every day.
The feedback sessions with the Agile coaches got shortened or canceled pretty soon. It become harder to give feedback. The Product Owner and Scrum Master were open for minor changes and tactical improvements. But they refused to change fundamentally. In one conversation, the last one, one said, they rather would do „hybrid agile“ instead of doing full Scrum.
Hybrid Agile?
What does „Hybrid Agile“ mean? Typically, you take some parts of traditional project management and combine it with Agile tools. For example, you gather all requirements, then you use Scrum for the implementation, then you do a separate testing phase.Is this a bad thing?
Well, first, there is no „Hybrid Agile“. In an Agile approach, we value a „working product“ or „working software“ over „comprehensive documentation“. If you continuously have no working product, you’re not Agile. The word „Agile“ should not be in the term „hybrid Agile“. Better call it „NOT agile“.Besides, why? What are the reasons, to introduce this „hybrid model“? Maybe because there are some internal impediments in the organization, that prohibit being Agile. But what is the value of this? You live with these impediments and therefore they never go away. What will be the longterm consequences, if an organization doesn’t face their impediments?
In the above example there was no necessary reason to use a „hybrid“ approach. It was just, that the Product Owner and functional manager, who micromanaged the team, enjoyed this way of working.
At the end, the organization decided to cancel the coaching for this team. The organization wanted to become more Agile and this team was using Scrum in such a wrong way, that it could scare off others from doing Scrum.
Notes:
- /1/ The New New Product Development Game: https://hbr.org/1986/01/the-new-new-product-development-game
Kommentare
Kommentar veröffentlichen