This article is the fifth part of a series on: The end of the agile world hasn’t come. Read part 4 here.
Responding to change over following a plan. Probably one of the most difficult agile values to cope with.
The first reaction when panic is knocking on the door – because your deadlines are approaching, because team work has been a mess in a past weeks, or because managers can’t understand why their team is so slow and expensive compared to the expected results – is to build a plan. And a contingency plan. And a contingency plan B. And build them with a beautiful retro-planning manner.
Plans make us feel safe.
I know what I’m talking about: I’m a product guy. I have some project management background. I’m the guy writing the roadmaps. You know, those nice Gantt-chart looking things that lead to believe the way is paved until 5 years from now. I can even make them look nice, with beautiful colors, icons and fonts. And I like rules which put a bit of order where chaos reigns.
But you know what? I’m from the Matrix movie generation. And there’s one thing I learnt from Morpheus:
What you must learn is that these rules are no different that the rules of a computer system. Some of them can be bent. Others can be broken.
Challenge your roadmap
I strongly believe that plans should be written, in that their direct benefit is communication within the team. And better a short story than a long one, when on paper, remember?
But I’m also well aware that it’s impossible to write a plan that will be executed in its entirety, as written on day one. Especially within the current context of software development. Both internal and external forces will do anything they can to bring you roadmap to the ground. Some examples:
- New client feature requests with ultra-high priority
- A developer leaving the company (sick, holidays, or even resignation), together with some crucial and unique know-how
- A bug crashes your product/a third party service fails to deliver, killing your service/a server goes down
- Reality catching up with your retro-planning
- New investor onboard
A lot of unforseen events that will directly impact your ability to deliver.
What this agile value tells us, here again, is not that plans shouldn’t be written. It tells us they should be flexible.
They should be a guideline, which should be reviewed on a regular basis. In other words: a roadmap is a living organism.
Challenge your organisation
And so it goes for the entire organisation.
Concepts such as continuous integration, software test automation and daily releases start being trendy in tech companies, as they promote the capacity to deliver software on regular & short periods of time. But that’s just software. Humans rule over it. And humans must be ready to accept that a schedule changes from one week to the other. That a feature which was once seen as cutting-edge now must be dropped because it’s un-accurate or out-dated. As long as it responds to a change in how to deliver value to the customer.
I’ve already written that I’m in favour of having clearly defined roles and responsibilities.
Now what I’m even more in favour of, is to assess on a regular basis the efficiency of the organisation. Do the current roles and responsibilities, tools and processes, help achieving our goals? Do we make good use of it? Should they be changed? Or simply improved?
Yes, some changes in processes and toolings, or even staff, may prove to be costly. It’s even possible to calculate that cost, most of time. But where it’s virtually impossible to calculate the cost of not changing, it will often be far higher, as you will fail to achieve.
Delegate responsibilities to the lowest possible echelon
Further on organisations, we’ve now long suffered one flaw. Command and control. Hierarchies. Endless chain of commands.
I’m a happy man you know. Being in a small company, that doesn’t really exist. But I’ve had some experiences, where I, or my colleagues, was awaiting the approval of a “N+3″/”N+4” for a project that need to start 2 days ago. You know, those guys whose agenda is packed 3 months upfront, and who’ll never make it anyways, in between 2 planes?
Responding to change requires to be versatile. And it’s impossible to be versatile when a few people are bottlenecks which you’ll need to pass through anytime you’d need to do something.
There is a serious need for delegation, to the lowest possible echelon.
Afraid to empower a youngster? Did you ever wonder if some of those youngsters where actually better than you are at what you do? Oh, maybe that’s the reason why you don’t want to empower them. And maybe that’s your biggest mistake: 1) that’s not serving your organisation 2) giving away responsibilities will cut you some slack to focus on more strategical topics, or on hiring more people and support them on some other responsibilities you’ll delegate them. What does that make you? You’re not the guy with the whip anymore. You’re the guy with the carrot. Yes, you’re still the manager, but in a much more positive way. You’re a coach, and people will like you for that.
Afraid that the youngster sucks at the job? Well, either you didn’t find the risk task for him, or he might just not be a fit for your organisation. And pushing him a little will let you figure it out. Either way: 1) he might be much more motivated and efficient once you find the right spot for him 2) he won’t be left to rot somewhere.
This article on the last agile value being written, I’m more than ever convinced that agile is far from being dead. A friend of mine, not involved in sofwtare development or engineering, read the series and told me: “Well, I see only common sense here. No big deal, why is it so hard to understand in your industry!?” I can’t agree more. Yes, it’s extremely hard to switch from our old command and control paradigm and waterfall methods. But getting out of our comfort zones makes us be the tip of the spear. And most organisations that say agile sucks/is dead/is not an answer to their specific situation probably totally missed out on what it’s made of.
Wake up Neo.
Featured image by Sergiu Bacioiu
2 thoughts on “Responding to change”