View the latest Inspect and Adapt blog

The One Where The Product Backlog Was Too Big

12th July 2010

Overview

Andy, the ScrumMaster, was guiding the team through a session of planning poker to estimate the initial Product Backlog so the team could come up with a release plan for the new project. Murray, the Product Owner, had provided the team with the Product Backlog in time for the planning session although it did have to be rescheduled a couple of times as he couldn’t get hold of a couple of the account reps to get their requirements.


The team had timeboxed three hours for the estimation but they had only really just scratched the surface of the Product Backlog and time was nearly up. A quick look at the spreadsheet showed they were probably only about 10% of the way through the product Backlog and that was quite depressing; it was noticeable how the initial energy within the team had all but disappeared and there was still no end in sight.


Unfortunately, even though the team was co-located they had to use a tool to manage the Product Backlog because of the size; they would have preferred to use index cards but the number of index cards needed would have made that impractical. Andy could hardly complain because Murray had done a very thorough job in preparing the Product Backlog and the team now had a very good understanding of what was ahead of them on this project. In terms of fulfilling his responsibilities as a Product Owner, Murray was definitely on the right track.

 

He still felt something was not quite right though – it didn’t feel very agile – and wondered how to help his team keep create the release plan before they lost all motivation. Andy called a break, saying they would re-convene in an hour and asked Murray for a chat. “Are all of these items absolutely necessary?” he asked.

 

“Absolutely” came Murray’s reply, “I have even prioritised them as you asked. Priorities 1 through 5. I mean they wouldn’t be called requirements unless they were required, would they?”

 

Murray started to look worried. “Why? What’s the problem?” he asked.

 

“I don’t know.” said Andy “But something’s not right here. We have the team estimating a load of work and, at this rate, it’s going to take them the rest of the week just to estimate it all.”

 

“Could we try something quicker than planning poker?” Murray suggested

 

“Sure we could.” Andy said “We could try affinity estimation or some other quicker technique but I’m not sure that is really the point. Plus the team are getting a lot of benefit from the discussions that are coming out of the planning poker session”

 

“Could we cut the Product Backlog down to a more manageable size?” Andy asked

 

“Not really” Murray said “I don’t want to run the risk of forgetting something after the account reps have actually submitted their requirements”

 

When the team came back from the break Andy put his unease to the team.

 

“On the one hand, I think we have learned a huge amount about the product and the product backlog. The effort put in to estimating these items has been immense. Personally I am seeing a big drop in the energy levels and am wondering what the best thing to do next would be. What do you guys think?”

 

By playing back what he was seeing to the team he immediately did two things. First of all he acknowledged the elephant in the room that everyone else was concerned about but didn’t want to mention, and secondly reminded the team that if something isn’t working they have the power to change it.

 

“How about we see how much work we have actually estimated before carrying on with the rest?” came the suggestion from Greg, one of the developers. The rest of the team seemed keen on that and so Andy to guide them through commitment based planning to try and get a feeling for their velocity and then use that figure to see how many Sprints it would take them to complete the Product Backlog items they had already estimated.

 

It turned out to be eight four-week Sprints.

 

“So nearly eight months work.” Greg summarised “If we extrapolate that out, assuming an average representation of effort over the Product Backlog items, we are talking about nearly four years worth of work on the Product Backlog. This is with just what we know now, let alone what will probably come up over the next 3 or 4 years! Is it really worth the effort of estimating the rest of this stuff right now?”

 

Analysis

Andy’s situation is far from rare. I regularly see teams with Product Backlogs that are unmanageably large and have even heard of teams with Product Backlogs in the 10,000 items range

 

The typical justification for this is to avoid losing information about what is required; users are also considered to be happier if they know that there is a plan to get to their requirement at some point rather than be told “it’s not going to get done”. Ultimately the Product Backlog is the responsibility of the Product Owner as it is their job to ensure a positive return on the investment of the project. If things do need to get done then they are perfectly within their rights to hold the item on the Product Backlog. Most Product Owners, however, are aware of the benefits of regular “tidying” or “grooming” of the Product Backlog, keeping it in a manageable state.

 

