Sprint Review undone: Part-I

I was recently present at an attempted Sprint Review Meeting for a team I was coaching. They were struggling to get finished by the time of the meeting, and by the appointed time could not get the functionality ready. The problem was that they had picked eight items, and could not even demonstrate one item, and this was their second sprint! They had earlier done a sprint zero, with many of it’s attendant problems which are described here. Now my overall  analysis of how this situation came to pass is at two levels:

1. Poor habits carried over from the waterfall days.

2. Lack of prioritization within the sprint.

Over and above this is the matter of a somewhat diluted DoD (a separate topic in itself) which is bad news being stored for the future. This team was working with a weak DoD, which was seemingly clear to them (For some one who reads tea leaves in his spare time, this is an ominous sign)

In this post I’ll explain the  first point. Within the sprint, each story was done strictly in a waterfall manner, including hand-offs. This not withstanding all the training the team and managers were given. Which meant, that the burndown chart, while warning about bad news, actually did not quite manage to reveal the really bad news. That nothing was actually ‘done’ ( this does not mean the team did not do anything). Suddenly towards the end of the sprint 4  user stories  were 90% done, and as the old saw goes, the remaining 10% takes the other 90% of time. The other 4 items were in even lower levels of completion. However what was the actual completion is moot.  Even more importantly, trying to find out the true completion percentage is missing the point. The team at the time of the sprint review, should try to keep the done/undone as binary as brutally as possible. Try to see it, standing in the PO’s shoes.

So what is to be done? Avoid waterfall. How? Especially given that the team is already facing too much change for comfort (One reason why many teams don’t see successful sprints early on).  Assuming they haven’t changed their technical practices yet (very common for teams starting off on Scrum), the first step is to try to break-down user stories to even smaller units of functionality, whose completion should be staggered across the sprint. Another approach that can be simultaneously used is  to write acceptance tests as the stories are picked up. This means that the team can test the stories (to some extent) at a very early stage, hence testing early and (hopefully) often.  A very good idea.

The above ideas are a reason why teams aiming to succeed have to change their ways of working and learn to breakdown stories and change the approach to testing among other things.

In the next post I’ll explain the other practical step to take (if you haven’t guessed already).

Advertisement

Handling changes in Scrum

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.

 

All s/w development projects have greater or fewer changes to be incorporated after the start of development. So how are changes handled in Scrum? and more importantly why are they handled in the manner described/recommended by Scrum?

Basically in Scrum the top few items of a product backlog (the highest priority ones) are chosen for any given sprint. The remaining items, can be modified by the product owner as he/she pleases at any time. As an aside, there has been some recent talk about the backlog not being prioritised, but ordered. I’m less than impressed by that explication.

Since Scrum is supposed to take care of changing functional/non-functional needs over time, the germane question is “How do we handle changes within a sprint/iteration?” in other words “how do we handle changes to the sprint goal?”. This is a recurring question, and the answer lies in correctly understanding the intent of Scrum.  Scrum’s intent is to provide a means, an island of stability where a complex project can be run smoothly, even though the environment around is in flux. This island of stability  is ensured by the “NO CHANGE RULE”. Which means no change in duration, goal or team for any given sprint.

See the following post for the reasoning on keeping the team fixed. Here I’ll essentially cover how and why of keeping the goal fixed.

There are two cases which cover changes to sprint goal

1. Urgent bug-fixes which may turn up at any time, hence cannot be foreseen at the time of the Sprint Planning Meeting (SPM)

2. Change requests to the selected product backlog items

These two cases are to be handled in radically different manner. For the first case the team can inspect and adapt to choose a means of dealing with bug fixes, by either keeping a percentage of available time (say 10 to 15%)  aside as contingency or by rotation having one or two team members on stand-by to handle the bug-fixes as and when they turn up. In other words this is being prepared for the unpredictable. The second case is severely discouraged and is  handled by not taking it up in the current sprint! This may seem extreme, but there is sound reasoning underlying this approach.

