How to NOT lead Agile

Sometimes it's easier to explain something, by explaining how it doesn't work. Today I will tell you how to not lead Agile.

Of course this is not to be taken seriously. I guess this already makes you a better Agile leader as it will give you an idea what not to do.

You don't need feedback, you know what the customer wants

I exactly know what our customers wants. We will create a very detailed plan first and then execute that for the next twelve months and of course we do it in sprints. We are doing Agile here.

In the first sprint we set up the backend, in the next the database and after sprint seven, we can maybe see the first html page. After six months I plan to have a backend demo.

Of course the customer will know what we are doing, the received a copy of our Gantt chart. There you can clearly see the single sprints and what exactly we are doing when.

Follow a plan, that's what it is there for

The customer called and wants to have something different. I told him that we can do that after the first release. Of course, he has to pay that extra. That's how we are making money here.

For what we made that detailed plan? That would destroy that beautiful Gantt chart I needed weekends to create in Excel.

As the Principles of the Agile Manifesto say, we welcome change here. And with change I mean Change Requests. The customer will have them in no time, after the final release. The contract clearly states how this works. In 12 months. Just look at the Gantt chart.

Pan for gold, you only need one shot

As an experienced development team we exactly know what the customer wants and how that works. On the Gantt chart you can clearly see that the customer gets a demo (or maybe a PowerPoint presentation in month eleven of twelve).

We have defined everything in detailed contracts, so the customer should have a clear picture of what he wants.

Unlike most other companies we are not releasing unfinished products to the customer. That's called banana software, it ripens with the customers, that's unprofessional. We give them everything at once. We made a plan on which we agreed with the customer, so he knows what he gets as well.

Keep everybody in their place, you give them the information they need

In my company everybody knows their place. Why should someone from accounting talk to the developers? They are just distracting each other.

That's also why I am making the seating plans. The developers know how to develop that tax calculation, I gave them a specification sheet about that. If they don't understand, I will tell them in next month's Jour Fix. They had time to discuss that in the project kickoff.

I personally make sure that business areas and development areas are clearly separated, also in tools like internal wikis. People shouldn't be distracted by seeing what other teams are working on. That's bad for their utilization rate.

Control Every Little Detail — you know what's best

Our developers know what's working best — I told them. They received detailed architecture diagrams and I wrote them a long list on how to do what and which libraries to use.

I have the biggest experience, so why should they waste time and energy trying their own way… Again, that's bad for the utilization rate and bad for the plan as well.

Communicate top down

Communicate in long monologues. One way. Specifications are your friend. You know what's best and your people know this. You don't need their feedback.

And remember, you only allow communication that's coming from you. Everything else would just distract people. Maybe place them in another room and optimize the seating plan if they talk too much instead of typing code on their keyboard.

Lines of Code per Minute and tickets per day are a good measure of success

What's the best metric to see if a developer is productive? Right, when they have typed all day and have spent most of it in front of the keyboard, they are productive.

And by making sure we stick to the plan — which I designed — we make sure to always go the best route.

After the release at the end of the project we will see that my plan worked out. And little things we can fix later, for extra payment.

Work hard — Long hours every day make sure that the pressure motivates people

As a good manager, I know what motivates people: pressure. Pressure forms diamonds. If you keep the pressure high, it makes sure your developers don't lose focus.

They also know who works longer gets good feedback in their yearly performance review. And of course, they are productive, they are sitting in their chair and write code.

I love it when I hear keyboards clicking at night. Long hours always lead to productive work.

We can fix that later — just make sure it works for the demo

Technical excellence is great. But tickets done per day is more important. We need to stay on time.

We need to make the software work until the demo. I can exactly tell the developers what they need to do. Some fixes are just a few lines of code. We can definitely do that later.

We do it according to spec, no matter what

Good software is software that was planned well. Therefore, we have a long specification of things that must be included. With all the experience, we — or better I — have, there is no chance for mistakes. We need all the things, that's why I designed everything this way.

A developer noticed a module is not really needed? Seems like we have a smart-ass there. I will not that for the performance review next year.

If there is a ticket for it, it has to be done. We have a plan to stick to, not for fun.

The best architecture comes from me

The team does what I say. I have the most experience in creating architecture and requirements.

They are paid for writing code. Not to think.

Once a year, I tell people what they are doing wrong

As a good leader, feedback is important to me. That's why I am going for a very frequent feedback method: Once a year, I talk to everybody on the team and tell them what they are doing wrong.

At the same time, they can ask for a hike in their salary, but if they haven't put in enough hours over the past year, I don't see a chance for that.

We will also look at their productivity score, which is measured by written lines of code and closed tickets. If they want more money, they need to write more code. Simple as that.

Conclusion

Have you ever had a manager like that? Claiming to "do agile" and just being a massive micromanager?

The above describes exactly what an Agile leader shouldn't do. If you can notice some of your behavior here, you got homework to do. Or just book a session with me, and we can have a chat about how I can help you.

Daniel Hauck

Daniel Hauck

I lead, I write and I find beauty in less.
in the forests, somewhere near Stuttgart