Why do we need self-organisation when we have micro-management!?!

Good question!

I’ll try to explain, while avoiding a close coupling with Scrum, though some tangential references may well slip through. Let’s start by considering something which is going to be familar to the gen-X managers: Pseudo-code, a key step in structured software development (or defined s/w dev processes). As the design phase is winding down, the last level of detailing was being filled in by way of pseudo-code. Pseudo-code: a detailed description of steps of a computer was supposed to execute, but not in a programming language. This was to be simply translated into code, by a worker bee (programmer) into a computer language, viola, ofcourse we have a flawless system. The need to write pseudo-code for someone else (the worker bee/mule) is, an admission if only latently, that we are hiring dimwits. If we follow this train of thought, another conclusion looms: usage of psuedo-code is a strain of intense micro-management, and a failure to understand the real nature of programming (at least programming in the small). As an aside: devotees of big-upfront design may have diagnosed correctly, that programming in the large, brings about its own set of problems; However they have unfortunately taken the wrong pill. They can detoxify, by reading Jack Reeves thoughts on software design. BTW, the gentleman, has nothing to do with the agile jamboree, just a very clear sighted (an endangered species) thoughtful, software developer. There is nothing wrong with a limited amount of upfront design, as long as we don’t try to develop the ‘perfect’ solution, while keeping in mind that this upfront design is just a draft, which can only be final, when the software works! (testing time, anyone!?!). So, unavoidably, we have to grapple with all sorts of detail, where the devil is hiding. So who is going to do all that grappling?

This brings us nicely to consider micro-management of teams. Serious software development takes place in a far more complex and fast changing environment than ever before. The work is highly interconnected with frequent changes (and surprises) streaming in. Many competencies are involved, with many things having to come together for a a successful result. It is impossible for one manager to do all the basic thinking and detailing. Much of the simple software has already been built, and most worthy teams are left with the implementation of involved software solutions. Therefore, the manager in question has to continually re-issue instructions to the team as events occur, surprises spring, lessons knock hard and the real target (software we need, as opposed to have wanted some time ago) reveals itself. It is, I’m afraid something of a losing battle.

Instead, the manager must work more as a facilitator, who ensures that the necessary resources and tools are provided to the team, and that impediments to team deliverables are removed. Having done this, it is best for the manger to get out of the way. It is not the manager’s job to order the team around; rather, it is the team that decides on how much to commit and how to deliver (from the top of the product backlog).

Breathing down the team’s neck and micro-managing it from the outside sends a signal that the team is not responsible. It then becomes the manager’s job to commit and then worry about how to get things done. This limits productivity, innovation and creativity in the team, chokes communications and, in time, results in disengagement and apathy. Actually this state of affairs is so widespread that it is the new normal.  That is why, we should encourage self-management.

If ownership firmly rests with the team, there is greater focus, sense of responsibility and motivation to perform. Let the team manage itself. The manager’s job is to keep the focus on the bigger picture and help if the need arises. At the same time—and paradoxical though it may seem— the manager must not lose sight of the critical details (important when teams are dealing with the rest of the organisation).

So, get your team together, emphasise goals, facilitate learning, offer to help, make it clear that you are watching and then,…let go! You should rather be spending your time to prepare for a role at an n+1 level than get bogged down with the details at n-1. Potentially a depressing corollary, is that one circumstance micro-management could succeed is where the project on hand is relatively straightforward! So, maybe, that project you are so successfully micro-managing, is just a run of the mill work, where low intelligence finds a comfortable home. It would also be interesting to know what you think of the BBCs advice on micro-management. Actually if you think about it, many managers cannot even really micro-manage, but try to give the impression that they are on top of things. A waste of energy, time and in acute cases, even space.

Therefore, in general, I advise eschewing micro-management, but hold your breadth, further flutters await you….

Some thoughtful birds in my circle of acquaintances, debated over the need for managers at all (in all shapes and forms !?!). I’m all set to write about that as well, in a day or two.

Advertisement

