SCRUM and Management – helping or disturbing?

The role of management in SCRUM

At a time the product development chain went to an entire stop. At this point we decided to introduce a new method – SCRUM. We all recognized that the project-waterfallish style of delivering our daily work didn’t work out that well. So, the demand for a radical change was recognized at all levels in the company.

We decided to move away from the old style (it was not even project-style work – it was … hmmmh hard to find a word for it) towards a new way of working – agile & SCRUM. The C-level took a decision to invest in consulting to help us implementing the fundament of our today’s daily work. So, management had quite a stake in the agile process.

When the product owners started to discover their freedom to take decisions on the priorities of stories something really strange happened. We started to have some really bad situations where a whole process came to a halt due to non-informed executives. Who decided to take this story before the other story? Why wasn’t management involved in this decision? Well, some of these decisions had real impact on our business (the product owners couldn’t oversee at this time). Other decisions turned out to have almost no impact no our business. But where is the borderline? How to handle these situations in an agile organization? What’s the role of SCRUM?

Strange days, these days

We took the situation to one extreme: we introduced the – I call it – “Everybody-into-one-room-prioritization”-meeting. We got all stakeholders from our departements into one room and did the prioritization of stories. At this stage, the one who was able to out-shout the others had the prioritiy secured for their stories. We haven’t had an objective way to do business value determination and hence persons being able to express themselves in a convincing way were always higher prioritized.

We weren’t overly successful with this method and decided to empower our product owners. They met in a “backlog meeting” and got the prioritization of the story items right. At this time we still believed in the one-and-only instance of a company backlog.

Nowaydays, we moved away from the single-instance company backlog and have topic-bound teams and team-bound backlogs. Paired with empowered and more confident product owners – it seems to work.

Lessons learned?

  • Management, empower your people!
  • Trust them and don’t start micro-management. That’s simply said: frustrating for everybody!

The Product Owner – the grey eminence in SCRUM.

The Product Owner in SCRUM – the grey eminence.

When we introduced SCRUM we decided to “transform” project managers to scrum masters and turn the product managers into product owners. I talked already about how successful we were with the decision on scrum masters here. In this post, focus is on the product owner.

In the beginning, not too much changed for product managers – they still were very much focused on developing our web application – the product. They were utilizing their well-known toolbox of user testing, feature discovery, A/B testing, multi-variate testing, visual design, user experience and so on. The product backlog – one of the most important tools (according to literature) – was perceived as another list to keep up-to-date (or not).

I guess we managed to survive for roughly 2 sprints.

Where did we end? In chaos and anarchy.
The scrum masters felt accountable for the process, the framework, SCRUM. They took their job serious and the mechanics of SCRUM were easily implemented.
The product owners understood well the importance of their job – but were still occupied with getting the product management issues right. The backlog as the utmost guiding instance – the fundament of the roadmap and the release plan was simply not looked after.

Why? Well, product managers were not used to do thorough project management tasks. So far, it was okay for them to do their small-scoped planning for daily work. Now, SCRUM asks the product owner to fill the backlog, to prepare easy-to-understand stories, to get the stories into the right format to not receive 100-story-point-estimates, to do all needed lobbying with management, to inform the C-level people, to … well to take over leadership for their products. For product owners, the shift towards SCRUM was bluntly said – a shock. Product management, project management, ownership for the product business, politics, … quite a lot.

What happened? The scrum masters started to support the product owners with project management tasks – looking after the technics of longer-term project organisation. The product owners started to take over ownership for the previously mentioned tasks – firstly starting to get their product backlogs organized and cut down their stories. Then afterwards taking over responsibility from business perspective.

Where are we right now? Well, the ideal product owner is a copy of Steve Jobs – close to BEING the product. We’re still not there, however the product owners take their jobs really serious now and made quite a way to improve.

From an organization perspective, we start realizing that the product owner as the super-human being doesn’t exist at all. We think about introducing the split of having a product owner and a product manager again. The owner takes care of the organizational tasks – feeding the SCRUM process. The manager takes over ownershop of the product, the strategic development being in-line with business demand and defines the next steps to be taken by the team.

SCRUM is really an excercise! Especially living it in practice!

Lessons learned?

  • The product owner is one of the most important persons in the SCRUM / agile software development process. Be sure you pick the right people doing the job of the product owner.
  • Also, keep in mind that there might be a point in time where you need to split product owner and product manager!

What is SCRUM?

What is SCRUM?

… or better said – what is it NOT?

When we introduced SCRUM we simply removed all project management structures and replaced them with agile – means SCRUM – process templates. We renamed “Project Manager” to “Scrum Master” and “Product Manager” to “Product Owner”. From this day on we were entirely agile. This worked fine for the – initial two sprints. User stories were small enough to fill up the sprint, they weren’t as complex to produce headache, and the overall spirit was positive and optimistic.

So, the bigger stories were produced by our product owners. One user story spawning multiple sprints? No problem at all. We started to work “agile” and followed the basic rules of waterfall (plan, build, run) forgetting all the nice agile ideals. Where we ended actually? Chaos and anarchism – no joke.

 

What lessons we learned – in a retrospective view?

  • SCRUM is a software development tool. It doesn’t free you from all the project management pain. Now, in our organization – we still have technical project managers looking after the huge topics or those needing external support. They get all the different departments organized and look after well-needed input from those departments – allowing the product owners to focus on their part of the game – filling the backlog and controling the product definition. We sorted out the mistake of renaming roles from the waterfal world into agile roles. Now, we have a thorough understanding of what the different roles in SCRUM mean – and what they have to focus on. And, more important where SCRUM roles end and you still need assisting roles.
  • SCRUM doesn’t replace your organization, roles and hierarchies at all – it allows a different view angle on these topics and highlight the product issues.

P.S.: If you were looking for a SCRUM introduction … Try these sources …

The role of the Scrum Master – a key player!?

The role of the Scrum Master – a real key player?!

Very early in the process of introducing SCRUM, we had to choose persons for the roles well known in SCRUM. One of them obviously for the scrum master. Knowing waterfall-a-like models from the past and project management we decided to transform project managers into scrum masters.

Why? What was the motivation?

Well, from the books and theory the scrum master personalizes the “big brother” of the SCRUM process. Not having too much experience with the agile process, the logical step is to transform the person looking after processes from the old universe into the new one. Make the project manager the scrum master.

This worked quite well for a while. But suddenly, scrum masters started complaining about their work – too less meaningful work to be done – too less challenges to be looked after – the process became a common tool and so did the framework. The master of ceremony wasn’t so important any more.
But on the other hand we recognized another role in the process to be overwhelmed with organizational, planning, decision preparation, controling, steering and actually leading the team. Which role is it? In books you usually find the role description of the product owner being reduced to owning the back log, giving input to the team and otherwise having quite a nice life. We found this role in our experience being one of the most important roles – but another blog entry for this topic.

What role does the scrum master actually play right now in our teams? We still have  scrum masters. Some teams run the role of the lead developer and the scrum master in one person. Others still have dedicated persons for the scrum master role – but himself actually looking after three teams. Other teams have one scrum master heavily supporting the product owner consulting the backlog prioritization, the user story splitting and how to actually run the team.

Lesson learned?

  • The scrum master needs to be experienced and well-educated about agile processes.
  • After a while, the process is established, the scrum master will start looking for further challenges – and will most likely find them supporting the product owner.
  • Even if the books don’t tell you – one of the most important roles of the scrum master in our environment is to improve the processes and challenge the teams against their commitment.