The myth of “Scrum of Scrums”

There are a lot of myths about Scrum and Agile in general.

The most commonly found both by googling and in reality are:

• Agile Teams do not plan
• There’s no documentation in Agile development
• Agile development is not predictable
• Agile Teams do whatever they want
• BTW, Agile Teams do not work hard, but just play around
• Agile is only for small companies developing web applications

Ever heard anyone saying that?

I bet you have.

However having the discussion about scaling Agile (and Scrum in particular) got more and more attention, yet another myth emerged:

• When you scale Scrum to more teams, you handle dependencies and coordination among teams with Scrum of Scrums

I think there’s hardly anything more dangerous and harming for both Scrum and large companies willing to adopt Agile SW development.

Actually dependencies are handled in Scrum by actually eliminating or at least minimizing them. That is done in many dimensions and here are 5 key things you cannot miss:

1. First of all development teams must be cross-functional, meaning that they have all needed competencies to transform a product backlog item in a potentially shippable product increment. This is complemented by adopting a collective code ownership, where anybody is allowed to touch any line of code needed to deliver a product increment at the end of the sprint: otherwise you constrain your team with a lot of dependencies from outside
2. Backlog items shall be in the form of end-to-end User Stories, cutting the system through all layers from front-end to the back-end to produce a potentially shippable piece of function: a component based development produces instead a hell of dependencies
3. User Stories shall be INVEST, where the I stands Independent, so that they are easier to work
4. In a scaled Scrum approach the Product Owner Team develops a unique Product Backlog to feed all development teams and ensure that they are as much independent as possible so that they can move fast with little need to coordinate with each other
5. Scrum teams plan together so that residual dependencies are detected as early as possible

If all that is implemented and being impossible to foresee everything in advance, you will use the Scrum of Scrum as a mechanism to manage coordination needs which pop up during the sprint.

It’s not a meeting of Scrum Masters to report some kind of status, but a possibility for a person who got a problem to rise up her hand and get fast help and support from other teams.

BTW, if you think about, the acronym is SOS.

So it is not meant as the umpteenth coordination structure, but more as an emergency procedure to adopt when some team has put or is going to put something on some other team’s feet.

Otherwise, if any possible effort to minimize or at least reduce dependencies in advance is not taken, you will put so much overhead on your teams, that will basically kill their velocity and productivity.

On the other hand, if you’re not able to implement real Scrum with only one team, how can you succeed in scaling it?

You’d better run your projects in a traditional way!

12 secrets of a successful Agile transformation – Part3

As promised here I am to complete the list of 12 tips for a successful transformation towards enterprise agility. In the previous posts (from last week and two weeks ago) we talked about the first 8:

1. Why?
2. The approach
3. Training managers
4. The pilot project
5. Scaling up
6. The Transition Team
7. Create the new roles
8. Cross-functional teams 

Let’s complete the list with the last 4 then:

9. Technical Excellence

Scrum is not enough! Scrum is a very powerful way of organizing work, but doesn’t say anything about how to practically do the work. Instead the biggest challenge for a waterfall organization is delivering a potentially shippable product increment in a short iteration. This implies finding new ways of doing things, applying state-of-the-art technical practices and build teams of professional developers, who are able to find the right solutions to always new problems.

Continuous attention to technical excellence and good design enhances agility. – 9^th Agile principle

10. Cultural change

It’s not about doing Agile: it’s about being Agile, by embracing Agile values and principles. This means primarily focusing on value, on what really makes your customer happy and not your boss or the boss of your boss. Prioritize your work based on the contribution it gives to the people actually paying for the product and not because “we have always done like that” or in order to make people busy: busyness is not a good business.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. – 1^st Agile principle

Then let self-organizing teams to pull the work they are able to do. This is very much connected to why Agile. We’re in an industry with such high levels of complexity and uncertainty that we can no longer assume we can know or control everything goes on. So there’s no other way than building empowered individuals and teams who are able to take decisions autonomously using their best capabilities and judgments in the moment, respond to changes fast and reach a defined goal in the most efficient way.

The best architectures, requirements, and designs emerge from self-organizing teams. – 11^th Agile principle

11. Make your transformation self-sustainable

·         Build internal coaches who can teach and coach the new roles, support people to work as performing teams and be permanent change agents: if you’re really Agile, you’re never Agile enough.

·         Nurture Communities of Practice to give people a place where to meet colleagues who share the same passion or interest and learn from each other.

·         Adjust your HR processes (Performance management, career models, recruitment, reward and compensation) to support your transformation, instead of giving contradictory messages, and enable a collaborative environment of high level professionals.