Case for starting with longer sprints

At last something reasonably sensible here, from a big Indian services company regarding Scrum. I say reasonably, because the conclusions arrived at are largely correct, whereas a couple of points made in support reveal an underlying thinking which is slightly questionable. I shall proceed to answer the Q of an “ideal” sprint length before returning to take apart the article referred to above.

Most Scrum teams use two week sprints and a few even one week sprints.  In some organizations where iterations have been about 3 months, or more in length or even worse a classic waterfall (Before Scrum) teams have a real problem starting with two week sprints. Much of this is in the mind. It is common for people in such projects to feel (or even ‘know’) that nothing can be achieved in two weeks. So, there is considerable reluctance to pick a two week sprint. Now the question is what should be the length of the first few sprints?

Something of a storm in a tea cup, is how I see it; There is no doubt in my mind that a two week sprint (with suitably small units functionality as backlog items) is what the doctor ordered. However in these times of diminished authority, quite a few people seem to duck clinical instructions, let alone heed good advice. So, a logical (at least superficially) decision is made where in a much longer sprint length is chosen.  If it were of four weeks, that is still within the rules of Scrum, but not a good choice. I’ve even seen a two month sprint taken up as how to proceed with Scrum, which  really is a marvelous illustration of how NOT to do Scrum. Basically the underlying problem is once again the lack of realisation that Scrum is really a rather radical departure from the traditional waterfall way of completing projects. Not an embellishment of the old ways of working with the latest jargon, minus the real intent, which in turn simply results in Scrum-but.

So why is a long sprint three weeks or more a problem?

1) Loss of feedback (course correction opportunity): Essentially there are fewer opportunities for the PO and functional stakeholders to get to know the growing system and provide feedback.

2) difficulty of holding on to the “NO CHANGE RULE”, particularly the part where the sprint goal has to be held fixed; i.e no changes to the stories picked up by the team at time of SPM (sprint planning meeting) are to be allowed, is increasingly difficult to maintain as the length of sprint increases.

3) Effectiveness of retrospective: One of the most important environmental conditions for a good retrospective is that people should remember what happened during the sprint. The only other even more important condition is openness and assurance of safety. Most people cannot recall many (unremarkable, but important) details beyond last week. That’s a two week span. So once a sprint is longer than two weeks, we have a memory retention problem, unless the team maintains a detailed activity log. Yeah right!

4) Reduced planning effectiveness: As the time horizon increases, it becomes more difficult to plan for the entire timebox. It is substantially more difficult to plan a longer period of activity realistically than a short one. A weakness of long term planning ability exists in most software project groups.

In fact all the above means, it is imperative that teams improve their ability to plan (a major underlying factor is estimation, but that is another long story), make progress, correct and then build upon what has already been achieved.  Basically do the “inspect and adapt”. So in a way more opportunities the better. Hence a shorter cycles are better.

OBERVATIONS on the Cognizant article

(Overall I think the article is well written and has many aspects covered well)

Pl refer to table in the article.

A flawed line of thinking here is “Adaptation to uncertainty in story creation”, which talks about stories crossing sprint boundaries. This assumes that stories are going to be large. Actually they can be quite small. Short cycles can be handled if the organisation and team learn to break functionality into sufficiently small blocks (here is an interesting thought on this matter). This is a skill that needs to be developed, and time after time many people have discovered that the most complex application can be broken down into block that need a couple of people to work on it for a couple of days. So ideally for a two week sprint a team of about seven people about 8 to 15 stories (or sub-stories, if you prefer) can be picked up.

An argument made by armchair planners against short sprints is that the overheads will take up a greater percentage of time as a whole (as possibly being hinted by the above article; see 32,16,11 and 8 days). However for shorter sprint the planning, review and retrospective times will also come down;  Of course time spent arranging for these meetings may go up, since number of meeting per month will increase. However this is a matter of habit, if everyone soon gets used to weekly meetings (each meeting of shorter duration) this will actually be a negligible overhead, with a tremendous amount of learning and correcting being generated. So a shorter sprint is better than a longer sprint.  So item 1 “Ceremonial days” in the table isn’t quite right.

