Interview with me at STOOS stampede

Rini van Solingen did a interview with me on the Stoos stampede on large scale Scrum.

It was fun 🙂

You can see the video at YouTube.

Daily Scrum for continuous improvement

The other day I was in the expert panel at the Scrum Day Europe.

One of the questions from the audience was

If you could only choose one Scrum event, what would you consider the most important event?

People in the expert panel ofcourse disagreed to have a interesting discussion. Ken Schwaber said the Retrospective is probably the most important event because improvement is key in Scrum, others said the Sprint Review is the most important one and so on. I was left with the Daily Scrum and argued that the Daily Scrum is probably the most important event in Scrum. Let me tell you why I think so.

The Daily Scrum is used by the team to determine the plan for the day. If there is a problem or impediment reported during the Daily Scrum all the problem related data is right there, it is at most half a day old! The understanding of the data is still easy, the problem is still small and can therefore be handled easier and there is still a chance that a counter measure helps you in the current sprint.

The Retrospective gives the team time to reflect on the past sprint(s), work on team building and improve what and how it develops. The team comes up with better ways of doing things, defines experiments to try out the next sprint and utilizes it collective problem solving intellect. A disadvantage of the Retrospective in comparison with the Daily Scrum is that it takes place at the end of the Sprint. And that could be too late! The longer you wait to handle a problem the harder it is to come up with good solutions. You loose context while time goes by.

You can better deal with a problem while the problem trail is still hot! The longer you wait the more time you spend in the retrospective establishing a common understanding of what happened or ‘Gathering Data’ as it is called in the retrospective circles. Most teams don’t even gather any data as they start their retrospectives right away with “what went wrong and what went right” questions… and that is a serious problem!

So next to having a big PDCA cycle every sprint, I like to also have multiple smaller PDCA cycles during a sprint which gives a better continuous improvement. The Daily Scrum makes having the small PDCA cycles possible. And that’s why I think the Daily Scrum is the most important event.

I would have chosen another if I had first pick in the panel discussion 🙂

Scrum does not work, that’s why it does work!

At my training classes the students get actually a bit disappointed when I tell them that Scrum does not solve many of their problems. Most of the students expect that Scrum will solve most of their problems and quality, productivity, predictability and value will be greatly improved. Well unfortunately Scrum does none of that!

Introducing Scrum in your organization does a lot of other things. The main thing it does is that it gives you a lot of very valuable insights. In fact what often happens is that you embark on the Scrum roller coaster and after a few sprints you realize that Scrum does not work in your organization for various reasons.

Scrum is very very hard and it just does not work here because we are special.

You are for example just not able to:

• Create small cross functional teams;
• Deliver tested, integrated and accepted software in short sprints;
• Handle all those disturbances that pop up from the outside during sprints;
• Have specialized people help each other on different specialization areas in a team;
• Deploy to production frequently;
• Produce code according to your well known quality standards every sprint
• Have teams dedicated to a product for longer time periods;
• Create real improvement actions during retrospectives;
• Find a good Product Owner to lead Scrum Teams;
• Steer development on value;
• Produce reliable forecasts and plans;
• Detail your requirements Just In Time;
• Get developers involved in visioning activities;
• Have performance testing be part of a sprint;
• Have architects that know how co write code;
• Have developers understand the domain;
• and so on

There are so many reasons why Scrum just does not work in your organization.

Well if you have so many reasons why Scrum does not work in your organization then Scrum is in fact working perfectly at your organization!

When you introduce Scrum you can suddenly see, if you are willing to face it,  numerous dysfunctions or as I want to call them potential improvements everywhere.

Now the question becomes “What are you going to do about them?”. If you are not willing to do anything about them then there is no use in adopting Scrum!

Management, as always, plays a very important role. Is management continuing to work around the problems, that is doing a lot of rework and firefighting? or is management going to work on improving the processes and focus on problem solving?

That is the main question!

In a continuous improvement culture, management sets challenging goals. Once those goals are met and things stabilize and teams become happy and feel there is nothing worth improving, management changes something and creates unstableness upholding the same goals or even setting more demanding goals to achieve. That is what Scrum gives you, challenging goals you can use for continuous improvement. The goals must be very challenging as described in The New New Product Development Game.

The thinking behind this is that you need to create product to beat your competition today but that you need to improve to beat your competition tomorrow!

So there is no point in taking on a easier approach because Scrum is hard. Scrum challenges you to be perfect and that is, although you will never be perfect, exactly what you need for improvement.

Growing an agile team with norms of conduct

I have seen numerous newly formed teams struggling to get into a performing stage. You’ve probably been in situations where, in meetings only a few people are really involved and the rest is just physically present, or people are feeling insecure to hold each other accountable for promises and just keep silent, people who are not listened too when team matters are discussed, decisions everybody thought where made but people do not follow up on them or my favorite one useless discussions where nothing gets decided.

In such situation creating norms of conduct could help a team move forward.
A norms of conduct for me is a social agreement that the team members create in which they describe what they value and how they want to work together.
Such a social agreement expresses three things.

• Promises – the team members commit to certain actions and behaviors
• Rewards – the team members get the things they value
• Acceptance – the team members take responsibility to act according to the promise

