Your boss, the Invader from Mars

I was sitting at a desk, helping another Scrum Master to assess the impact of unplanned work that had been dumped on her team. Her eyes darted about as we talked, alert to the continuing threat to the Sprint Plan.Suddenly she grabbed my arm. "Duck!" she rasped. It was our boss, the Invader from Mars. He was on the prowl again with his Disruptor Gun.

How Agile Teams Handle Change

Last month we looked at how agile teams handle unplanned work such as emergencies. We saw that a lot of it boils down to queue management…the priority that items are given in a queued backlog of work. We compared Scrum and Kanban approaches to backlog management, and we saw that they respond to “the unforeseen” in quite different ways.

For example, the response by Kanban teams is potentially swift. Broadly speaking there are two mechanisms a Kanban team can use:

1. The contents of their backlog can be reprioritized to enable a reasonably zippy turnaround for urgent items. Those items that are considered less urgent will simply be pushed further back in the queue. The next available team member will action the top (most urgent) item in the backlog.

2. A “fast track” mechanism can be supported. Very high priority work will be jumped on immediately, pre-empting anything that is currently in progress. That’s the sort of immediacy of response that might be valuable in a true emergency.

The important thing to realize is that, with either mechanism, planned work ends up being delayed so that unforeseen events can “jump the queue” and be dealt with first. Clearly that’s fine as long as the work being delayed isn’t part of a wider development effort, such as a project. Support work would be an acceptable context for Kanban teams providing the type of response we have just mentioned, since each backlog item is typically isolated. The knock-on effects of a delay will be limited and should be absorbable as long as terms of service are not broken.

Projects, on the other hand, have timelines and dependencies that might be compromised by any diversions. Scrum teams, for example, are optimized for project de-risking and delivery, and will break a project up into regular time-boxes of one month or less called Sprints. At the end of each Sprint a substantial and valuable piece of the project’s scope will be delivered by a Scrum team. To this end, each Sprint will have its own backlog of work that is planned just before the Sprint commences. The work on that Sprint Backlog cannot be pre-empted without compromising the delivery of the increment. This means that, as far as Scrum teams are concerned, any unplanned work will have to be planned into a future Sprint. This can amount to a delay of up to four weeks. It’s a major restriction compared to the way Kanban teams operate…but it does allow for better project management. You get a much clearer return on investment through substantial and valuable incremental releases, each of which mitigates a significant portion of risk. That is potentially more meaningful than a Kanban-type dribble of finely grained deliverables.

How Your Boss Can Mess This Up

Every agile process needs careful fostering if its benefits are to be realized. In an agile transformation management have a duty of care to get this right. The responsibility to protect and nurture an on-going agile transition belongs not only to team members, but also to those who are sponsoring it, and who are stakeholders in its success. This includes setting organizational expectations about how different agile teams will respond to change. If a Scrum response is confused with a Kanban response, for example, then the risks to project delivery are likely to be mishandled. So now let’s ask a question. Does your boss understand the way your agile team is equipped to handle change, and communicate that understanding to the wider organization? Or does your boss make a hash of it?

To be specific:

1. Does your boss value Agile roles, and what they mean in terms of the corresponding responsibilities? For example: does he or she understand the need for effective product representation before a project is allowed to start? Is a Product Owner resourced? Also, does your boss understand that the responsibility of a leader is to serve a team by tackling their impediments, and not to manage their work? Are Scrum Masters encouraged to fulfil that remit?

2. Does your boss understand the differences between Scrum and Kanban, and the different ways in which they respond to change? Or does he or she think an agile team should be able to handle all changes immediately, while still meeting existing commitments?

3. Does your boss consult with the team, the Product Owner, and the Scrum Master before enforcing a change in priorities, cost, scope, or deadlines? Or does he or she make commitments on behalf of others, potentially breaking their plans while expecting them to pick up the pieces?

4. Does your boss value a team’s record of stable and successful delivery? Or is he or she more likely to view it as an opportunity to throw uncertainty and change their way?

5. Can your boss actually be said to manage change, and to demonstrate servant leadership themselves? Or is he or she more likely just to pass change on?