The larger the Product Backlog the more overhead there is for a Scrum team, the more items need to be re-prioritised and re-estimated, the more churn there is on requirements and the more stale they become. In Scrum we ask the ScrumMaster to help the Product Owner in their grooming responsibility and Scrum also allows the development team to spend up to 10% of their Sprint preparing for the next Sprint so, effectively, they are involved in grooming the Product Backlog too.

 

There are a number of options for Andy and the team here. As Murray suggested they could try a quicker estimation technique – such as affinity estimation, where team members don't vote but instead collaboratively move the items along a scale – to speed up the estimation process. 

 

This is often a very useful technique to cover more ground in an estimation session. My personal preference is that this is only used when a team is used to working together and, ideally, after a good investment of time into establishing benchmarks and assumptions through something like planning poker. Hopefully the development team were estimating the Product Backlog in priority order and so the items that had been estimated were the most important ones. If this is true then the decreased discussion and debate in the affinity estimation approach is likely to be less of a risk. However, in this particular situation, I agree with Andy that this probably wasn’t going to address the underlying problem.

 

Another option would be for Murray to group the Product Backlog items into themes of related requirements/features/user needs so that the teams would have less items to size. They would probably need a different set of cards for their planning poker session as these items would most likely be much bigger than the items they were estimating before but it would fit nicely with Scrum. We expect a Product Backlog to be very pyramid/iceberg shaped in terms of size relative to priority. See image below:

 

The Product Backlog Pyramid
We are comfortable with larger items if they are lower down the priority list as they will be broken down and estimated at a finer level of detail when they become more relevant i.e. closer to implementation.

 

Mike Cohn calls this a method of “providing multiple views into the Product Backlog” and another way of doing this is to provide views into the Product Backlog based on release schedules i.e. have only the Product Backlog items that are likely to be included in release one showing at the moment. This, combined with theming the Product Backlog, could make the teams’ job much easier without losing any of the detail, the prime fear of Murray.

 

I have also known teams that set a time limit on Product Backlog items such that, once an item gets added to the Product Backlog, the clock starts ticking and if it hasn’t been planned into a Sprint within say 4 months, it will automatically be removed from the Product Backlog. There is nothing stopping somebody from adding it again but nobody will be notified that it has been removed. If it is that important, people will notice it has gone and will be asking for updates on it regularly. If they don’t, or aren’t, then perhaps it wasn’t that important anyway.

 

Summary

Andy showed good instincts here. Something didn’t seem quite right – he sensed something was not working – and he aired his concerns. Equally he didn’t settle for the first answer as he felt it didn’t really tackle the problem, just dealt with the symptom. Also, he didn’t make the decision himself; he brought it to the attention of the team and asked them how they would like to proceed and what help he could offer them.

 

A product backlog should be a manageable size. This is ambiguous because what is manageable, or indeed appropriate, for one team will not be for another. We don’t want to be beholden to the overhead of managing unwieldy artefacts. Already the planning for this project was pushed back in order to capture more requirements than could ever realistically be delivered in a reasonable timeframe. This was wasted time (and effort).

 

“The longer design and requirements documents sit on the shelf, the more likely they will need to be changed […] the real problem is that the requirements were written too soon” – Mary & Tom Poppendieck, Implementing Lean Software Development

 

We will never know less about our project, and its requirements, than on day 1 so trying to get them all written down on day 1 is not only a folly but also a waste. Scrum is a great balance between very reactive approaches, such as kanban, and the overly predictive approach of waterfall. It allows us to look a little into the future without over-planning. Our product backlog should help us with that but can, all too quickly, take us the other way.

 

Self-Organisation Survey Results

2nd July 2010
Thanks to everyone who contributed to my survey on self-organisation. I presented a summary of the results at NDC2010 in Oslo and have more detailed results available for download from the articles section.

The One Where The Product Owner Was Also The Designer

14th June 2010

Overview