12. Use an empirical approach

An Agile transformation is not a Change Program, you can plan upfront, set goals and KPIs, deploy it to the organization and track the progress. It simply doesn’t work like this. As you might have understood introducing Agile is complex: you’ve never done it before and you do not know exactly where you’re going, how can you define the steps to get there?

The answer is then to use Agile instead: yes, use Agile to introduce Agile.

So have a transition strategy and a transition backlog, but use an empirical, iterative and incremental approach.

Prototype and refine, make assumptions and validate them through baby steps, use fast feedback loops: it’s all about Continuous Improvement.

Of course using an empirical process control implies that you can observe your system to be able to inspect and adapt. Therefore enabling full transparency is a key success factor: make relevant information visible as much as possible from everybody to everybody to be able to really understand what’s going on and act accordingly.

Otherwise your transformation will degenerate into chaos.

So here are my summary on what it takes to have a successful Agile transformation.

Happy enough, my dear cheeky brother?

BTW, Happy Easter to everybody!

12 secrets of a successful Agile transformation – Part2

Following the blog post from last week, here is the continuation of the list of 12 tips for a successful transformation towards enterprise agility. We mentioned already the first 3:

1. Why?
2. The approach
3. Training managers 

Let’s move on with 5 more:

4. The pilot project

Since we’re talking about applying an empirical process, the starting point is to setup an experiment in terms of a pilot project. Scrum can help out with its framework to give some guidance and some practices which help understand the agile principles behind. A pilot project can provide objective information on the feasibility of rolling out Agile to all the organization. Craig Larman says that if an organization is not able to implement real Scrum with only one team, how can they succeed in scaling it in the whole enterprise? But be aware of choosing a proper pilot project. It needs to be important and critical enough so that people will consider it a serious try and a valuable success (it should be used to gain even more management support for the change), but not too critical to create a safe environment for possible failure. It should be end-to-end and therefore include all the stages that are needed to bring an idea into a product and it needs to be closely monitored and supported by senior management, ready to fix possible impediments.

5. Scaling up

Leveraging on the feedback from your pilot project and acting on the findings, you can start scaling up incrementally. This will allow better control and will enable the organization to build internal capabilities to help the teams that start later.

If you don’t know what you’re doing, don’t do it on a large scale – Tom Gilb

However beware not to be too slow, to avoid the organization finding them in the ford for too long and losing momentum, sense of urgency and a clear direction about the change to make.

6. The Transition Team

Creating a successful Agile organization does not simply mean make a number of Scrum teams work: it means creating all the conditions around to enable those teams to succeed and get astonishing results. The Transition Team is an operative team, with the goal of helping and supporting the organization in implementing the Agile Transformation, by supporting teams, removing organizational impediments, training and coaching people, spreading the Agile values and Lean thinking. The team works as an agile team, driven by the so-called Transition Backlog populated top-down by the organizational transformation strategy and bottom-up by impediments from the team.

7. Create the new roles

In order to scale up you need to build new skills and behaviors for people to fill the new roles of Scrum Master, Product Owner and Scrum Developer. This is best done by means of a mix of training, mentoring and coaching and is a typical item in the Transition backlog. Understanding that we’re talking about new roles, you cannot find in the existing organization, is a critical success factor. One of the worst (and yet easy and most common mistakes) is to create a mapping between existing and new roles, like System ArchitectàProduct Owner or Project ManageràScrum Master. They are totally different jobs and you need to realize this and prepare to help individuals who are willing to learn and challenge themselves to fill the gaps needed to move to the new roles.

8. Cross-functional teams

Cross-functional teams who can deliver potentially shippable product increments at each iteration are a key element in a successful Agile enterprise. So one needed step is to change your organization, remove functional silos and have self-organized teams of 5-9 people with all needed competences working together permanently. And this might imply changes in the office logistics as well, to create the right environment to enable team collaboration.

The most efficient and effective method of conveying information to and within a development  team is face-to-face conversation – 6^th Agile principle

It’s probably enough for today: any comment?

Let’s have a date for the next blog post to talk about the remaining secrets for a successful Agile transformation. 

The importance of working with requirements

Two weeks ago (and the week before) I held a couple of sessions of Product Owner training in Sweden. 

As you know, I’m particularly interested in Product Ownership, being such a critical (and often underestimated) activity for the success of an Agile organization.

Anyway, regardless of this, every time I facilitate a PO training, one of the most interesting discussions happens around the subject of requirements. And the reason is that even experienced analysts or system engineers are sometimes not used to work with requirements properly.

