There are many agile software development practices that require changes in middle and upper management to be effective, or work at all.
OPTIMIZING FOR FLOW RATHER THAN RESOURCE UTILIZATION
This change is counterintuitive for most of us. Work is no longer assigned, it is prepared and made available to be pulled by individuals or teams based on their capacity and competence. This comes across as a radical shift in mindset that middle management needs to live, and upper management needs to understand. There is no longer direct control over who does what, or if they’re doing anything at all. Are you ready to trust that people will actually choose to do useful work?
LIMITING WORK IN PROGRESS
To achieve flow, we need to do less stuff. Limiting work in progress has moderate effect if nothing changes upstream. You need to limit the number of initiatives or projects as well. This means you need a different approach to portfolio management. Management must understand why, and help share this understanding with all stakeholders.
EMBRACING UNCERTAINTY
An agile team isn’t stoked about estimates, deadlines or detailed roadmaps. They still plan and analyze, but prefer to do small scale tests and experiments to prove or disprove a theory. If unexpected things happen during implementation, we see this as a valuable learning experience instead of a threat. Adjusting course based on things we learn during our journey, will help us build a better product.
The trade off is that at the beginning we know very little. Upfront information about exact cost or delivery date is not available. This has consequences above the team level. As a manager, it is difficult to see uncertainty as a good thing. However, every decision made and date promised, means less room to navigate in the future. To be agile means to commit at the latest possible moment.
Every decision made and date promised, means less room to navigate in the future.
FREQUENT DELIVERY
Instead of accepting large bodies of work with a fixed delivery date, agile teams prefer to deliver small, frequent changes. «Save early, save often.» If you screw up (and you will), going back isn’t too hard (or humiliating).
That big change you requested will be delivered in increments. The team roll their eyes at the detailed specification you spent days writing, but insist that you are available for questions and discussions throughout. The customer may get incomplete features that provide some value, but not all the functionality she requested. We mark some features as Beta, others are only available to select customers until it has been battle tested.
This requires good relations and good information flow between you and your customers. To deliver incomplete stuff enables an opportunity for feedback, and subsequently better products. Both customers and management needs help understanding this.
PERMANENT TEAMS
Agile developers prefer to work in permanent (or at least semi permanent) teams, and build technical and domain understanding over time. The teams are often not just technical, but rather focused around a product or service. The team include many if not all required roles. This is difficult in a project organization that fund and staff every effort individually. The organization should instead fund the permanent capability to build products.
Instead of funding projects, you should fund the permanent capability to build products.
We’ve established that the model for funding and budgeting needs to change. Needless to say, the team can’t carry out this change alone, so again management needs to get involved.
This shift also leads to an interesting effect during prioritization and triage. The discussions are no longer about funding and cost, but about value and cost of delay. How long are we willing to let this initiative block our development pipeline? What is the consequence of delaying our other options during this time, as opposed to delaying this option? Can we do the most important part of this now, and the rest later (if we still want to)?
TRANSPARENCY
Traditional companies are usually a bunch of silos with different goals and objectives. Some even do internal invoicing (don’t get me started). Information is often seen as a valuable commodity used for politics and rarely openly available.
An agile team value transparency and sharing above all. When everyone involved share the same view of the world, we spend less time on misunderstandings and wasted efforts. The transparent, inquisitive nature and brutal honesty of a mature agile team can be uncomfortable for managers. Suddenly the reply is «Why» or even «No» instead of «Yes, sir». The project status is «We are drowning in technical debt and our speed is approaching zero» instead of «Green». The brutal reality that middle management used to cover up, is suddenly available to everyone including the CEO.
The brutal reality that middle management used to cover up, is suddenly available to everyone including the CEO.
IN SUMMARY
To keep this post short, I didn’t explain in depth why the above changes makes sense. Google is your friend, or read a book. A crucial change when moving to agile, is to value learning and the “Sharpening of the saw” over delivery and busywork. Were you about to respond that you don’t have time to read and learn new things? You got that reversed. You don’t have the time to not read and learn new things.
Many of the changes you do when moving to agile might seem technical at first glance. When implemented as intended, the claws of agile will extend to every corner of your organization.
You might as well prepare, because sooner or later agile will happen to you too.
Follow me on Twitter: @Tsigberg
(This article originally appeared in @thorbjorn.sigberg’s Medium stream.)