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?

Comments

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…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…