The first important concept, which looks straightforward and totally sensible, but happens to be pretty hard to apply, is that a requirement is expression of a need, not a specification to implement.

It is an item in the space of problems: it is a problem to solve, not a function to deliver. 

On the other hand developing SW is just about solving problems, not writing code, right?

For instance, if one says: I want a bridge, is this a requirement? Is it a problem to solve or a solution?

A right conversation would then be: 

- What is the need behind this request?

- I want to cross a river without getting wet.

Eureka! This is a requirement and, as you might guess, this opens up more than one option to find a proper solution. One solution is definitely the bridge, other solutions could be a boat or a raft or even swimming. And you don’t even need to build anything in the latter case.

This is a very important job: understanding the real need behind a customer request. That’s why we don’t say writing requirements or defining requirements, but eliciting requirements, because it is about digging out real problems and helping the customer understanding her real need (or at least making a hypothesis on the real need, which must be validated through a fast feedback loop).

Then you as PO use your brain, your skills, your domain knowledge and the brains in your team to translate the need in business solutions, you can write in forms of User Stories, which is the language you speak with your team.

Requirements are instead the language the Product Owner speaks with customers, but it would be too easy and not profitable downloading the requests on the team as they are. Challenging customer needs is a very crucial activity for a Product Owner to be able to find a solution compatible with business and maximize the Return on Investment. 

I repeat many times to my PO team: your job is not to push your team to do as much as possible – your job is to challenge requirements, so that your team can do as little as possible.

Cutting some scope because it is not needed has an effect that no efficiency program whatsoever can ever beat: effectiveness eats efficiency at breakfast every morning.

Unfortunately I saw too many times the pattern of jumping directly into solution mode as soon as a request arrives and business solutions masked as requirements.

Buddhist masters know that, if you spend enough time in finding and formulating the proper question, the question itself will contain the answer. But how do you feel is the ratio between the time spent on defining the problem and the time spent on the solution in your context?

How to build a big product in a collaborative way – 3

Well in shape into 2013 after the end of the Great MayanCycle, let’s continue the posts thread talking about how to help a Product Owner team work effectively.

We talked already about how to setup the team and how we build the Product Backlog collaboratively.

Let’s touch today the way our team grooms and orders the backlog and I will start telling you the story of a failure.

A “good” failure indeed: one of those you learn something out!

Some months ago, facing the development of customer requests based on the business priority order, the team realized that implementing a new feature would have required moving to the new version of a 3^rd party we integrate in our system.

No big deal: they said!

And everything would have been ok, except for the fact that, after some weeks, we realized that the new version of this product was not actually properly working with our new operating system.

Result, as you can imagine, was: a lot of troubles, blaming games, fights, time wasted and, finally, the decision to roll back to the previous version.

What went wrong then?

The question is that requirements are prioritized according to business value, but Product Backlog is ordered instead, taking into account other factors than simply customer priority.

Otherwise, what would be the added value of a Product Owner?

My 10-years old son would be perfectly able to do tasks strictly following a prioritized list given by someone else.

Of course, I oversimplified the question a bit.

But not too much indeed!

However, out of this failure, we learned how to arrange our backlog better, putting into it competence and brains, not only from Product Owners, but from developers and managers as well.

Now, before ordering our backlog, we take into account 3 parameters mainly:

1. Business value
2. Dependencies
3. Risks

So, before giving the backlog a certain order, we evaluate the business value ranking coming from Product Manager, we consider the Product Anatomy and rate both the technical and non-technical risks we see associated to the requested MMFs. 

So the PO team defines the backlog order, putting high in the list not necessarily the most valuable items, but obviously the ones which the others are dependant from. We give special attention to the riskiest features, many times splitting them and touching them first, so that we can have an early feedback and take actions accordingly.

Actually there’s a fourth parameter which comes into play many times, that is cost: since the goal of a Product Owner is maximizing the Return on Investment, one could choose to anticipate cheaper features, given a certain business value.

That’s the kind of brain we have to put in, to move from prioritized requirements to an ordered backlog.

What else would you suggest to consider in order to get a proper backlog ordering? 

How to build a big product in a collaborative way – 2

In the last post we said that the PO Team’s job is to collaboratively develop a unique Product Backlog to feed all development teams.

So: how do we do that?

Look at this picture.

We basically do it iteratively, so that at each step we do the cheapest possible amount of work to verify our assumptions, get fast feedback and take a business decision together with our stakeholders: whether continue more or less on the assumed path or rather pivot (or even drop the development).

Given a customer request or a business opportunity, we start writing a Vision of what we’re going to develop (a pitch to explain what we’re going to do and why) and eliciting requirements in terms of needs and problems to solve.

