Retrospective: The driver for change.

9 Comments

Ensuring that the retrospective makes a real difference

This post is only partly in response to an observation made here that retrospectives were found to be generally useless. Having said that the practical tips in the above post are valuable.

I think the feeling (or even reality in some places) that retrospectives are a distraction is due to a few factors

1. The software development organisation, as a rule, doesn’t have a culture of self-improvement (neither developers nor managers)

2. Many teams struggle just to get to the sprint end date meeting the sprint goals and lose stamina by then (an important tip is covering this). Oh, yes I’ll not be in the least surprised if the cause of this is organisational pressure applied onto the development team. Similarly this pressure will lead to ineffective retrospectives.

3. Poor visibility, hence support for getting action items done (also mentioned and dissected here)

Retrospective is the driver for change generated by the team (and possibly anything that the SM points out). So after the lovely discussion how do we actually make the change? Hopefully the Scrum Master and the team have identified action items (not always easy, not always correctly done), but even so, some of them will be straightforward.

It is all a matter of perspective: Encourage all concerned to view the retrospective as a driver of change; and I think it’ll have a very different effect. At some point (ideally the beginning) of the project, or when the team is getting stuck, floundering etc., it has to be said “There are things that are not quite right around here. We need to change, bit by bit; Let’s use the retro”. Wonderbar! but how?

TIP: Suppose these action items were to be put into the Product backlog. This is an extension of suggestion here. A bit radical, eh what!?! as normally the product backlog is reserved to deliver something for the PO or external stakeholder.

caveats: Some action items need a lot of work/effort to be made and teams tend to drop these items from their to-dos, so these could go into the product backlog. Not all action items need go into the product backlog, as some can be done by the Scrum Master, some by the development manager (hopefully) and some are simple to do.

Coming back to the suggestion: What is the effect of putting retrospective items into the product-backlog? It certainly gets attention (visibility), and these items also get budgeted. More importantly a lot of careful thought based on experience WILL get acted upon. But there is something of a dilemma here, as then the PO gets to prioritize the action items! How would a PO react? What does the PO’s reaction tell us? Something of a litmus test, as to how well the whole team, SM and product owner understand the principles and imbibe the ethos of Scrum. This may often mean that the coach/Scrum Master will have some convincing/cajoling to do. However, while it may take time, eventually the team and organisation around it can see the effect of doing/ignoring retrospective action items (as there is greater visibility). Yes, it also gives the Scrum Master a great handle to encourage improvement via these action items.

WHEN NOT TO RETROSPECT: (ideally a separate post, but I’ve the first quality of a programmer)

I’ve as a coach often observed  teams which struggle to meet the sprint end deadline and led and facilitated their retrospectives. A team that takes it’s commitment seriously is at a disadvantage, as they have been working overtime for the last few days (nights!!?!). This usually means that their sprint review meeting, in such circumstances doesn’t go like a bomb, (don’t bother this link if you are from the UK/antipodes). By the time they are done with the review they are tired, somewhat dispirited and possibly uninterested. TIP: Give the team some recovery time. Don’t hurry into a retrospective under such a sepulchral atmosphere on the same day. Don’t hurry the retro to get on with the next sprint. You almost surely will be failing to learn. An ineffective hurried retro is time wasted, a longer one with sensible action points (which get acted upon) is valuable learning and a “velocity+morale” booster. If you must, hold a 30 min debrief. Especially, if the next day is a working day, people will be late, and the retrospective must be conducted well. So the main body of the retrospective should be around lunch the day  and concluded after lunch. This is to give team members time, discuss formally(during meeting) as well as informally (over lunch). In case the sprint ended on Friday evening, we can conduct the retrospective on Monday morning (with a long coffee break in between). But do make sure that at least three action items are identified and people commit to acting upon them (maybe put them into the product backlog). There must be visible progress over time, else each following retrospective would become more useless than the last (ironically, the reverse result for the retrospective itself, opposed it it’s intention for the project).

I’ve generally seen teams benefit from decently conducted retrospectives. As time passes and the retrospective action items become larger and more difficult this improvement slows down. This is where higher visibility (as suggested here) and perseverance will pay dividends. Good luck and God speed.

Commitment Under Pressure

2 Comments

Srinivas is the co-author of “Essentials of Scrum practice“- a mini-book
currently in a draft stage. This is an extract from the book.

Pressure pushing down on me
Pressing down on you no man ask for
Under pressure that burns a building down
Splits a family in two
Puts people on streets
It's the terror of knowing
What this world is about
Watching some good friends
Screaming let me out

The hidden hobbler of Scrum teams: Pressure