A social agreement is great for agile teams because team members define how they work and therefore influence their future as a team. They are self-organizing because they created the agreement and they can freely choose to agree with it or not! The social agreement provides safety because people can refer to it when tension rises in conversations and situations. With the guidance and extra safety of the norms of conduct people are encouraged to behave constructively.

How teams make decisions, hold each other accountable, provide feedback and what it values determines the teams’s success. Having no social agreement puts a team in the danger zone, especially newly formed teams. Mature teams often have social agreements that probably emerged without the team even knowing it.

But what is a team value?
In agile we have values that we prefer. These values could be things like respect, courage, openness, focus and commitment.
A team value is what a team likes or dislikes in certain situations. Values are the criteria the team uses to decide what to do and how team members feel about certain events and situations.

So for example lets assume the team members agree that everybody should contribute in decision making. This means that they could value active participation of everybody in a decision making process, they could value that the team members give each other the space and time to contribute in discussions and that everyone’s opinion receives serious consideration. The team could not value, not letting team members speak and interrupting people when they speak, not asking for clarification to really understand what others are saying and checking your email during a meeting.

How do you create a social agreement?
A social agreement is best created during a workshop. It could be an explicit meeting, I call them Team Ethics meeting, or it could also be the first retrospective. In the meeting I facilitate a workshop and help the team come up with the social agreement.

I start with discussing the situation they are in, make it visual using a team maturity or growth model and discuss the importance of such a agreement and show some examples of other teams.
Next thing is for everybody to brainstorm and come up with a list of values, behaviors, ideas that they think will help create a great team. After some affinity diagramming I try to categorize them into the agile values or general team topics like behavior in meetings, expectations on accountability, providing feedback and decision making.
The next step is to facilitate discussion about the affinity groups using the agile values and general topics and come up with a few statements for each group. You can now place the social agreement somewhere where everybody can see it daily and refer and adjust it when you need.

With a social agreement in place the team can finally focus on producing software and improving and stop wasting time, energy and intellectual capabilities of its members with unproductive collaboration.

Remember that the physical social agreement is great but the discussion itself is where most of the value is.

Where is the business value?

In agile we say that we do value driven development. We try to work on the most valuable items first so that when the time comes when there is either no more money to spend or no more time left we have the most valuable stuff done and deployed to production.

From all the projects and product development teams I worked with over the years I have seen only a few that measure and track value across time.
The challenges with measuring value are that value is defined different depending on your perspective and that there are numerous possibilities to measure it.

There is value in doing the right thing, that is value measured on outcomes. And there is value in doing things right, that is values measured as output. There is a big and important difference. Output is the stuff you produce like e.g. stories. How much stuff are you making, how fast and at what costs.
Outcomes is the difference it makes. Why are we making this stuff? and why should anyone care? You could measure things like economic value, product quality, strategic alignment and innovation rate just to name a few.

In this post a simple example of how you could work with economic value.

Lets say you are a project team and are delivering your project in 3 month release cycles. The objective of the project is to be able to increase online sales by 10% from 10M to 11M. Great, how do you measure that while you are developing? you can’t as you will only get feedback after shipping the functionality!

What you can do is to let the product/sales/marketing people make an impact estimate on how much sales increase they can achieve with the proposed epics of functionality.
Lets say they estimate that the new functionality impacts sales increase as follows

	Epic 1	Epic 2	Epic 3	Epic 4
Increase from 10M -> 11M	30%	10%	10%	50%
Economic Impact	300k	100k	100k	500k

Don’t worry, product managers, sales and marketing actually studied for making these estimates. It was when a VP once told me

…getting value estimates is easy, that is what our product managers and our sales people have been doing long before you came in…

that I started to realise that it is nothing special at all.

Once you have these impact estimates you can use them to assign economic value points to your stories. The impact estimates limit the amount of value the epic and its stories can create. Without such a limit the value points would be meaningless because you would not able to see progress towards the objective. One way to assign economic value points is to first do a relative value point estimation on your stories. Once that is done you can just distribute the estimated impact.

Lets say Epic 1 consists of 8 stories.

Epic 1	Story 1	Story 2	Story 3	Story 4	Story 5	Story 6	Story 7	Story 8
Value Points	3	1	5	8	13	5	20	3
Economic value	15.517	5172	25.860	41.376	67.236	25.860	103.520	15.517

With this data you can easily measure value delivered each sprint. You can use this data as one out of many of the attributes for ordering your backlog. Another benefit is that you can take action when the rate of added value starts decreasing. It will as value added most of the times follow an s-curve.
After your first release you can start measuring real progress towards your objective of 10% online sales increase.

You can easily extend the impact table with other objectives and estimate impact for those. You could add for example strategic alignment, innovation rate, costs and so on.

Oh yes, of course you have no time to spend on estimating and planning as there is never enough time to do it right, but always enough time to do it over?

Professional Scrum Master Training in Utrecht op 17 & 18 september

I’ll be giving the Scrum.org Professional Scrum Master training in Utrecht on September 17 and 18. The training will be in Dutch.