We do it together with all involved stakeholders to be sure everyone is aligned. The requirements are then prioritized and basically divided in 4 categories: must have, should have, nice to have and must not have.

So far we stay on purpose in the problem domain and not consider the solution yet: in order to find the right answer, it’s better to spend time finding the right question.

And whether the question is worth being answered indeed.

The next step is to make a quick architectural analysis and try to identify a possible structure of MMFs (Minimum Marketable Features), which makes sense for the highest priority requirements. This requires again a collaborative approach with stakeholders and, if the team does not have all the needed domain competence, a PO pairs up with a system architect to get some help in the high level solution sketch which will inform the coming backlog preparation.

At this stage, a first cost estimation is provided: a relative cost estimation in story points, having actual efforts of already developed features as baseline.

MMFs, for which business opportunity is still considered valid at this point in time, become part of our global Product Backlog and represent items which can be pulled by any PO in the team to be worked upon and produce more detailed items in a hierarchy from epics to really INVEST User Stories. Pairing within the PO team and involvement of development teams, as well as collaboration with people from QA and Customer Support, help build high quality backlog items as a necessary condition to be able to build a high quality product.

The cost estimation is refined iteratively, leveraging on estimation from development teams actually doing the work.

A release plan is also provided, either as scope first planning, leading to provide a possible lead time interval, or a date first planning, leading to a scope scenario interval. The release plan is updated at the end of each Sprint taking into account historical data on team velocity and possible re-estimate, give the newly built knowledge in the iteration.

Daily work on the different global backlog items is followed up during a 15-min standup and work planning for the coming day is collaboratively agreed, considering which are the most important tasks to be accomplished to come closer to the project goal.

Next time we will have a look at how we groom and we order the global Product Backlog, so that the whole organization, including the PO team, is focusing at any point in time on the most important items.

How to build a big product in a collaborative way - 1

What happens when you have a product too big to be built by one team within the timeframe needed by your business?

You might answer: Well, I allocate more teams and then create an organization structure where each team is accountable for their part and with a project staff, headed by an expert project manager, to coordinate everything.

I do not want to judge this answer. However let’s have a look at the Agile principles:

• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
• The best architectures, requirements, and designs emerge from self-organizing teams.

What do I get out of this??

Well, first that SW development is a collaborative game by its nature: there’s no complex problem which can be solved by one person in a time which is compatible with modern business needs.

Secondly that self-organization and servant leadership are some how embedded in being Agile.

Furthermore, if you look at Scrum, you will find only 3 roles: Scrum Master, Product Owner and Development Team.

I'm sorry: no project manager whatsoever.

Beware! I’m not talking about people here: there are plenty of great project managers serving with passion and competence their organization. 

I’m rather referring to roles and their effectiveness in an Agile context, in terms of: What is the probability I might have success in an evolving reality?

Said that, what I would suggest to a Scrum organization is to setup a Product Owner Team.

Yes: a self-organized team formed by all development teams’ Product Owners collaboratively working together. And I’m suggesting that, because I’m currently coaching a PO Team and I would like to tell my experience through this and some other post I’m planning to write.

Of course a team does not make sense if they do not have a product to build: the PO Team’s job is to develop a unique Product Backlog to feed all development teams, so that the following is ensured:

1. the whole organization is focusing at any point in time on the most important items
2. the development teams are as much independent as possible so they can move fast with little need to coordinate each other
3. the overall architecture of the system is preserved 

Like any other Scrum team, a PO Team might better have a Scrum Master or Team coach (it’s just me in our case) and a Product Owner, who is in charge to give a final word on the overall priority in case of conflicts.

To tell you our story I will start from the beginning and that’s the team setup.

In a recent post I described how it is important for a team’s success to set the stage to high performance and that’s just the same crucial if we’re talking about a group of normally quite senior people who need to learn how to collaborate for serving the entire organization at best, instead of only cultivating the silos they felt responsible for.

And we really started from the foundation by writing together our team vision and the ground values we wanted to build our team upon, as you see in the pictures below. After few months I really recognize that this exercise had proved to be tremendously effective.

So we set the first draft of our working agreements.

Since I wanted to introduce the Scrum values in the team in an organic way, I let them decide completely how to organize in the first place and here come our ceremonies:

• Global Backlog grooming once a week
• Global Release planning once a week
• 15-min daily standup everyday
• Review of work done at least by another team member according to our Definition of Ready
• Team retrospective once a month

I will describe each of these ceremonies, make you see our awesome task board and tell you how we build our backlog starting from customer needs in a number of coming posts.

Talk to you soon!