The other (more worrying) point made is that about procrastination;  Use of sprint burndown chart correctly will actually circumvent this! In fact very long sprints may just increase pressure on the team since there is a real possibility that team will struggle to meet sprint goals towards the end of a sprint. There is a real danger of falling into a serious waterfall mode every long sprint. Teams don’t seriously examine their way of working and change to get as far away as possible from the waterfall. In fact in this matter the article seems to lie on a resource (read people) utilization perspective and the worry that people are not going to be busy all the time, easily confusing activity for progress; which is fairly anti-Scrum in approach.

Another issue with the article is the point about “minimum number of days spent testing”! This is really puzzling.  Is less “testing” days better, or worse!?! I’ve no idea what this article considers better, let alone what the thinking behind this is. In reality it depends heavily on the context of the project, the abilities of the team members,  automation involved (rightly or wrongly)… so many ifs and buts. In fact Scrum does not even attempt to prescribe this.

So the main root point in favour of a long sprint is the comfort of the team and managers involved coming from a waterfall habit! This is really a question of willingness, understanding and realization of the people involved in the project. Not something to be sneered at, maybe a coach can help.  He/She must show sensitivity to this, and do all possible to show the team how to break down user stories into smaller blocks of functionality.

In closing…everything else points to shorter sprints. A two week sprint is strongly recommended and indeed used by many, many successful Scrum teams.

PS: The points made above may seem like a merciless slating of a deeply flawed article, but not so, the article itself makes many good points from a certain level of Scrum understanding.  I think it analyses the various factors of making the sprint length decision fairly well. Here I am simply attempting to provide a deeper understanding of how to think through this matter.

Retrospective: The driver for change.

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.

Strictly left footed right wing striker

Background: The Pune vodQA 2012, where I was involved, but not entirely committed(A frivolous reference to Scrum lore, about commitment, chicken and pigs) in more ways than one, was interesting instructive and illuminating! Read about it here.

Mr Chaitanya Nadkarny, a senior member of Thoughtworks consulting gave an opening talk, covering among other things which factors are going to affect the lives and careers of testers. One point he made was with regard to how testers can be generalizing specialists, or specialising generalists. It took some time for the audience (at least I did take time) to get it’s collective head around this.  Mr Nadkarny’s point here was that

One could be a performance tester (specialist), but also interested in expanding capabilities (therefore generalising) to do general functional testing, manual etc.

OR

A tester (generalist) now wants to be more skilled and focus on an area of testing, for example usability (specializing).

MAIN POST:

Since I see the world through Scrum tinted glasses, I’ve been struck by how Nadkarny has put in a nutshell the possibilities of how people develop, become more valuable and competent. Many years ago a programmer was doing most if not all activities in relation to developing systems/applications, including testing. As the field developed people became more and more specialized. Eventually in the noughties, we have extremes of specialisation. Even being a tester isn’t enough of specialisation, one is now a manual tester or an automation tester, or a performance tester. The side effect of the industry moving in this direction is that people are squeezed into ever narrower roles, even though this isn’t required and actually creates inefficiencies. Finally we have the equivalent of a striker who can only play on the right wing,  kick with his left foot, but will not head the ball into the net, even if the ball is at eye level, straight ahead and the keeper is out of position!

This attitude is so entrenched  and pervasive in some places that even managers have often fallen into the trap. People are type-cast and given no opportunity to learn new things. The Scrum team, essentially being cross-functional, would struggle to succeed if a group of super-specialists have to work together, even if they are initially willing to collaborate. Why so?

Firstly: There is little understanding of what the other person does and needs.

Secondly: Load balancing at different points in a sprint is a nightmare, as work of a given type isn’t evenly loaded throughout the duration of the sprint.

Thirdly:  Majority of work in any organisation is done by generalists, because much of the work doesn’t need a too much of specialization. How often have you visited a general practitioner vs a specialist?

