Scrum: 'sometimes the slap needs to be harder!'

Anupama Rathi, leader of the Agile practice at Infosys, provides the following response to my recent post, “Scrum is like getting slapped, but in a good way:”

"Scrum may be like getting slapped, but in a good way. But sometimes, the slap needs to be harder!

Thanks Joe for an interesting blog. I agree, scrum techniques can surely accomplish the results delivered by a professional 'slapper,' but only if those are followed in true agile spirit. When you have a team which is self-organized, independent and experienced in agile, then improving the quality, productivity and satisfaction with scrum is really easy.

But the challenge lies with teams and stakeholders who don’t adopt the very essence of agile and follow scrum merely as a set of rituals -- if they even follow those. For such teams, we need to convert implicit ‘scrum slaps’ to explicit ones.
Consider a case, where a team is updating scrum artifacts time to time, conducting ceremonies at desired intervals, and has people performing different scrum roles. It looks perfect!  But if the velocity is not improving; quality is not better as compared to any other project then it’s time to take a pause and check what’s going wrong? At this time evaluation of the team’s scrum adoption is required.

Why does scrum adoption fail at times? In a majority many of cases, mindset shift is the main reason.  For example, if a team is a part of a hierarchical organization and has followed waterfall for many years; it is difficult to change its mindset quickly.
Some of the sample issues which bring about this resistance are:

• Managers cannot easily accept scrum master roles.
• Senior members of a team are often more dominant in estimation or retrospective meetings.
• Not everyone can / does contribute to planning exercise.
• Slowly, rituals like retrospectives get boring or daily standups are avoided as those get lengthy  
• Many problems related to team and individual behaviors cannot be located easily as they are subjective topics.

In an attempt to locate such problem areas and more, improve scrum adoption and help derive more agile benefits we use a 'Scrum Adoption Matrix.' The matrix describes various aspects of the three roles, four ceremonies and three artifacts at different levels of adoption. Appreciating the fact that it may be a gradual journey to become a high performing scrum team; this adoption matrix has four levels of adoption for each of these practices:

• ‘Not Scrum’ (not following scrum at all)
• Silver (barely doing scrum)
• Gold (executing the said practice well)
• Platinum (expert level)

This adoption matrix is designed to convert many subjective topics into objective questions to helps the scrum team locate the problem areas, even if there are behavioral problems. It is not just limited to behavioral issues and scrum recommendations. It is developed on the basis of real observations from many Agile project teams’ best practices and lessons learnt. Hence, the matrix will also provide useful hints on course corrections and the next set of best practices to be adopted. On the contrary, not all of the basic activities of scrum are listed in the matrix as it is assumed that the team is already aware of those.
Lastly, it is neither an agile maturity model nor a lengthy questionnaire to be enforced on the team. It’s up to the teams to use it to enhance their agile experience.

How do teams use it? There are no scores in this assessment and one does not need an elaborate exercise to conduct evaluation against the matrix. Going by visual management principles, figures in this matrix can be simply pasted in a team room and the progress can be noted. It is a self-assessment matrix and hence the teams can use this in retrospective meetings at regular intervals to observe and understand their current level of adoption. Teams can also look at the subsequent level to look for ways to improve the agile experience and attain the next level.

Teams should not aspire to be at same level for all practices. A team may be at the silver for a certain practice while it may be at gold for another practice. In fact, considering the organization or environment constraints, one may consciously choose to remain at a lower level for certain practices.
Further, teams can enhance this matrix itself based on their experiences and context so that organization can use it extensively.
While the adoption matrix covers all aspects of basic scrum ceremonies, artifacts and roles, it may not be sufficient to cover all the aspects of a project execution. Most of the projects combine at least a few of XP practices with scrum. Thus, similar to this adoption matrix, teams may define multiple levels of adoption for additional practices followed by their projects. One such example is already added in the matrix as user stories. Similarly it can be extended to engineering practices like configuration management, and build automation.