I would like to state categorically (more so than my disclaimer on this blog site) that this blog entry is not a plug for any particular service or association to a particular institution, it is intended purely as an observation on my experiences and interactions with individuals both in the SCRUM community and the world in general.
We have all heard the mantra from the “founding fathers” of SCRUM – “Unless there is complete management backing; then SCRUM will not work” – this is very true, to a point. It depends entirely on the project.
How can that be you may ask? Well, consider a new project in an existing company where new ground is being broken both as far as methodology and technology goes – if it goes bust, well hey, at least “we tried”; if it flies, well hey, “I told you it would”. From a management perspective it can be a win – win scenario (except for the manager that has put their reputation on the line in pushing for the change in methodology and/or technology).
Taking this type of project and putting on my Britannic influenced monocle and looking at the evidence in the cold light of day, one could form the hypothesis that the SCRUM based project worked because it was isolated enough that it wouldn’t disrupt existing products / projects. If it failed, well, a few reputations would be soiled, time would have been wasted and something new would have been learned – don’t do it that way… If it succeeds however, we now have the seed for which we can germinate the other projects / teams.
Or do we? If we take existing projects and teams run through the traditional waterfall methodology and try to germinate them with the success of the “golden team” we all too often hit the “they just don’t get it” factor. This is especially true when the proverbial hits the fan; it is far too easy for everyone to scramble back to the former way of doing things and hit panic mode – for any number of reasons. One of the failures at this stage can be attributed to the fact that those that were outside of the Golden Team during the whole process of development have little or no idea of what the implications of being SCRUM really are.
What is the first aspect of SCRUM that is so appealing to those that are doing it?
Complete and utter transparency – there is nothing that hones your concentration so much as to “air your dirty laundry in public”. The sprint burn down chart that is viewed on a daily (or hourly basis) can be very telling to those outside of the team, especially when you know what you are looking at.
What is the main aspect of SCRUM that traditional managers are petrified of?
The perceived loss of power: “What? You mean to say that the team is in charge of organizing their tasks, doing the estimates, etc. How will that work without a manager telling them what they should do?” It is all about trust. In order for SCRUM to truly work you need to trust the team. You can monitor them easily enough and as SCRUM dictates (via the Product Owner or the team itself); pull the plug when the whole scene goes south.
For many, the idea of “handing over” control of a project is too much to bear and is best left to projects that will not impact the company too much. I am not saying we should all go and play the typical team-building exercises where an individual allows themselves to topple over and be caught by their colleagues, but the idea is not far off. If there is no trust in the team then there is little chance of SCRUM working and the traditional dictatorial methodology is best suited to that type of manager.
There is a definite necessity of culture change required, both at the team level and at the management level. For those of us that have become experienced at SCRUM through whatever avenue we have followed, it becomes second nature to us and anything remotely related to waterfall seems like the dark ages of Software Development.
At a team level there is the necessity of maturity on part of the team members to know how to play within the rules, to be honest and open about their estimations, task progress and their limitations – they’ll be very quickly found out within two or three sprints.
At the management level, there will be a necessity of helping your teenage team to pack their bags and prepare to venture out in to the “big bad world” of software development – you will need to place your trust in them, be open with them about your concerns and most of all show them your unbending support.
There is no magic formula for ensuring that a SCRUM project will work, there are numbers out there that state that up to 90% of SCRUM teams fail – the main reason being attributed to the emotional factors (from Michael de la Maza). As someone that has moved countries 4 times, it wasn’t until I came to the US that a cultural consultant pointed out to me the emotional roller coaster that many go through under such circumstances. Google the phrase “cultural adjustment curves” and you will come across articles such as the one provided by the University of Minnesota Duluth where they discuss the culture shock experienced by many individuals that move abroad. When you look at the graph on offer in the article; there are various stages that a person will pass through:
Typical Culture Shock Curves
This can be mapped on to many circumstances where a person has to experience a radical change in their lives. We often overlook the fact that we often spend more time at our places of work than we do in our personal lives and therefore the emotional experiences we have in the work place play a lot in to the feelings we carry home. From what I have seen of SCRUM blogs, lectures, books, etc. few people seem to highlight the fact that there is an aspect to change that needs to be accounted for when adopting such a radical change in methodology (Michael de la Maza is one of the few people that I have had the pleasure to meet and share ideas of SCRUM that actually understands it).
Therefore when making the statement that you are prepared to plough headlong in to SCRUM, bear in mind what you and your teams are going to get in to. As a manager you will need to be able to place your full trust in the team to handle the crisis that they go through and the judgments that they make that perhaps were traditionally in the domain of a manager. As a member of the team, you will need to be honest and open about your work, you will need to be frank with your team-mates (obviously not to the point of being obnoxious) as well as accept their comments about your work. You will also need to have no shame in admitting failure, but at the same time be safe in the knowledge that you and the team can pull together to sort it out.
One of my fondest memories of development was during the height of the initial phase of a new SCRUM project, when the team appeared, for all intents and purposes, as though it was a (very) small colony of ants – as soon as an issue bubbled up we pulled together to resolve it as a team. We were (and still are) very close – with the comfort of knowledge that we can count on each other at all phases of the project.
I cannot effectively express in words the feeling of elation that comes when working within a team immersed in SCRUM – co-located, cross functional and open makes other methodologies seem dull, obscure, in-efficient and out of date.
