Scrum Exposes Bad Processes and Obstacles
In our last post, we discussed the Agile Retrospective technique of Start, Stop, Continue or SSC. In this, post we discuss a technique first tried by Pete Deemer [CST, co-leader of Yahoo’s implementation of Scrum].
Often, as the end of a sprint, the team comes back and says things like
- Its more stressful in Agile
- Things are worse than before
- Agile does not work
- We were better off before
If as a Process Coach or Scrum Master you hear something like this, you can try this in your retrospectives:
- Ask the team to collectively come up with a list of things they thing are better than before/ is working well and also what is not working well/ worse than before. So, you have two lists : Better and Worse.
- Now ask each member to mark each item on both the lists from three possible options : Caused by Scrum [C]/ Agile, Exposed/ Made Visible by Scrum or Agile [E], Does not relate to Scrum/ Agile [U].
- Compile the score and let there be pin drop silence in the retrospective.
- The team may find a lot of C’s on the “What’s Working Well or is Better than Before” side of the board, and a lot of E’s on the “What Could Work Better or What is Worse than Before ”; this is good news, even if the “What Could Work Better” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.
- The team’s opinion and acceptance of Agile/ Scrum would have undergone a complete 180 degrees turn.
It is often useful to keep a snapshot of the whiteboard where these lists are maintained and keep revisiting them in each of the Retrospectives. This is especially useful for the teams which are transitioning to Scrum or Agile way of working.
Agile Diary, Agile Introduction, Agile Implementation 
April 8, 2009 at 6:52 am
I’m just curious… What if there are more or less equal number of C’s and E’s? For me scrum or agile is not the silver bullet (neither is any other methodology). You’ll find a lot of projects where implementing Scrum will bring you a lot of E’s and that’s great. On the other hand sometimes it’s enough to see few major C’s to end up with poor opinion about the whole thing.
To give you one of most common examples – if the customer is not willing to play the agile game and doesn’t give consistent feedback on the work team does you lose one of the greatest powers of agile. What more the customer can actually expect you’ll deliver detailed specification up-front and and you’ll build according to specification (as they don’t want to put any additional effort during development process). In this kind environment, which is pretty popular in big organizations, you can use Scrum barely as a way of internal organization of software development process and not much more.
Whether this would trump current software development methodology – that’s an individual question with no default answer.
April 8, 2009 at 2:35 pm
I’m not sure how what you’ve described works towards solving anything. From my perspective and experience with scrum your first 4 steps don’t lead to your conclusion (which seems to be in step 5).
So there is a BVC (Big visible Chart). Now what? That makes things better? It seems like this is your point. I would argue that just becuase your team sees the things that scrum caused or didn’t cause or made better doesn’t mean they are going to change their opinion.
Here are some context issues that your approach leaves out
1) It assumes that putting stickers on board or keeping a secret list during voting somehow removes pressure and bias making the votiing more “real”. Some people are influenced by where they see other people putting their stickers. This skews the results.
When keeping a personal written list people are also influenced by the immediacy bias. There are issues that happened at the beginning of the sprint that I don’t remember anymore but they were big issues at the time. That doesn’t mean those issues are any less important. Keeping a “private” list and then tallying a score doesn’t let me learn or change my vote based on information brought to light during the meeting. This is a real shame.
Here is an experiment – stand back and watch the people putting the stickers on the board or if you are putting the list on paper look at how people who are “friends” vote. What were they doing just before they came in? Who were they talking to? What were that person’s issues?
2) If you have more developers than testers – dev issues will overtake testing issues – NEARLY EVERY TIME. Test issues will NEVER bubble up to the top. (until your list gets very very short). I speak from experience.
3) If you have more than 1 person in a room doing something like votiing on issues that can/might be emotionaly charged – you aren’t going to be able to get pin-drop silence. Especially if someone gets an emergency call or even a non-emergency one. Why must there be silence anyway?
4) It seems like you are saying that by seeing all this information that people’s opinions are going to change 180 degrees for the BETTTER. Have you thought that for some their opinion migh change for the worse when they see that the list of things that “got worse” is much longer than the list that “got better”
Scrum isn’t the catalyst for change – PEOPLE ARE THE CATLYST FOR CHANGE. Even after the list is compiled, scored and ranked it’s not going to change unless PEOPLE change.
So I’d love to work together with you to figure out how can we help people change.
April 9, 2009 at 8:38 am
@ Pawel – I agree that Agile or Scrum is not a silver bullet. It is just one of the many good frameworks out there which people can use to aid them, but eventually things would have to be done by people. Scrum or Agile does not replace the need to get good quality people and people environment.
April 9, 2009 at 8:51 am
@ Adam : You make interesting points. However, I would like to offer some more points to discuss this further:
a. People influence people and I believe they should. How about mixing the two approaches? You all go to this big black room where you can post your card in front of issues, while still seeing what others did but without others seeing the same.
b. When would you have more developers than testers? In the team I work with there are only two graphics artists but more than 10 developers and this still does not cause the balance to shift.
c. Silence is for people to stop giving immediate response to what someone is saying or doing, and delay responses. It is to allow people to comprehend better. It could very well be that during the silence people are dreaming about their date tonight, but a good Scrum Master will bring these people back. It is not a question of Scrum or no Scrum really but the technique and in my experience it works.
d. This post is written based on experiences of Pete Deemer at Yahoo [with multiple teams] as well as my own with teams at 04 organizations. The 180 degree always strengthened the belief that Scrum framework should be continued.
Also, I started the post saying this is something you could try. Its not a definite that it will yield results. But in true Agile fashion, you should then inspect and adapt and think of something else.
April 9, 2009 at 1:14 pm
Vikrama,
a. I’m not sure I understand what you mean. Can you explain it further?
b. In my company there are always more developers than testers.
c. I understand what you mean now. However having complete silence in a room full of adults may be a bit unrealistic.
d. I don’t share the same experiences
What else is something I could try? Give me more options? You mentioned other frameworks. Tell me about the pros and cons of those ones.
April 10, 2009 at 5:20 pm
a. Lets me give an example from a discussion I had today. We were designing an interface and one design had been finalized. Only I was not comfortable with it. I got everyone there [Lead Designer, Business Analyst, Development Manager] in the room and argued passionately about what I expected. They argued too. All 03 were influenced finally by what I said [or should I say – understood and appreciated my point so much that they gave up their point]. Is this influence bad? Yes, if what I aruged for was not good enough, or all I did was use my position [none of them reports to me] to get it done. What is the harm in people/ group of people influencing others? What if anything at all would get done without influence? In case of a new team – a method they can try is book a conference room with a whiteboard. Each person can keep writing their points on the whiteboard without anyone present [that way only they are in the room]. They can see what all everyone has written and go with it or add more. The people who went first, can go back again too. I think we are getting theoretical here. If a group can not argue without hurting someone or only if some people get their way always, then there is a deeper problem. We should address that first.
b. Why are there people who are developers and testers? Why are both jobs not being done by all?
c. It is not. I have achieved this multiple times.
d. That’s fine. Is that because of the technique, because I got it to work positively more than once.
Other retrospective options are mentioned in the book by the same name. My favorite is time mapping. Help people imagine [without giving cues] on what they want to see next sprint review and what is it that they can do to get there. Silence and group discussions are a key to any effective retrospective.
April 10, 2009 at 7:14 pm
a. I understand your example now. I think people should influence people too.
We are getting theoritical. So how would we address the deeper problem?
b. Why are there seperate roles? Not sure. We might as well all do the same job since we are all equally skilled – right? Developers love to break their own stuff and are skilled at it. After all – they know where they put the bugs. 🙂
Curious – Why is that we don’t need specialization in writting software but the business needs specialization to run? Why do we need a CEO, CFO, and CTO? Maybe we should get rid of these roles and let everyone do software development and run the business equally. It’s not that far of stretch. Kind of an intersting thought.
c. I think that’s great! How did you achieve this? How many people where in the room?
d. You mentioned that you got this to work postively more than once. This begs the question how many times did it NOT work postively for you? How many times did people think scrum wasn’t the way after seeing the list?
I can’t find the book you mention using a google search for “Retrospective Options”. Can you post a link to it?
When I was asking for other options I meant outside the realm of scrum style retrospectives. What are my options if I’m not doing scrum?
April 11, 2009 at 12:16 pm
1. The deeper problem is why people can’t argue/ discuss without having to use their power/ position to get things done? Should not everyone agree on what is the best thing to do – on what is being said, rather than who is saying it? How to achieve that culture? That is the aim of retrospective.
2. Just because business has specialization, does not mean we should have it in writing software. The concept is that you have a team, some people are more skilled at something, but overall people should be able to adapt as per the demand.
3. There are 14 people in the room. I achieved it by speaking and that was it.
4. It has worked positively on all occasions I tried [which is 04]. The book is http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649 – Although it says this is Agile Retrospectives, you do not need Scrum/ Agile to implement them.