agilethinking.net Blog

Last week I had the privilege of working with an organization in the UK who take Scrum seriously, and understand that it is more than a quick fix. The director/VP level management realise that it will take time for Scrum to show benefit and more importantly they understand the need to trust their development teams.

I spent five days with the company, and they committed 25 of their developers and testers to working full time with me during those five days. That is a big investment, and I recall with dismay those companies that have told me “we can’t afford the time to send our employees on a (two-day) training course” – we have work to do”… just like the lumberjack who complains his saw is blunt, but then says he is too busy cutting the tree down to stop and sharpen it. But these UK guys were different.

This company have been doing Scrum for about 2-3 months. The one Scrum Master they currently have took the CSM course that Boris Gloger and I facilitated in March this year. They have had some success with the transition, but then started to run aground and recognized they needed additional support in the form of on-site coaching. A good thing to recognize. I wonder how many companies fail to make that connection and continue to struggle. Scrum is not easy; it surfaces problems and makes things look ugly. Some companies will do their best to hide the unsightly things and plod on with a “hybrid Scrum” (eek!) that doesn’t address, or even acknowledge the root causes. Other companies will abandon Scrum altogether and reach the conclusion that “Agile doesn’t work for us”. Happily this UK company decided to go to the next level and work through the difficulties.

During the first two days I worked with a partner, Michael James, to run a team training course. I sold this course to them over a CSM course, partly on cost (it is cheaper by $50 per head as there is no payment to the Scrum Alliance for certification), but mostly on the fact that these people (with the exception of 2-3) would all be Scrum Team Members, not Scrum Masters. It made sense: train for what you are going to be.

There was a lot of skepticism among the workers – remember this came as a management initiative, not a grass roots one. Most of the skepticism is of the healthy kind (willing to learn) but not all of it. Still, the general mood of the group was positive, and Michael and I made a lot of inroads in terms of creating a shared understanding of the nuts and bolts of Scrum, and the use of simple tools such as the task chart – which I more and more see as a core element of a highly functioning Scrum team. When used correctly the task board will keep a team focused and grounded.

During the latter three days the work was focused on improving the quality of the product backlog, identifying organizational impediments, and, most interestingly, exploring the limits of self-organization. The outcome was that the teams completely restructured themselves, and removed a “control” group who were responsible for decision making, prioritization, estimation and work assignment. All duities of this control group would now be distributed between teams and Product Owners. Making these decisions created a feeling of empowerment and freedom among the team members, but to the point where I grew slightly concerned. There was a danger that it could move towards a state of anarchy. Could this be too much freedom, too much power? How would it be used?

I recalled Spiderman’s famous line “with great power comes great responsibility”. The teams were empowered, what now, was their responsibility? This led to a discussion on Responsibility and Commitment. The whole group worked on creating a Team Charter that expressed their commitment to the organization. This was done in small teams, through three iterations, sharing the results with the whole group at the end of each iteration, reconceiving, and then fine-tuning during the subsequent iteration. It was a sort of Scaled Scrum model: living the principles. At the end of the third iteration the product was complete. It was not perfect, but it was a working agreement that everyone present (including the skeptics) felt able to commit to for the next thirty days, when it would be up for review. The Team Charter would be printed large and displayed around the building for all to see.

Here is a copy of the Team Charter:

Framework: We commit to following Agile principles to the best of our ability using the whole Scrum framework.
Quality: We commit to building quality into our products at every stage of their development and to continuously review and improve our techniques for achieving this.
People: We are professionals and have a responsibility to respect each other, act honestly, communicate openly and assist/seek assistance where appropriate.
Process: We commit to working with the organization to define a minimal process to guide our activities over the duration of each sprint, empowering teams to get the job done.
Growth: As individuals, we commit to enhancing and furthering our knowledge and to share that knowledge, as appropriate, with others at [company].

I am deeply impressed by this piece of work, and would love to see more organizations create such a document. To me it showed a seriousness and a dedication which is rare amongst grass roots workers in a top down implementation of Scrum. The experience of working with this company was one of my most enjoyable consulting experiences to date. I hope to be back there in a few months for a follow up visit, and will get to see if the good intentions became good actions. I’ll let you know…