You can register at here at Scrum.org

Check AgiliX for more information.

Lean Agile adoption metrics

In my work I always encourage my customers to define metrics so they can measure their agile adoption initiative. To me this is important because when times get tough and resistance grows it helps to have some data about obtained progress.

As beautifully described by Robert Austin in his book Measuring Performance In Organizations, as soon as you start measuring things and use those measures as performance indicators the measures loose most of their value as they will ultimately be gambled. Nevertheless measures are needed and you should use them solely as management information.

There are two import points to realize when figuring out what measures to use.

1. Lean Agile adoption can never be the goal.
You should figure out what the goal is of the agile adoption initiative. Here are some goals I experienced at my customers.

• Increase in product quality so that customers happiness increase
• Reduce release cycles to deliver new features faster
• Reduce cost by producing the same with less people
• Increase employee engagement & job satisfaction
• Increase ratio of new feature development to bug fixing
• Increase steering possibilities of product development
• …

Once you figured out what the real goal is of the adoption initiative you should define measure for tracking progress towards that specific goal. It’s that simple!
Progress towards goals like shorter release cycles or better ratio of money spend on new feature development vs bug fixing are often easy because they are hard numbers. Goals like employee engagement & job satisfaction or steering possibilities are harder to measure in numbers but surveys are a great alternative.

2. Lean agile adoption is not a project
It starts but it does not finish! The adoption cannot be easily measured because Agile and Lean are not solely about practices but also about the much more important values and principles and these are intangible. This is quite unsatisfying especially because you want to measure progress towards a goal.

Fortunately you can measure Lean Agile adoption indirectly through for example the rate of use of agile engineering practices, number of produced defects in a release, number of support calls, voice of the customer surveys, cycle times, average number of successfully implemented improvements by the teams, having a appraisal system based on team performance and so on.

But does any of those measures indicate your adoption is successful? Probably these measures you have to put in otherwise you won’t get hired to do the job 🙂

For a successful agile adoption there are three things you need to take into account. First people must learn new practices to be able to deliver frequent high level product. Second new working agreements, new policies and the organizational structure has to change to be focussed on created value instead of utilization. Third the people themselves have to change to be able to work in and with teams, think differently about how work is done, people are managed and create a culture of continuous improvement.

So how can you measure if your adoption is successful? … you can’t! but using proxy measures such as the ones described above works quite well!

Professional Scrum Master Training on 9 & 10 juli

I’ll be giving the Scrum.org certified Professional Scrum Master training in Eindhoven on Juli 9 and 10. The training will be in Dutch.

You can register at here at Scrum.org

Check AgiliX for more information.

What makes a great Scrum Team?

In Agile the assumption is that software development is best done in teams. The formation, growth and guidance of teams is essential. In Scrum you no longer bring the people to the work as most project organizations do today. No instead you bring the work to the people! This means that the work is designed for the team.

Agile teams stay together for a longer time span than project teams do. The obvious reason is that groups of people need time to become a real team (If they ever become one). It takes an average of 18 months for a real team to form and become high performing.

As a Scrum Master you play an essential role in the team forming process. The Scrum Master has the job of doing tasks like facilitating conflicts, encouraging fail safe experiments, coaching on social skills and even motivating and inspiring the team members. And the Scrum Master has to do all of this without authority.

What is a team?
A team is a group of people that feel shared responsibility for achieving a goal. A group of people that put the winning of the team above the winning of the individual. A group of people who feel collectively accountable and are responsible for the team’s success with whatever they are trying to achieve. It is a group of people where there is trust and people are comfortable showing their shortcomings and vulnerabilities within the group.

In a good Scrum team there are various opinions on how to attack problems. There is a constant constructive conflict going on where people are challenging the status quo. The goal of the conflict is to learn and come up with a good enough solution at the moment of discussion. The team engages in discussions to seek and use everybody’s intellect and opinion. In a good team everyone is heard and decisions are made based on the team’s collective input.

Team Task
For teams to succeed the work needs to fit the group of people. One of the things this means is that no single individual is able to succeed on his own!
Linear software development is definitely not a team activity. The goal of producing valuable software is the project manager’s problem. The designer, developer, tester, architect, user experience engineer and analyst are able to succeed individually! All kinds of gates like Test Gates and misused Definition Of Ready make it possible for individuals to succeed while the ‘team’ fails!

In Agile a team task taps into the intrinsic motivation of people. That is because team tasks give frequent feedback of real progress (valuable software) and therefore gives meaning to the work people are doing. It is the fact that the team is working on a complete piece of functionality, experiences frequent feedback on progress and value with the possibility of deciding how to do the work that increases accountability.

The best Scrum Teams are self designing. The Product Owner, ScrumMaster and The Development Team decide on the direction of the product, decide how to do the work, who does the tasks, measure & monitor their own progress, decide which people and resources are needed and use everyones intellectual capabilities!

ScrumPloP 2012

Lachlan Heasman made this funny video of the ScrumPloP 2012.

Check it out 

ScrumPloP 2012

The next ScrumPloP is in the Netherlands. See ScrumTulipPloP for attendee list and registration details.

There is also time for drinks 🙂