Lastly and very importantly: it encourages the continuation of waterfall habits.

Time to generalize. A cross functional team would need generalizing specialists.

On the other hand, once they get there, they might then need to be specialising generalists, as well… and so it goes.

Developers are people too!

I happened to come across this absorbing article: Whales are people too! and in then the word speciesism (a one word tongue twister, say it out loud, quickly, twice in a row!)

Now, I’ve lost of count the number of managers/executives who proudly say that their organisations are doing Agile (whatever that means ) and refer to people as ‘resources’. In light of Mr D. Adams’ observation (that humans are the third most intelligent species on earth) it is possible that these enlightened managers are right after all. We are all resources.

However, on a serious note, it is worth considering, since dolphins have a strong claim to rights, if our developers also need some rights.  Also more pragmatically, always keeping  this in mind makes management effective, and true; Not a wished based glossing over the real people development and attitude issues and avoiding necessary but difficult conversations until it’s too late. A team of people, are not simply a summation of individuals, and their interactions can easily be unpredictable, someone leaving the team, could result in a productivity increase, or even velocity increase. If only developers were people.

N.B: Prima facie this is tangential, but on second glance quite central to Scrum. In this article I’m not being sarcastic, but tongue-in-cheek. (Note on N.B to some readers: These things have to be explained to most ‘resource managers’  in the ICT industry)

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).

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

Manager! Leave the team alone!

We don’t need no disruption
We don’t need no time control
No breathing down the neck in the server room
Manager, leave the team alone.

What do we do if a senior manager is asking for a ‘resource’ from within the team, in the middle of a sprint, to deal with some urgent matter?

As with a lot of things, this is better preempted, by informing as much of the surrounding organisation as possible before the start of a Scrum project, that we have to keep a team constant for at least the duration of a sprint. In other words the organisation should understand that the ‘NO CHANGE RULE’ is critical and central to the Scrum way of working.

However, senior managers may not pay sufficient attention to this or feel that whatever is occupying their minds at the moment is of utmost importance, and they can pull ‘resources’ (actually people) out without too much consideration. It is the Scrum Master’s job to protect the team, and as such does throw the Scrum Masters into a very difficult situation. The organisation culture will be a dominating factor in how people (SM included) behave. In many organisations the hierarchical structure combined usually with a command and control culture means that Scrum Masters are either powerless in face of such disruption or get into a downward spiral of de-motivation. This effect should be highlighted after the sprint end, to the management including any effects on how the team struggled to meet the sprint goal.

The Scrum Master in such circumstances should talk to the team and PO, and if applicable to the PO’s manager (who could be the senior manager in question) about the side-effects of pulling someone out mid-sprint.

Organisations where everyone is well-educated about Scrum, will seldom face such a situation without being able to make corrections and recover fast. This situation is particularly difficult in organisations which are largely ignorant of Scrum and the attendant principles. So it is important to respond to this situation without using jargon in such settings.

Speak in terms of disruption, de-motivation and relative importance of the sprint goal versus the work the pulled out ‘resource’ will do, versus the importance of adhering to the rules of the game. Such a conversation should also guide the persons making this decision to think in terms of ramifications of such requests and induce an inclination for senior managers to talk to the PO and SM before making any such requests/orders to pull out people, in the future.

All this engenders a culture where disruptions are kept to a minimum and only for good, genuine reasons. A relevant point here is the case when in response to a management edict coming from much higher-up, and in essentially a knee-jerk reaction, someone is pulled out even before it is really clear what exactly needs to be done. In other words the person pulled out cannot really begin work, since certain clarifications are still being sought. In such cases the useful practical steps to take consist of the Scrum Master taking a close look, spending sometime to discuss this with relevant team member, so they are prepared, wait till the end of the Sprint, so there is minimal disruption. Then after the sprint ends, the team can be reset, with a freshly updated backlog, which may include this ‘urgent’ piece of work; alternatively the person in question will not be part of the team for the new sprint, and works independently.