Scrum and The Enterprise (Panel - Day 1 afternoon)

In the afternoon of day 1 I chose to attend a discussion about Scrum and the enterprise with Bas Vodde, Steve Greene, Nigel Baker and Robin Dymond. I found it very useful as I am interested in applying Scrum for large scale projects and organisations. Unfortunately my notes from the session could have been a lot better but I focused mainly on listening and therefore it took me some time to connect all these notes in my notebook.
A book by John Kotter has been mentioned with title “Leading Change” which was recommended as useful read for discovering and being aware of 7 key errors in the process of change (I intend to buy it). Bas said that Nokia scrum implementation was a bottom up one which I found interesting as I always thought that such a large scale change must be driven from the top. A couple of the speakers agreed on the advice that coaching should be done on the basis of one person at a time and this is one of the reasons that changing the organisation is slow. Somebody said that culture and cultural change is overestimated. A key thing is to make sure testing drives development rather than waiting for story completion.

An interesting topic was how to do planning when teams have many related functionality and dependencies. The suggestion was that all dependencies are displayed on a white board and teams then link with other teams and list commitments. When you have such a large implementation you end up with many teams, the scrum masters of these teams form teams as well and they have scrum masters as well which is a reason for having the 3S meeting(Scrum of Scrum of Scrums) which was recommended to be done once per week.

In terms of keeping team members engaged it was suggested doing regular innovative workshops which should include the business owners and also having OpenSpace days to raise Scrum awareness and to support the coaching community. In terms of working with HR the advice given was to have Scrum roles – Scrum team member, Scrum Master and Product Owner and define competencies for these roles. I guess the challenge is to convince HR and Senior Management that this is needed.

There was the inevitable question about architecture. The common opinion was that architecture is best to emerge – Google walking skeleton.

A huge importance is being placed on having a skilled Agile Coach not just a volunteer. I would say it is the same with Scrum Masters and Product Owners. It is difficult to ask people who are not passionate about Scrum to show the same energy and engagement and deliver the same leadership as an experienced and successful practitioner.

Somebody also said that while agile coaches are skilled change agents, traditional PMs are only skilled to tell lies ;)

The change to scrum is a change from activity based hierarchy to value based streams. For the enterprise it was suggested that Scrum/Lean combination makes sense. Scrum provides the tools; Lean makes sure waste is eliminated.(or so my notes say).

Scrum –dominant in the Agile Community

(Day 1 of Scrum Gathering Autumn 2008)

Jeff Sutherland started the day with a resourceful session about the long way Scrum has gone to become the dominant agile approach. Following are my notes so most of the information comes directly from Jeff except where notes weren’t enough I tried filling in the gaps. If you find some of this confusing it is because of me ;)

Interesting facts in the presentation included results of a research showing that 49% of Agile implementations are Scrum based and another 22% are Scrum/XP. Jeff also touched on productivity improvement levels and how Scrum adoption can affect them. For example an excellent Scrum implementation should result in 400% revenue increase; Good Scrum would give about 300%; Pretty good about 150-200% and something he called ScrumButt just mere 0-35%. Just for clarification ScrumButt also referred to by other authors as MURSC, ScrummerFall, and others is an implementation that doesn’t fully follow the rules of the framework and as result this affects the level of productivity and profitability increase.

I liked the suggestion about what kind of goals work better. I am sure many company directors or owners will say their goal is to meet revenue targets. In fact goals that are likely to work better should focus on customer satisfaction and employee happiness like for example “customers to be ecstatic” or “make life of employees better”.

One of the biggest problems during adoption phase is the fact that traditional managers and often the whole institution have problem with self-organizing teams. They’ll try to do control planning which kills self organization. They find it difficult to abandon command and control which is likely to crush the team. They carry on doing isolated activities and promote lack of transparency which undermines self organization. They object impediments removal which delays progress. So no wonder why 70% of change initiatives fail! This highlights a bigger issue – lack of sense of urgency among leadership.

Jeff suggested using the enhanced Nokia test for finding out if a team is doing Scrum or not. There has been a vast discussion on scrumdevelopment about how and if such tests are useful and while generally I do not like the idea of measuring using the enhanced test for initial assessment seems a really good approach.

A look into the most productive ever projects (where productivity was documented) shows that the most productive one – Borland Quattro failed. As for the second most productive - a project at Motorolla, the team “died” after the company went for a 3rd party product. This comes to show that productivity itself does not guarantee success.

Key factor to success is actually failure. Fast and furious failure plus good retrospectives drives the super performance. Einstein says that one who has never made a mistake has never tried anything new.

At the end of the presentation Jeff talked about well run teams. According to him having a well maintained product backlog, minimized work in progress and the ability to stop when something is wrong are the top factors leading to good Scrum.