Cragilist or Scrumbut(t)

There seems to be a lot of discussion at the moment about teams and companies who are "not really doing it". There are arguments in favour of those who take baby steps and constantly strive to improve themselves over time.

There are also arguments that most teams get stuck half way, once they have implemented the easy bits, and stagnate with a partial Scrum implementation.

People have called this state a number of things but the most amusing I have heard are Cragilist (crappy agilist) and Scrumbut (we're doing Scrum but...). Some people (usually the Americans) add an extra t to make it Scrumbutt.

The best teams I see use this information as their primary metric for improving themselves, running the Nokia test and aiming to improve on those scores sprint on sprint. 

Why do so many teams turn into cragilists? Probably a combination of factors:

 

• Change is hard and keeping up motivation and discipline for a long time takes its toll
• The easy bits of Scrum are easy to implement (daily scrums, sprint reviews etc) and that seems like enough change for the time being...
• Organisations de-motivate people. Companies that don't reward the good behaviours or encourage or provide incentives to those breaking the mould wear individuals down. Also a failure for the organisation to change and remove the barriers to successful Scrum teams is a contributor here.

There is even discussion of whether such measurements could be brought into the certification process which is an interesting concept. In my view, application of this measurement stops becoming useful when used by those outside of the team to judge that team. I think this would fall into that category because as soon as something is riding on the figures coming out of the Scrum test (pay, bonus, certification etc), the sooner the figures start being manipulated 

Fellowship Of The Scrum

The Fellowship of the Scrum

 

Somebody asked me the other day "What did you learn from the Lord of the Rings?". A strange question you might think. And when you ask strange people strange questions you undoubtedly get strange answers. I thought about it and, given the way my mind works and the prejudices it has, I thought that "the fellowship" quite strongly resembled a good Scrum team. This was a group of individuals plucked from various specialisms (bow, axe, sword etc) from diverse backgrounds, some with tensions (Gimli and Legolas) that come to the surface in a classic "storming phase" which is both inevitable and necessary in every Scrum team. They are also tasked by a pseudo-Product Owner in Gandalf with a highly challenging yet motivating goal to defeat their opponent.  Aragorn emerges as the ScrumMaster but, for a while, the team naturally flip-flops without any internal protection or impediment-removal.

 

There was no opportunity to come up with the perfect plan and the team had to make several significant adjustments to their plan as they came across more information and more problems. Even though there was a king in the group and one person who was tasked with carrying the ring, there was no one person in charge of the group. They self-organised and, at different times along the journey, different members of the group led, picking up the more weary at that particular point in time. Another thing that I noticed when looking back on this "team" was that they very rarely did anything on their own; they almost always tackled things as a team or, at least, in pairs, picking up skills from and playing off each other.

 

If we run with the example of Gandalf playing the role of Product Owner, we also see the benefits a Scrum team gets from the close links with their Product Owner. Gandalf was not always with the team and certainly didn't define how the problem would be solved but he did help them with domain knowledge, guidance and even getting his hands dirty. At other times he was away from the team but still looking forward and furthering their cause like a good Product Owner does within a Scrum team.

 

Obviously a normal Scrum team is not faced with such a life-or-death scenario like "the fellowship" were and should aim to work at a much more sustainable pace than this group but I think it's a fairly good, if somewhat whimsical, analogy of a team spirit coming from a cross-functional group of individuals galvanizing around a challenging goal.

Generalists or Specialists

Scrum has as one of its primary principles the concept of self-organising teams and the ideal here is that any member of the team should be able to take any item off the backlog and get it "done". As these product backlog items should be vertical slices of functionality, this is often difficult for teams primarily due to functional expertise - having experts in each area of the development lifecycle. Due to traditional career progression paths we often have an issue in that testers are encouraged to become developers in order to gain promotion and developers are then encouraged to become designers etc. This is, imho, very destructive as it effectively promotes people out of their areas of expertise as well as promoting waterfall, silo thinking. Also, by emphasising various functional experts, we are backing ourselves into a corner where we are restricted with what we can deliver by the skills we have available. As a business we would much rather be in a position where we can deliver what we and our users need; and having a group of cross-functional people helps us reduce that risk to our project.

This is not to say that everyone becomes a homogenous resource - certain people will always have more skills in some areas than others - but it almost inevitably calls for people to focus on pulling in for the team and picking up other areas than they might have done before hand. I would still expect people with the passion in certain areas to take responsibility for sharing those skills with the other team members in a mentoring and coaching capacity. I have had a few conversations with people who are concerned with this, that their desires to focus on their area of expertise would not be supported by an organisation wishing to "go agile" and that overall technical levels will be diluted by the lack of focus and dedication to their specialisms.

Some of those concerns are driven by "the hero syndrome" where people worry that they will no longer get the respect that they got when they were the only person who could deal with a particular problem. This is definitely going to be reduced in a good agile team as the "heroes" are bottlenecks to teams delivering and something that adds risk to a project. Some of the concerns can also be addressed by finding new ways of creating respect for experience such as mentoring and coaching, thus bringing up the skills of the other team members.

My view is that we should be aiming for a team of specialising generalists: people that pull in together to get what's needed done but still spend time furthering their areas of passion so long as this benefits the team by helping building up the skills of the other team members rather than holding them up waiting for the "hero".

Organisational Butterflies

Maybe it's because I'm an external coach for the organisation, maybe it's because I'm not assigned to any particular project, maybe it's because I've come across so many people in my capacity as trainer and coach, or maybe it's because I'm just nosy... I seem to have so many conversations with so many people from so many projects in one organisation that it seems that I am uniquely placed to bring parties together when needed.

Today was a case in point, I was in one building talking to someone about an experience report we have been pulling together when we got talking about, let's call it "Project X", which she was getting some stress about. I happened to mention that I was just on my way to the Scrum of Scrums meeting and that it would probably be a good idea for her to come along as well - get people who need to talk talking. It made me think of the term butterfly from openspace sessions - someone that just flits from one session to another, taking a bit of information, leaving a bit of information and helping the pollination process a little here and there.

This interested me even more because we have been talking a lot recently about becoming self-sufficient - one of the aims of all of my engagements is for the internal employees to own and drive the change - and I think a few organisational butterflies would be a good thing not just for the success of an agile transformation, but for projects and programmes to work in general.

Workstreams in a Scrum project

I was talking with a team today who were considering splitting their one Scrum team into 3, allowing groups to focus on their own "streams". There was very strong opinion from some members of the team that a split would be constructive, allowing smaller, cross-functional groups to get more focus without the "distractions" of the other team members and what they are working on. On the other hand, there was also a significant feeling that the team would risk becoming silos of domain knowledge and they might lose any advantage that being a team gives them over being a collection of individuals. There was a also a concern that if each team was only focussed on a stream of work, would they lose track of the bigger picture.

I've seen teams split into streams very successfully in the past. They have managed the extra communication overhead of co-ordinating themselves pretty well and can track overall progress just as easily as they can track their progress within their own sprint. However, that is usually only necessary when the team is so big (15 people plus) that the day to day working of the team is a little too much. In this situation, we were only talking about 4 developers, a couple of testers and some BA's and when they really talked through the issues it seemed that most of their problems that were leading them down this route were a lack of domain knowledge within the team and, more importantly, trying to do too much. These streams were really broad and they would have been much more effective focussing as one team on a thicker vertical slice within a sprint rather than trying to do 3 ultra thin vertical slices that weren't really very closed related.