First and foremost, if change requests are allowed at any time within a sprint, there is no line drawn as to how much of change is allowed. Given human nature this will result in any amount of change being allowed any number of times with any sprint. What is the implication of this on the usefulness of the SPM? We are very possibly on a slippery slope by allowing a change in sprint goal, mid-sprint. Essentially, by having this rule, we are creating an island of stability.

Secondly, the reason we have sprints with items being pulled into any given sprint, is to accommodate change. This means at a project level change to functionality is handled in an orderly fashion as well as a welcoming manner.

Thirdly, and this will be difficult to stomach for some stakeholders,  a significant amount of change is due to lazy thinking early on. In other words quite a few of the change requests are a result of not thinking through what is needed. While it is recognized that the PO/customer cannot always know everything that is required in detail, up-front, what this rule does is encourage reasonably detailed analysis of the items which are at the top of the backlog. When the PO is confronted, with a situation where he/she/it (How PC am I becoming!?!) has thought of a change and has to wait till the next sprint, this is a stimulus for more careful thinking before and during the following SPMs.

The encompassing principle above is that Scrum is a system that encourages corrective behaviour from the stakeholders, while maintaning a balance between accommodating change and reducing avoidable waste due to lazy change.

Two further points:

1. Scrum does NOT need (in fact discourages)  to have the functionality described in every detail at the starting of the sprint! Then, how in the blue blazes are we supposed to keep change at bay, as clarifications are made during the sprint!?! There is another simple rule in play “If in doubt, it is the team that decides whether it is a change or clarification”. In case of clarification the team simply implements, in case of change, it gets put away for following sprints.

2. What if there is an utterly, unavoidably, compellingly, the-sky-is-falling-on-our-collective-heads, URGENT change of sprint goal, in the middle of the sprint!?! Either a change to an item picked in the current sprint, or an altogether new item added.

Well, indeed if it is THAT important, follow Scrum by the book!

i. Terminate the sprint

ii. Inform all stakeholders

iii. Immediately start a new SPM for a sprint, of what-ever length, that makes sense for the explosive circumstance. Does one need to do a full SPM (of 4 hrs?), not really. Exceptional circumstances can mean that just the new/changed item is to be dealt with in the planning.

Any loss of time/money/delay due to this decision is made in full knowledge by the PO.

Again note, that this is a highly disruptive, but necessary change, and is widely visible. Not to be undertaken lightly. After all if there is a serious earthquake, the sprint goal will change.

Scrum as a transparency mirror

My experiences of coaching teams and hand-holding organisations in taking up Scrum have revealed a curious inductive pattern depending on the type of work environment. A group which is generally genuinely responsible and transparent would take to the practices of Scrum in letter and spirit, like a duck to water. However, equally true is the case of an organisation/group wallowing in apathy and complacency. Such organisations have a very large portion of managers who are essentially set in their ways and have an overriding (but short sighted) interest in maintaining status quo.  Any change makes them deeply uncomfortable. It takes time to understand just how deeply buried this resistance is in the sub-conscious of such managers. They are befuddled and unable to view a very different future which at the same time is frighteningly unfamiliar with any enthusiasm. As someone said “the raison d’etre of middle managers is to resist any improvement”, which implies that the management layer has been set up to run a bureaucracy and not an ever improving organisation. This in itself is a very dismal revelation and an example of what Scrum uncannily exposes: Your management is less than useless, they are actually a liability. Their only use is to run things in the same chaotic manner today and tomorrow and the day after…and their weapons of choice being pressure and manipulation.  The reactions of managers who are suddenly confronted with Scrum, something that requires much greater transparency and direct execution, ranges from apathy to passive resistance to delusional arguments and even the dismissal of the entire idea of Scrum as unworkable (however without a clear line of reasoning based on knowledge).  So the questions to consider are: are you prepared to make deep, possibly unsettling changes for a better tomorrow? Will you do it by infusing a truly transparent culture? (Transparency need not mean surrendering your trade secrets; It first of all means being honest to yourself).  You will in all possibility have to catch the pig! And Scrum is an excellent means and in this manner of engendering transparency, is an end in itself.

Commitment Under Pressure

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