Scrum Master Certification

I attended the 2-day Scrum Master Certification course in Boston on Sep 22-23. Overall this was an excellent course both as a detailed course on how Scrum works and, just as importantly, the subtleties and application of Scrum as an approach to management in general. Ken Schwaber and Jeff Sutherland were both excellent in portraying the history, philosophy and workings of Scrum and the nuances of how to make it work.

There were a number of key takeaways for me, other than the mechanics of the Scrum Process.

The importance of trust, candor and honesty cannot be understated. The course demonstrated how too easy is it to be overly agreeable with clients and that the hard facts are what they need to hear. Building trust is about delievering the good and the bad news in terms the clients understand but also ensuring that all commitments are actually deliverable from the team's perspective. Often what people say and what they think or mean are not necessarily the same thing

Scrum is also a philosphy in how to get the maximuim performance from people through self-organization. The social interactions of people are at the key to the whole success of Scrum and when done correctly, the Scrum team will evolve and organize itself very quickly into a very high performance team delivering high quality deliverables in short timeframes. Internal reflection and accountability within one's own team drives out inefficiency and increases the ability to make decisions that are focused on delivery.

Scrum can be applied to anything we do in life such as IT projects, management of companies, marketing, product development, and even your own personal life ! Scrum is a simple lightweight process but its application requires a lot of common sense. It removes impediments, focuses on what CAN be done, provide continuous feedback and therefore is a continuous quality improvement process. Again, all based on candor and honesty.

As the course got into the implementation of Scrum to real life situations, there were many examples and exercises to demonstrate the approach required to roll out Scrum. In some cases, the adoption has to be at the grass-roots level whereby a team executes a Scrum process internally but masks this from the traditional management by showing what the mgt team thinks it needs to see. Gradually, the tools and results of Scrum are introduced and actually become the things management realizes it actually wants to see (e.g. burndown charts, delta backlogs, etc).

In other cases, the top-down approach can be implemented in terms of a) adopting Scrum across the board, which is very difficult to do, or b) as a new way of managing the organization itself. In general, the best adoption curve comes from trying Scrum a few times to get the hang of it and to see how the organization can the use it the best.

For me, it really forces management teams to focus by making people accountable for getting things done. If things are not being done, then the team will very quickly realize either the impediments, or what type of people they have on the team! Also, the course demonstrated the importance of cross-functional teams to ensure that all aspcts of a "product" are dealt with during its development in real-time rather than the "over-the-wall" approach to waterfall approaches.

The Scrum Master's role can be challenging in that they have no authority and need to rely on strong people skills to facilitate the process of self-organization. This can be very difficult to achieve particularly under scenarios where there are tough people issues to deal both internal to the team as well as with clients. For IT projects, it will be a rare person that will be a great Scrum Master as (ideally) they need a strong technical background, great client skills, and strong people skills. The course highlighted the "matriarchial" nature (or nurture!) of bringing the best out in people by the strict discipline of letting teams learn on their own but with guidance in a manner that is not "command and control" which most project managers use today.

I thought the performance measurements and estimating sections of the course to be very good as they really provide real-time transparency on how well the team is performing within a sprint and across multiple sprints. The beauty of the techniques is that they can adapt to changing requirements very easily, and the team has multiple ways of controlling its velocity and what it can deliver in any given sprint -- and it MUST deliver something every sprint.

By focusing on one sprint at a time, and the resulting decomposition of tasks that occur at the planning stage for that sprint (up to 40% more effort being needed to be allocated above original estimates), it really brought home how bad traditional project management, waterfall and other prescriptive approaches are in dealing software projects as they continuously change.

Accordingly, there was some discussion about the definition of "Done". When is a product Done ? Clearly, this is something that will vary by project, product and organization.

Ultimately, once a Scrum team realizes how autonomous and self-sufficient it is being allowed to be, the natural dynamics of social interaction really kicks in, and they are off to the races. Once clients see how well this team delivers, then there is no looking back ..