Let’s anchor these concerns to a real-world example. First, I’ll give some background to the case, and then we’ll consider each of the above points one by one.

A case study from the trenches

I was recently working as a Scrum Master within a public sector organization. The ability of such bodies to deliver strategic improvement is notoriously slow. Change is pushed down line-management hierarchies where it ends up being dealt with operationally, and my own boss was fully vested in this scheme. He was a line manager for my own developers. Bucks were passed from him to them. Unless I was able to intervene, and persuade him to modulate his approach in a less reactive manner, my team would spend much of their time fire-fighting. They would still be expected to meet originally planned delivery commitments.

This organization, and my boss, wanted to solve their problems by “becoming more agile”. However, agile methods were not implemented in place of current practices. Instead, they were layered over existing dysfunctions as a sort of veneer. The application of this veneer was achieved by co-opting a vocabulary of agile terms. Scrum terms were generally favored since they are well known and have kudos and currency. For example, the term Scrum Master was applied to certain existing roles without revising their prescribed function. In my case I was a “Delivery Manager”, a role which included some responsibilities that, in truth, crossed over into product ownership. In addition I was expected to liaise with “Project Managers” whose remit is best described as an implementation of the Management by Reporting anti-pattern. Nor was there a process wrapper for introducing agile ways of working, even though the situation arguably implied a tactical need for one.

In short, there was no appetite for genuine structural or methodological change in middle management. Tokenism was rampant, and new words were used to place a gloss and spin on organizational torpor. I’m not citing this as a particularly bloody example of a wicked problem. This kind of situation is not all that unusual. There is a culture of such inertia across the public sector, and also in some of the larger corporates. Many of you will have had experience of working in this type of environment and will be familiar with the kind of manager it produces. It’s a world of vested interests in the status quo, of not sticking your neck out, and of kicking initiatives for strategic improvement into the long grass.

Now let’s review each of the points we identified earlier. Let’s examine some of the ways my boss was able to mess an agile transition up, and try and draw some relevant lessons.

1. Failing to understand and value Agile roles

The Problem: It’s one thing to explain what agile roles mean to your boss; it’s quite another to get him to value them. My own boss was not particularly interested in roles. He was more concerned about being able to allocate resource. Seen from a certain angle this is admirable, in so far as he expected people to go to where the work was and not to get hung up on job titles. However, he failed to understand and value the responsibilities that each person in a given agile role has to fulfil. Any notionally available person - no matter how fractional their available time, or the stake they had in delivery - could potentially be a Scrum Master, Product Owner, or Developer, and thereby fill the relevant “agile check box”. The actual duties that a person was expected to perform were given little consideration when making such arrangements.

The Result: Scrum Masters did not have the authority to shield the team from interference. Product ownership was left unresolved, or in the hands of those who were not suitable stakeholders, and the minimum viable product was never clear. Developers were not encouraged to develop clear Sprint Goals with business value, and product roadmaps were fudged. Team boundaries were unclear, making inspection and adaptation difficult. The Business Case was revised post facto to match actual deliverables.

The Lesson: Make sure that you have the time and authority to fulfil your own agile role, whatever it may be, and be suspicious if your job title matches a legacy job description. Don’t allow the Product Owner role to be backfilled once a project has started, or for a project to commence with an unsized and unmanaged Product Backlog.

2. Failing to understand how agile teams handle change

The Problem: Teams were expected to handle change immediately. Kanban teams did not have a clear understanding of the quality of service they were expected to provide, or of the rules for triage and prioritization. Scrum teams would be coerced into providing a service-level response that would be better handled by Kanban teams, while Kanban teams were often expected to do project work.

The Result: The commitment of each Scrum Team to its Sprint Plan was not respected, and increments of value would not be delivered in a timely manner. The quality of service provided at a Kanban support level was variable and unfit for purpose.

The Lesson: Stay on top of the team’s metrics. Show the impact of sudden change on Sprint and Product burn-downs, or (for Kanban teams) the quality of service provided. If there is too much variability in the data to provide meaningful forecasts, show how erratic the velocity and/or cycle times are, and the consequences of this for quality and commitment-based planning.

3. Failing to consult with teams before making commitments