Abdul, the lead developer was one of the co-founders of the company along with Pervez, the CEO and Suzanne, the head of sales. They had built a product from scratch to rival the biggest players in the industry and were getting to the point where they absolutely had to expand. So far they had got away with just Abdul and another developer building the product and due to the small nature of the team, when there was a trade off between user experience and functionality, the choice had always been to add functionality at the expense of user experience.
Recently Pervez had appointed a Product Owner, Manish, to the team to focus the product from a user’s perspective as a clunky product just wouldn’t fly in the market. Unfortunately Manish was not playing the Product Owner role full-time and was also handling the design responsibilities as there was no design role within the development team.
At their first sprint planning session Manish came along as Product Owner with a user story for the highest priority product backlog item that contained a screen grab of how the functionality should look, what tables and fields were required where, how the user would use the feature (drop down lists) and even the colour coding.
Manish felt he had done his job really well and so was surprised when Abdul and the team were upset. Pervez, who was playing the role of ScrumMaster tried to work through the issues.

Analysis

A lot of teams would be really happy with the Product Owner providing a lot of information about the highest priority product backlog item in the Sprint Planning Meeting as one of the biggest complaints I hear from Scrum teams is the lack of clarity around Product Backlog items. One of the responsibilities of the Product Owner is to make sure the Product Backlog is in a ‘good enough’ state for the next level of planning. This usually means making sure the highest priority items have enough detail in them to make planning them into a sprint achieveable.
However, another principle of Scrum is that the Product Owner limit themselves to worrying about WHAT needs to be done while allowing the self-organising Scrum development team to work out HOW it will be implemented. We trust the development team to use their skills and experience to come up with the most appropriate design and solution. I often say that ‘a Product Owner with a little technical knowledge is a dangerous thing’ as they cannot resist the temptation to state the solution they want rather than the business problem or user need that is to be solved. This often leads to what we call ‘technical successes’ where the development team deliver exactly what has been asked for but miss what the user actually really needed. This allows the development team to claim the delivery a success but from a business point of view, it is far from successful.
This was a difficult situation because Manish was also a member of the development team so would naturally be involved in that design process anyway. However Abdul’s argument was that this smacked of up-front design similar to that of a waterfall process, the designer turning up to the development team and saying “implement this”.
Pervez attempted to determine what the issues were and found out that Abdul felt that once a design was put in front of the team, they felt less able to think of alternatives; all they could see was the presented option and they thus felt stifled and un-empowered. Manish felt that, unless he paid attention to the user experience in the user story, it would be forgotten and more “clunky” functionality would be added leading to an unmarketable product.
Pervez asked Manish if he would be happy if the team picked his design apart to which Manish replied that that was what he was expecting. It was only meant to be a starting point but Abdul was still concerned that the team would still only be focussing on the option in front of them instead of considering alternatives. Pervez then asked the team if they would be happier if Manish came to the Sprint Planning Meeting with his idea about the design in his “back pocket” and to let the team have a first attempt not influenced by Manish’s ideas but the reaction from the rest of the team was “why can’t we come up with the design together in the sprint planning session?”.
 
What was especially interesting was how this dysfunctionality, while causing conflict within the team, was fairly easily steered toward some very natural agile outcomes. Pervez’s first question was to ask whether Manish should “hide” his idea so as to avoid compromising the creativity of the development team. This led to a suggestion of collaborative design and a call for Manish to focus his Product Owner time on adding acceptance criteria to the user story rather than the design of the solution. While Manish was still a little uncomfortable by this the team agreed it was better than the alternative of tightening up the requirements even more in advance. As it was, this was taking up Manish’s time pre-Sprint and effectively turning the Sprints into mini-waterfall phases.
One suggestion that the team came up with was to actually make visible a few team agreements i.e. the team will collaboratively uncover the design in Sprint Planning and during the Sprint, everyone can contribute to the design discussion but all ideas are open to change/approval/rejection. Manish also decided it would be helpful to clarify what he should and should not be doing when he is in the role of Product Owner and what he should and should not be doing when he is in the role of team member. He also asked Pervez to help remind him when he is crossing the boundaries.

