Change: story from the trenches

Marc Garlic/Science photo

This blog talks about three lessons I have learned about the change process. The examples are from when I introduced Scrum into an existing team.

Change is so interesting because it happens all the time, and this is true also for the work place: The last three years this is some of the change I have experienced:

• being project manager for a team that changed from developing a soft client (sales numbers of 1,5 million clients!) to develop sw for hardware
• three sw teams being merged into one large group of over 80 people
• lots of changes in the culture and organisation due to the acquisition
• not to mention change in sales processes and marketplace

 All this -and more -in just 3 years!

Forestwander Nature Photography upload bot

I think change is interesting and fun, it can absolutely form the basis for new opportunities and growth. Both on a personal, team and organisational level.


So, let's go back to the "introducing Scrum into an existing team" story:

  

1) Team involvement

How did  the idea of implementing Scrum come up in the first place? It was based on some challenges that (almost) all of the team members agreed was painful. The situation was long release cycles and huge instability in the code base during this development cycle. It was hard to get the code stable before release. And it required lots of time -both hours and calendar time to get to the point of having the overview of bugs -both the number and scope of those blocking the release. (= big risk!!)

However, there was no agreement in the team on how to solve these problems. To see if Scrum could be a solution, all the team members attended a scrum master two day class and we looked into benefits, pitfalls, principles, techniques and vocabulary. We decided to get "all in" for 6 months, and then evaluate if we needed to do major changes (during this six months, we did make adjustments based on retrospectives, but only within the principles of Scrum). Like a Chinese saying: First learn the rules, then break them.

I can imagine several other variations of this where the team buys in on the principles of Scrum, while the business side and management parts of the organisations might not. In that case, I believe the part of using some of the existing challenges as a starting point for change is still a valid case. Then being smart and deliver value on a frequent basis and build trust, and take it from there.

2) Do NOT put up the "here comes a big change" sign

My mistake in this process was to do exactly this: I held up the sign of change, emphasising the parts that was the "change" bit in how we did development.

Don't do this!
Picture: denstad.com

I soon found that a much better approach was to build on the smart things and good principles that was already implemented by the team and being a part of the team culture. I did this by pointing to the evolution part, building gradually on the great things that was there already, not mentioning "change" at all.

One example is the short feedback loop. This team had the best culture on writing automatic tests, not one commit during the last year had been committed without tests. To release to a friendly internal gang (we called them "the gang of five"), was however not something that the team wanted to do at all.

Rather than emphasising that releasing every sprint to the gang of five as a new idea, it was much more successful to get people on board by answering the question: "We have done a great job of getting a short feedback loop into our continuous integration system. How could we involve "customers" into a short feedback loop as well?"

Evolution brings out less resistance than revolution

3) Focus on the intentions behind, empowered teams find solutions
Each Scrum team decided if/how to do estimations. The group as a whole did not do estimations before we tried Scrum, and there was different opinions in the group whether or not this was something they wanted.

The intention of release planning, backlog refinement and estimations are for the team to get on the same page of what is this project all about. What is the order of doing things? What do we believe make sense in order of milestones? What options do we have to make different choices; could we do less on one part in order to get something else in? (I do not believe customer value is the only aspect to consider when prioritising the backlog, but also risk, a mix of smaller and bigger epics/user stories/tasks, motivation/competency in the team, and if the user story is understood)

On the question on "do we need estimations or not?" we rather asked other questions:
How can we get on the same page on what the different user stories is all about? How can we as a team get to understand intentions of user stories and get to the "why" part of them? How does the team have the same understanding of the acceptance criteria?
Could using numbers or size help us in explaining to each other what we are thinking? Here there was different answers in different teams, and we tried out different solutions (no estimates, t-shirt sizes, ideal days, variations of relative numbers).

One team wanted to discuss the topic (it started as quite a heated discussion by the coffee machine). This is what I wrote in the invite to the estimation-discussion-meeting:

Estimates are lies, and estimation is waste
-Unknown

Plans are nothing, planning is everything

-Eisenhower                                           

We ended up doing estimates not for the estimates own sake, we did estimates to get on the same page in the team.

One of the release plans we made in the process
of getting on the same page (3 scrum teams, 25 people)
The picture is taken mid release, this is capturing finished
 work and guesstimates.

More info on change:
Kotter international: 8 steps of change
Toyota kata