The Problem: My boss would sign contracts, or acquiesce to political pressure for new work, without first checking the availability of sufficient, suitably qualified team members.

The Result: Scrum Developers would be assigned to multiple separate workstreams simultaneously, and Sprint plans (which assumed dedicated resource) would be compromised. The effects of context-switching between work-streams reduced velocity still further. Delivery dates slipped and project scope was reduced.

The Lesson: Again, metrics are important. It’s important to stay on top of them, and to show the impact of such interference on delivery dates and/or velocity.

4. Failing to value team stability and a record of successful delivery

The Problem: When a team demonstrates a good track record of delivery, while others struggle, an irresponsible manager might see this as evidence of “spare capacity”. My boss interpreted performance metrics this way. If a team seemed able to meet its existing commitments then he assumed they must be “having it too easy”. He would then reassign team members to other teams, or otherwise involve them in additional, unrelated work.

The Result: Sprint Plans were compromised and increments were not delivered on time, with knock-on effects that impacted the Release Train. Delivery dates were not met, or were put at risk. Team integrity was compromised and morale fell. Team inspection and adaptation was made even more difficult as it was unclear who was genuinely on the team. Forecasting became impractical and stakeholders could not be assured regarding timely delivery.

The Lesson: An information radiator can be used against a team, if it is misinterpreted. In this case, a healthy burn rate was thought to be evidence of excess capacity. Although little can be done against a calculated and deliberate misinterpretation of data, it is better to try and get your boss to add work to the team’s backlog rather than to see him pull team members out. That way, the team itself will be able to self-organize in order to handle the work. It will retain its integrity and be able to inspect, adapt, and produce metrics that can be compared from one iteration to the next.

5. A failure to manage change and to demonstrate effective Servant Leadership

The Problem: Traditional line-management structures encourage the delegation of work. Unfortunately, they can also encourage the dereliction of responsibility. For many line managers the path of least resistance is to pass change on to those who fall under their authority, almost in the manner of a pipe or conduit, and without modulating the demand or otherwise adding to the value stream. This stands in contrast to the model of Servant Leadership, in which managers will defend teams against diversion and interruption, and facilitate a team’s ability to deliver on the commitments it has been able to make. Our boss saw teams as being there to serve him, and not the other way around.

The Result: By not being a servant leader, this manager set a poor example to others. He commanded little respect among the teams. I remember that he was frequently referred to as “Captain Chaos”. Interestingly, the failure to manage change was reflected in an inability to manage his own commitments – for example, the chance of him attending meetings was rather less than 50%, even when he had asked for those meetings himself.

The Lesson: Every manager - and not just Scrum Masters - should follow the principle of servant leadership. After all, it is the teams that deliver the work, not the managers above them. Managers must therefore be seen to add value if they are to be respected. Many struggle with this. Effective servant leadership involves insulating teams from diversions and distractions, and providing them with an environment that optimizes their performance.

Conclusion

A good manager will protect teams, and nurture an agile transformation by clearly demonstrating the principle of Servant Leadership. Unfortunately, not every manager is a good one. Even if there is a commitment to agile transitioning at a senior level, and even if the teams themselves are behind the initiative, most organizations will have middle managers who are not entirely on board. These people are quite capable of scuppering a move towards agility at scale. They can often be seen stalking the corridors like alien belligerents, looking for teams and projects they can zap with their Chaos Ray. They need careful handling.

Here are the top three tips I’d give:

1. Keep as tight a grip as possible on agile roles, and accept no compromise regarding the associated duties and responsibilities. For example, if a Product Owner isn’t a stakeholder who values the product, nor able to prioritize its features, don’t go along with the pretense that the project is ready to start.

2. Do everything you can to maintain the integrity of a development team. It’s better to take on unrelated work (waste) than to lose a developer. Make the matter a prioritization and product ownership issue instead. As a rule, agile teams are better able to handle uncertainty in scope than uncertainty in their composition.

3. Value metrics and transparency without feeling intimidated. A manager can exploit a team by misconstruing the data it provides, so express it carefully and be alert for any sign of abuse. Highlight the risks that an unwarranted change will present, and redo forecasts, dashboards, and RAID logs as necessary.