Summary

This was an interesting situation because all the players were on the same side but this was potentially a source of great conflict and disharmony. There was an obvious tension between Abdul, the lead developer, who was looking to get as much functionality into the product as possible at the acknowledged expense of it looking great and Manish, the Product Owner, who was openly putting more of a focus on things being usable soon. Equally Manish was struggling with his dual role and separating out the time he should be focussing on being a Product Owner and the time he should be focussing on being a designer while the fact that he was now wearing two hats (designer and Product Owner) was already leading to him being considered less of one of the team by the rest of the development team.
Dual roles (people in the team taking on two Scrum roles simultaneously) always causes conflicts in the team and brings extra risk to the project. It is not impossible to handle, and sometimes it is necessary but there are some things to consider. Namely whether this is absolutely necessary – often it is not as necessary as we first think – and part of the role of the ScrumMaster is to challenge current conventions rather than compromise Scrum. Certain dual roles are easier to handle than others but I would argue that if you have a dual role you need an even stronger ScrumMaster than you might otherwise need to help identify and facilitate the team through the conflicts.
It is usually a good idea as a team to understand who is bringing what to the party (as it were) and to what degree the Product Owner is going to define the design. In this particular case, a big risk is that the product moves from the extreme of “not so pretty”  but lots of functionality to a really polished but functionality-sparse product. The ScrumMaster is often the fulcrum between product management and product development. Pervez will probably find himself even more in the spotlight in this regard here, making it very visible when either side is potentially dominating the other.

The One Where The ScrumMaster Was Also A Developer

25th May 2010

This blog post is the first in a series of stories from real Scrum teams (although the names etc have been changed to protect anonymity). 

Overview

Marcel had been at the company for 7 years and, in that time, had come to be known as the “go-to guy” for Java work. In fact he was known affectionately as the “Java Guru”. The last project was a really important one for the whole company and, naturally Marcel was a central part of the effort to build this product. On more than one occasion he had come up with a breakthrough to help get the team and project back on track and, with a monumental effort from everyone, the project just about met the deadline. 

In an attempt to get things under a little more control and avoid this type of situation in the future, management had decided that it was time to start using Scrum. One problem they had was they couldn’t afford a dedicated ScrumMaster and so, after the whole team were trained in Scrum, management asked Marcel if he would take the role on as he was the most experienced person on the team.

Marcel seemed apprehensive but had not got to where he was by saying no when asked if he could take on more responsibility so agreed. He found this challenging almost immediately when working with the team and the Product Owner to come up with the Sprint plan – how much time was he going to spend doing his ScrumMaster work? And therefore, how much of the Product Backlog could he and the team commit to? During the sprint, finding time to chase down the team impediments while also trying to complete his tasks was a constant headache and he often found himself stopping mid-task to shift his focus to a problem the team needed resolving. 

Also, the team didn’t seem to be very self-organising as they were supposed to be with Scrum and he couldn’t work out why.

Analysis

Can a person be a ScrumMaster and a member of the development team at the same time? This is a question that I think I have been asked every week for the last 5 years (or at least it feels like it). From Marcel’s point of view he was obviously very conflicted, between his duties as a member of the team and his responsibilities as a ScrumMaster in servant-leadership of the development team.

First of all this dual-role has made planning (both at a sprint level and release level) even harder than it would normally be as there is an additional unknown variable thrown into the mix, namely how much of Marcel’s time can he spend on development activities and how effective will the rest of the team be without a full-time ScrumMaster? Marcel and the rest of the development team could agree on a figure (say 30%) that they think Marcel would be able to spend on items on the Sprint Backlog as one way of handling it. This at least gives them something to go with but there is another issue here – which items should Marcel commit to?

A team member who is not totally committed (which is effectively what Marcel has become) poses a new problem for the team in that, if he takes on the high-risk or high-priority items, there is a very high chance that he will be interrupted during his work leading to either delay or, in some cases, mistakes. For this reason, the team may decide that it would be prudent for Marcel to focus more on the lower risk items, letting the “full-time” people tackle the higher risk items. This mitigates risk but also loses the value that the “Java Guru” could and should be adding to the team and the Sprint.