One common problem Scrum teams face is in the difficulty of meeting their sprint goals, followed by increasing pressure, which seems never-ending. Such teams don’t see sustained significant improvement and can quickly fall into a death march mode, or a jaded plodding with longer hours but no end in sight. Such situations are due to their choosing sprint goals (targets) under duress in some form. The ill effects of such commitments are not easy to understand or link to the cause. The inviolate Scrum principle in this regard is that the team chooses the extent of the backlog which it’ll deliver. Team requires to have a fair shot at making an independent, free commitment for their sprint, after all they are the ones who do the work. Mainly managements are worried that the teams will under commit. Hence they may treat the whole affair as a negotiation game.  As entertaining explication of such games is provided by Rob Thomsett. Software development is very commonly done under pressure, and this makes it seem as though this is very normal, and possibly the only way to work. A good anti-dote to such thinking can be found within Tom DeMarco’s entertaining “Slack”.

What do we do when the pressure to finish is so much, that there is no choice left to the team.
Don’t buckle under pressure, and stick to the Scrum principle (i.e make an independent and genuine commitment), however this is much easier said than done. Many projects have deadlines in some form, based on a marketing wish or executive fiat. Since organisations need to make plans, what upper management wishes for, may be necessary. Trouble is in the making, when this wish is widely out of line with reality. What organisations do poorly, is handle the difference between an original high level plan (based on executive wish or even a high level estimate) and the reality as the devil in the details appear. The Scrum approach is to do planning in small bits (2 weeks) and improve continuously by ‘inspect and adapt’. In our experience, far too many projects and managers are worried about the success of any given sprint and don’t give a chance for the team to learn and improve, hence endangering a number of future sprints and ultimately the entire project. A difference is made if a couple of steps were to be taken before the sprint starts:

1. Get an agreement from management that the team be free to choose the extent of work they commit to; offer to be transparent regarding why such a choice is made.
Essentially this means that the details of the sprint planning meeting is made available to the larger organisation. Management also needs to support the Scrum Master in his/her task of protecting the team from any external pressure. Now the Scrum Masters job is easier, if he/she also provides transparency into the Sprint Planning Meeting, by highlighting significant events in a MOM, as well as, circulating the sprint backlog/plan itself after the meeting. Normally the sprint backlog, with estimated hours for each task totaled and compared with available time, will give a realistic view of what is within the realm of possibility for the team to take up.

2. Explain the distinction between a real commitment that the team makes, believes in, as well as is serious about, as opposed to a perfunctory commitment made under duress.
Pressure to finish fast exists in most organisations. However, better the protection a team can be provided, to demonstrate to the team that their honest views are truly valued, better the commitment from the team and the teams attempt to meet this commitment. Fair and transparent planning will mean that team will not knowingly under-commit. Once a true commitment is in place the team, they should be supported by the Scrum Master and the management will do all in their power to meet the sprint goals. An unrealistic deadline imposed may make the team work harder, but they are unlikely to learn and also this will not be sustainable. In fact there is a very good chance that team members will take a fair stab at pretending to work hard. What the Scrum Master and the management can do is replace pressure with motivation. Any pressure must only be peer pressure, generated naturally, not imposed from higher up.

An intangible, but important effect of an open transparent sprint commitment made freely, is that the team sees it’s opinion valued even by management. They are being treated as professionals. I’ve yet to hear of any one, however powerful, saying to a surgeon “You have to do my gall bladder operation in 45 mins, now! and not take 3 hours as you say it’ll take”.

Further more, if after all this discussion we still have a situation where pressure cannot be held off, either due to the unwillingness of people to be open, or the unwillingness of management (briefly glossing over the fact that management also consists of people, of  a sort) to accept bad news, then the Scrum master must present the actual versus the hoped for amount of functionality delivered after the sprint in a neutral communication as a means for the organisation to learn. Many organisations take time to learn so this can be a long drawn out process. Remember Scrum Masters can do this easily, if they are not directly responsible for the success of any and every given sprint, which is typically the case with a project lead. It is well worth noting that a ScrumMaster is not a new glorified label project lead, but an enabler and protector of a team, which alone is responsible for delivery.

Finally, a thought on how breaking the Scrum principle leads to long term undesirable side effects. When the team members realise, that management just wants unrealistic results and is unwilling to listen and act upon information provided in good faith by the team, their motivation drops. Also they have no further incentive to provide bad news ahead of time, and the slide to micro-management is fast. This also means they stop caring for the project as professional pride is buried. Therefore they will go through the motions; not the most inspiring and driven crew, who will be apathetic at the best of times or even hostile.

Pressure pushing down on me
Pressing down on you no man ask for
Under pressure – that burns a building
down
Splits a family in two
Puts people on streets
It’s the terror of knowing
What this world is about
Watching some good friends
Screaming let me out