The agile SCRUM team – bundled forces.

The agile SCRUM team.

Besides the key roles in SCRUM, there is still this unstructured collection of humans – the team. When we started to introduce SCRUM we simply put all developers into SCRUM teams and we were finished. Amazingly, this went quite well. Developers found themselves confronted with other tasks than pure coding – but as said they did well, accepted the responsibility, improved their intra-team communication skills and everything seemed fine.

From a pure developer’s view the story could end here already. BUT (you knew there would be a “but”, right?) software development as such doesn’t contain only software development tasks – especially not in a web environment.

How to treat the non-developer resources? What about architects, user experience, visual grafix, editors, system administrators, online marketeers, quality assurance? Are they part of the SCRUM team – or not? If not, how to get them to work together with the SCRUM team?

A lot of questions! What we changed so far …

We started to structure the team. Besides the developer we have a lead developer. This person actually leads the team from a technical perspective and acts as an architect for the team. Next to the developers we onboarded the quality assurance team members to let them work directly with the SCRUM team. In parallel, we put user experience specialists directly into the SCRUM team. The visual grafix persons are still external to the team and form a service center where multiple departments of the company got access to. Members of the editorial team participate in the daily stand-up meetings (well, most of them) – but are still not part of the SCRUM teams. The system administrators are associated to the various SCRUM teams we operate – but are not actually part of the team. Online marketeers? Other departments? They are also not part of the SCRUM team and communicate mainly with the product owners and scrum masters.

So, to summarize – our SCRUM team is structured like this:

Closely connected to the SCRUM team are:

  • editorial team member

Still in other parts of the organization:

  • visual grafix designers
  • system administrators
  • other departements

Is it optimal? Well, not really – but SCRUM in our organization is a living process – we’re still improving!

Lessons learned?

  • Initially, get the SCRUM team going with the product owner, scrum master, developers and quality assurance as team.
  • In a next step when SCRUM is well accepted and adopted start thinking about a better structure for your teams.

Good ideas needed? Have a look at Marty Cagan’s great and inspiring methods and principles @

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!

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.