Marcel will also probably end up doing less of the job he likes and I see the loss of passion and enjoyment a lot in people taking on these dual roles. This will almost always lead to a loss of productivity, not just in the individual but in the rest of the team as well as they subconsciously get dragged down by it. Of course, this could be the beginning of a whole new career direction for Marcel but, in my experience, that is the exception rather than the norm.

One of the typical problems I see in teams that employ the developer/ScrumMaster dual role is that the rest of the team is slower to self-organise, and in many cases, just don’t get there. I put this down to two factors: firstly the lack of focus of the ScrumMaster (and the fact that quite often it is not the right person) holds a team back due to the lack of coaching and facilitation time available; and secondly, the implied hierarchy of one person with two roles. This person with the dual-role at least appears to be a little bit more important than the rest of the development team and this can stop the rest of the team “stepping up” and increase the feeling of responsibility of the person with the dual-role.

An option for Marcel and the team could be to rotate the role with each member of the development team taking on the dual-role for a Sprint at a time. This would remove the implied hierarchical challenges and mitigate the impacts on Marcel’s technical passion. It would also give every member of the team an opportunity to get some experience in removing impediments and serving the team, almost increasing the self-organisational capabilities of each team member in turn. However, you are almost certain to have someone in the team who is either unsuitable for this role, or not happy about taking it on and therefore are almost guaranteed to have at least one Sprint where the team struggles. Also, a big part of being an effective ScrumMaster is the networking within the organisation: knowing who to speak to and where to go when a certain problem comes up. By only giving each person one Sprint to play the role, nobody is going to get the opportunity to build up their network and “get their teeth into” the role.

Another option would be to duplicate the dual-role i.e. have two people (or possibly the whole team) who are both developer/ScrumMasters. This way whoever is least “in the zone” with their work could pick up the ScrumMaster responsibilities and the risk is spread a little. Obviously we are then bringing the sub-optimisation that comes with task switching to more people instead of one and making planning even harder and there is no focal point for impediment removal.

In this particular scenario, the team found that because Marcel couldn’t be relied upon to perform his development “heroics” others in the team had to step up technically which, although meant a short-term velocity drop, was a massive boost to long-term productivity and teamwork.

Summary

Scrum itself is not particularly prescriptive about this situation although its values of commitment and focus imply to me that it is not recommended. Also in practice it is usually sub-optimal in that it compromises both the development efforts of the individual and the effectiveness of the ScrumMaster role, usually leading to lower velocity of the team. Therefore it is probably best for this situation to be avoided wherever possible, or at least until the team is mature enough to be able to cope with a part-time ScrumMaster. The team would really have to work out how to balance things such that they have the greatest chance of success – would having Marcel fully focussing on his role as developer with a less effective ScrumMaster be better for the team than having a dual-role within the team?

A secondary consideration here is the message that the organisation is sending by not supporting the team with the ScrumMaster that Scrum requires. This is a fundamentally important role and a full-time role too. It isn’t really a question of whether the organisation can afford a ScrumMaster but rather can they afford NOT to have one? This is a question certainly worth asking. Although the options above are all valid ways of coping with the issue, a better solution would be to look at the issue itself – very much what a ScrumMaster is there to do. 

Getting RE-TRAINED to be a ScrumMaster

