Skip to main content

Three Simple Hacks to Improve Management

Why doesn't the C-Suite understand Agile? Agile improves performance, profitability and customer delight. Why don't they get it? Why won't they even take the time to look at it? This dilemma has puzzled Agilists for as long as there has been Agile. Software developers have long been confronted with a similar problem. Here is a look a their solution and three simple hacks which may help managers improve their performance and their company's competitiveness.

I think there is a simple explanation for this: Top managers simply don't have time to think deeply -- about Agile, or anything else. They are overwhelmed, overworked and under extreme pressure to perform. They have no time or energy for creative thought. And since they have to deliver results every quarter, they can't risk doing anything new. If they were software developers, they would be doing death march releases every three months.

To understand the problem, let's look at the act of getting a meeting to discuss Agile with a top manager. You're the Agile coach; how does it go?

1. Schedule the meeting

You (with the brilliant new idea): I'd like a meeting with you to discuss an awesome new approach to software development.
Manager: How does that affect me? I'm responsible for finances, not software. Besides, I'm totally booked! No time.
You: I understand, but this is really important. It's about the future of our company.
Manager: Well, in that case, I can squeeze you in for an hour on Friday.
You: Thanks!

2. At the meeting

Your Manager has invited six additional people, mostly his direct reports, to the meeting.  They all come and you all wait for him to arrive - about 10 minutes late. In the meantime, the other six people have all opened their laptops, and now are working on their emails and things. Of course they stop when the top manager arrives, but as soon as the meeting begins, their attention is divided between what is being discussed and what is happening on their computers.

The first thing the top managers says is, "I have to focus on our financial results for this quarter, so cut the chase. What do I absolutely have to know?' Now you are flabbergasted and not quite sure what to say, but your try to deliver your points faster to the assembled notebook-readers. Five minutes before the end of the meeting, the manager has to leave for the next meeting...

Everywhere the same pattern!

Sound familiar? Of course it does. We've all been there. This could be a Dilbert cartoon. But it is daily life. Of those 7 people, five of them should not have come. All these people are seriously overloaded. They are taking on more work than they can accomplish, and trying to multitask as a means of working harder. So they are not doing anything well.

We've hit the limits on our ability to work harder. Management multitasking is evil. It kills performance. It kills the ability to innovate. And this eventually kills even the biggest companies.

I've been in the computer business long enough to remember working on the first timesharing minicomputers and mainframes. Back in those days, multi-tasking seemed like a great invention. The machine had lots more capacity than needed (or so we thought), so it could share that capacity among many users. Great in theory, but the users needed far more, which slowed performance dramatically down to a crawl. The same thing is happening in every large organization that I have come in contact with.

We have to do less.

Today, multitasking is used on lightly loaded notebooks, PCs and tablets to give their single user great performance: Dazzling graphics, snappy interfaces, sound and video are all possible because the devices can now do far more than is required of them. Does this sound like Apple? Apple works this way. What would it be like if your company gave your customers great performance?

Unfortunately, we cannot upgrade our brains with a faster processor. Would be nice, but I don't think I'd do it even if some doctor offered it to me. So we have to do less and make that which we do count more.

So the alternative is to get rid of all the bloatware that is occupying your brains and focus on what really matters!

We need slack.

If you are working towards a new product release, how far before the deadline are you willing to try out something new? My experience is that 3 months is a pretty typical answer. If there are more than three months left, people are willing to try things out. Less than three months, people want to focus on the release. How is management like delivering products?

We need to get better at delivering results to Wall Street.

If a software team is not doing well with a monthly iteration, what should you do? Shorten the iteration. Ron Jeffries popularized this approach and any agile coach will tell you it's true.

Management of public companies have to publish financial results every three months. They are always three months away from a release, so they are always under pressure to perform. Always frozen by the release which is three months in the future. What should management do?

How to get better management?

Here are three simple hacks to improve management:
  1. Meeting-free afternoons. Give yourself some slack. Just block the afternoons, leaving you available for short term issues and deep thinking.
  2. No notebooks at meetings. If the agenda isn't worth 100% of your attention, then you shouldn't go.
  3. Publish financial results monthly instead of quarterly. By doing it more often, a) You get better at it, so it becomes easier to do. b) You increase transparency, which increases trust between you and your investors. c) The consequences of a bad month are smaller than a bad quarter, so you decrease the need to manage the expectations, and your own stress level will be lower and more constant, giving your mind more freedom to consider new things.
OK, this last one seems counter-intuitive and might not qualify as a simple hack. Simple means, it does not require legislative approval, because three monthly reports can easily be consolidated into a quarterly report.

However it is very consistent with the experience of software teams - they are better able to manage the stress of releases when they release more often. They are also better able to improve their quality when they release more often. They have a more trusting relationship with their stakeholders. They have better releases.

As a manager, improvement starts with you. What would it be like if you could get your level of stress under control, so you could really focus on making your company a better place?


dnaworks said…
One minor correction - "because three monthly reports can easily be consolidated into a monthly report" should read "because three monthly reports can easily be consolidated into a QUARTERLY report", without the shouting, of course :)
Peter said…
Thank you, dnaworks for the correction.

Consolidating a monthly report into a monthly report shouldn't be a big deal, but with three reports, it really is not a monthly report anymore ;-)

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…