20th May 2010
There are only three roles in Scrum. This is often the first thing that people have difficulty with. There is no project manager in Scrum, there is no distinction between different members of a development team – they are just called team members.
The Product Owner is responsible for representing the needs of the stakeholders of the project to ensure that what gets delivered is valuable. She owns the budget for the project, determines the requirements and their importance and is judged on the return on investments (ROI) of the project.
The development team are responsible for turning the Product Backlog into potentially deployable increments of product on a sprint by sprint basis. They are a self-organising, cross-functional team who are responsible for committing to as much work as they feel they can do in a sprint and then are given the authority to do whatever they need to do to achieve the goal of that sprint.
Then there is the ScrumMaster. A term that has been so misunderstood, sometimes deliberately, as to cause confusion. The name itself leads people to incorrect assumptions due to the inclusion of the word ‘Master’. I have had people turn up to my classes believing this person is effectively the secretary of the development team or the “agile project manager”. This person is not in charge, she is not the expert, or the arbiter, or the go-between. She is not the manager of the team and certainly not the project manager under a new title.
I like to think of the word Master in a similar way to “master of ceremonies”. An effective MC has good communication skills, is calm, ensures the event runs smoothly, that protocol is followed and that the real stars are able to do what they need to do. An effective MC is adaptable such that if there are problems then they can help work past them.
The ScrumMaster has four main responsibilities:
  • Facilitation of the individuals and interactions
  • Agent of change within the organisation
  • Impediment remover
  • Remover of distance between business and development
The role of the ScrumMaster is a difficult one for a number of reasons, not least of which is the fact that they have no authority; in fact the team can fire them. A ScrumMaster will need to encourage, motivate, challenge, mediate, question, listen and sense in equal measure with the dual aims of making the rest of the Scrum team as effective as they can be and changing the organisation to be more accommodating of Scrum.
I find a lot of my time as a ScrumMaster was spent asking questions of the team and the situation in front of me, almost like I am talking to myself out loud sometimes.
Ultimately I am unimportant in this process because I am neither paying for, nor receiving, the product nor am I invested in producing it. I see my role therefore as helping those who are directly involved come to the conclusions they need to move forward. Sometimes this is easy and the team know the answer but just need to be asked a few simple questions to realise this. Sometimes it really is a complex situation where nobody knows what the answer is and the best we can do is to explore possibilities before deciding on the best answer we can find at that time. Sometimes it is necessary to let a team fail in order for them to find a better way forward. Personally I have found techniques taken from the field of coaching – reflection, questioning, drawing out goals and feedback rather than imposing – to be extremely useful in my attempts at playing the role of ScrumMaster.
So who makes a good ScrumMaster? I was asked an interesting question a while ago by someone in one of my training classes: “How would you measure if the ScrumMaster is doing a good job?”. I liked the question and first asked the class, what skills would they be looking for when trying to identify someone to fulfil the responsibilities of the ScrumMaster with no authority. We came up with the following:
  • Empathy
The ability to identify with the feelings, thoughts or attitudes of other people. To understand “where they are coming from”
  • Listener
A ScrumMaster will spend a lot of his time listening to people…really listening, so they can play things back to the team in order for them to make decisions or consolidate. They will also be spending a lot of time and energy listening to what is not being said as well
  • Networking
In order to get impediments to progress removed and push organisational change, a ScrumMaster will need to know how things get done in the organisation and who to speak to.
  • Respect
Anybody who wants to help ensure rules are upheld in an environment where they have no authority needs to have the respect of the team. Also, in order to facilitate relationships and interactions, and almost inevitably conflicts, this person needs to be respected by the team.
  • Determined
Change takes time; cultural change takes a long time. A ScrumMaster will need to be very resilient to see through this change, even within the team in which they are working.
  • Integrity
The rules of Scrum are simple but some of them will be very difficult to follow through with in the heat of battle during a project. The pressure on a ScrumMaster to bend the rules or let this one slide is immense but they are the guardian of the process. Those rules are there for a reason.
  • Tactful
Almost on a daily basis a ScrumMaster will need to help resolve conflicts or remove impediments, even challenge people to help the team move forward. The most effective ScrumMasters that I have seen have been very diplomatic in these endeavours to tackle sensitive subjects with tact.
  • Argumentative
A good ScrumMaster should not accept everything at face value. They should not just accept “the way things work around here” or be comfortable with our working habits; they should be constantly challenging them. I remember my old boss Denis saying to me once that he knew I was doing a good job because I was being a pain in the backside (he used stronger words than that) but I was doing it in a way that wasn’t endangering my job.
  • Enabler
I would say that a manager knows and directs, while a leader asks and guides. There are people who have a naturally supportive, enabling style and those who have a naturally directing style. Neither is wrong but, in my experience, people who find enabling others to be a natural and enjoyable activity take to being a ScrumMaster much better and quicker
  • Resourceful
The impediments that teams come up with will be many and varied. To get them removed quickly will involve ingenuity on many occasions. I really like the phrase “it is easier to get forgiveness than permission” when it comes to being a ScrumMaster and encourage ScrumMasters (and Scrum teams) that if they have thought about a problem and have identified a solution, that they go for it rather than ask permission.
 
Human beings seem incapable of coming up with a list these days without turning it into an acronym and so, we took this list of words and came up with the following acronym to help them remember:
Resourceful
Enabler
Tactful
Respected
Argumentative
Integrity
Networked
Empathetic listener
Determined
This turned out to be quite an appropriate acronym actually because most of the people who I have seen take on the role of ScrumMaster have had to be, to some degree or other re-trained into this new role.
Ken Schwaber and others describe the ScrumMaster as a type of servant-leader to the team; a shepherd watching over and guiding the flock. I have heard the phrase “a manager has subordinates; a leader has followers” and when we eventually worked through the question of “How would you measure if the ScrumMaster is doing a good job?” we came to the conclusion that you know if a leader is doing a bad job because people stop following you.

Does self-organisation work?

26th January 2010

I am conducting some research on one of the fundamental underpinnings of agile that has been interesting me of late. How effective is self-organisation? And also, do teams actually want to be able to self-organise or is a turn off for them?

At the moment I am gathering data so if you know of any good papers/presentations on the subject or just wouldn't mind sharing your experiences then please get in touch - geoff@inspectandadapt.com - I would be grateful.

I will also be launching a small questionnaire shortly to try and capture some more specific information on the subject and hopefully I will be presenting my findings at some conferences this year. 

Article on InfoQ

27th August 2009

A recent article of mine has been published on InfoQ if you are interested in reading it. It focusses on overcoming anxiety and fear to make Scrum stick in your organisation.

 http://www.infoq.com/articles/making-scrum-stick 

When The Going Gets Tough

17th April 2009

When the going gets tough...

 

I hear the phrase "the current climate" a lot these days and, undoubtedly things are tougher for most, if not all, companies. I worry that some companies are using it as an excuse however. I get the feeling that that there are two types of company out there, the ones that were never really serious about being agile and the ones that were (and are); these are the times that it true colours become very visible. "The current climate" quite rightly makes everyone take stock and become even more careful with what we spend our money on, driving even more for value for money and I see two opposite reactions. The companies that cut whatever costs they can (training, travel, consultants, headcount, communication media, team meetings etc) and revert back to the more comfortable world of contracts, documents, process and predictive plans. 

 

I think this is a great time because it is exactly situations like "the current climate" that we need to be agile. We need to make sure we don't let failing projects carry on forever, we need to get greater return from our projects earlier through iterative, incremental delivery and we need to stay and work together. We should invest more in our people (training etc), make sure more than ever that people get together to work through the issues on their projects, ensure tighter relations with all aspects of the project (customers, 3rd parties etc) rather than trying to "look after number 1" through tougher conditions and contracts. Agile methods such as Scrum give you a massive competitive edge and in "times like these" we need all that we can get so, to me, it screams for an agile approach. The companies that are truly behind this need to stick to their principles, because it is easy to regress and lose heart, but those that do stick at it they will surely thrive in "the current climate"

ScrumMaster & Chief Architect

16th April 2009

I was having a discussion the other day about the differences/similarities between the Chief Engineer in a Toyota-style team and the ScrumMaster in a Scrum team. This has been brought on recently by the thought in some places that the "leader" (note not manager) of the team should be technical in nature and, in the case of the chief engineer, should be even more technically competent than the team members themselves. I can see why this would have advantages, not least when applying the "Go See" principle, in software teams the place to "Go See" is the code itself. A non-technically minded person would be unable to apply this concept and thus would be unable to act as either a check on the team or a guide for the team.

 

When asked if the ScrumMaster has to be technical, my answer has always been "no". This might be because I was never technical and I seemed to cope quite well, coaxing a team of very good people to achieve and solve problems themselves - why does it need to be a manager who applies "Go See" at the code level? A lot of the most effective teams I see employ peer review far more effectively than management review. It might be because they had good people on the team.

 

An inherent danger in the ScrumMaster being the most technically capable person on the team is that it stifles the creative input of the rest of the team; they become scared of suggesting things in case they looked stupid compared to the genius that is inevitably going to come from the guru. When this person also has the hat of ScrumMaster, this can also infer some authority - of which there is none in the role of ScrumMaster. Conversely, as I understand it, Toyota's chief architect had, if not absolute power, then certainly the final say.

 

This is a similar issue to the ScrumMaster being the line manager of the team, something I also strive to avoid not because it is an inherently impossible combination but because it creates a more-likely conflict of interests and negative consequences. Achieving a high-performing, self-organising team is incredibly difficult and few teams get there. They are, in my opinion, even less likely to achieve this peak if they have a ScrumMaster with either of these types of "baggage".

 

I like the popular racing car analogy, where the Product Owner is seen as the driver, the team as the car and the ScrumMaster as the oil and instruments warning that the engine is being optimally or over-used (working at an unsustainable pace or taking risks). I believe by blurring the ScrumMaster role with the Chief Architect role this compromises the neutrality of the role which is a key balancing act in creating a high-performing team.

 

Another thing that makes me wonder if it could work is the demands on that person to remain the most technically astute person on the team - keeping their hand in - while also taking on the role of ScrumMaster, which is certainly a full time role in the beginning, if not for the first couple of years. The Chief architect role in the Toyota teams was obviously successful however, and is certainly not a model that I advocate ignoring or declaring incompatible with Scrum. I guess it just concerns me with its potential impacts on hyper-productivity.

LSUG - Team Ownership

9th April 2009

At the last meeting of the London Scrum User Group, a collection of interested people had an interesting discussion about how to get Scrum team members engaged and taking ownership of the process, especially at things like the Sprint Retrospective. The point that came up was an interest in why that feeling might have been there in the first place and this could obviously be any number of things. There is often the fear of speaking up as this could make you prone to blame, possible inhibitions in front of "seniors" or "technical experts" and so some people would rather defer to others. There is also the factor of WIIFM (what's in it for me) i.e. what benefit do I get from taking responsibility? This could be because the change effect isn't running as deep as it could be and so they don't feel that this "self-organisation thing" is really happening and perhaps there are even conflicting messages coming from other parts of the organisation about whether it is OK to make suggestions take ownership. Most of the discussions came down to a feeling about a lack of safety or a comfortable environment in which people felt OK to speak up.

Then how to create a safe environment? This is arguably something that takes time and a lot of (repaid) trust but one quick way to move in that direction is to lead by example. Sophie, one of our group, mentioned how she had deliberatly put herself "out there" and made herself vulnerable in the hope that others would follow her lead. This is arguably a brave thing to do but undoubtedly a very effective way of establishing trust in a group.

If we are talking about an experienced (in a years under the belt kind of way) as a lot of us were, this is a slightly different problem but still in the same ball park as safety. Other team members don't want to say anything that might be negated or dismissed by "the expert" and likewise, he/she is very happy with this hero-like status. A quite common technique amongst the people present was to actually ban said person from writing any code for a sprint or two and, instead, encouraging them to mentor other members of the team to explicitly try and bring their confidence levels up.

This was an interesting discussion in a pleasant, well-attended evening. I look forward to attending again soon.

The LSUG wiki can be found here and the next meeting is at The Square Pig, Holborn on 14th May

Cragilist or Scrumbut(t)

15th December 2008

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

15th December 2008

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

12th November 2008

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 generalising specialists: 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

07/10/08
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

5/10/08
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.

Keep up to date with the Inspect and Adapt Newsletter

Name: Email Address: I agree to the terms and conditions of Inspect and Adapt Subscribe
website by nerv media