Managing managers

I've worked on many projects in my career, and just like my style of development has changed, so have my managers. This is not a tutorial on how to manage your manager, as I don't believe you should. No, this is more of an open letter to those managers that seem to enjoy making your life hard when it could be so simple.

I've been advocating Agile methodologies for years, I've seen big design first fail miserably and tdd and xp succeed fantastically. I've also seen the reverse, with very well organized big design first projects, often on complicated enterprise-scale systems, with many developers split into smaller teams that then adopt whichever methodology they are comfortable with.

But the worst cause of failure has always been this strange beast that is the methodology-agnostic manager. By manager I mean anything from Project Manager to Dev lead to self-appointed boss, and by methodology-agnostic I mean someone not following a proven way to ensure you can actually deliver software. This can range from Scrum (that I'm covering here) to various waterfalls to ones grown in house and prooved by time. I'll call him Ralph for the purpose of this rant. And Ralph usually say any of the following.

We'll just drop the unit tests.

This usually comes with We'll document [remember, the unit tests are your main source of documentation!] and the very satisfactory I planned a handover phase on the day you finish your contract. It usually come with a justification: We can fix the bugs after the release date, so we'll be on target.

You just cornered yourself into certain failure, Ralph. This may do for v1, you may survive it for v2 with a lot of time and a lot more money, but by v3 you've failed. Let me repeat that: You will not survive beyond v2 if you do not bet on quality over quantity.

Just do it

That one is a bit borderline. There is always pressure to deliver software, and cutting corners is a fact of life for any software project. After all, shipping is choosing. However (you've seen that one coming didn't you?) this means cutting functionality to ensure quality.

Ralph has a tendency to be terrified at the idea of managing the customer. A new project starts, and sometimes the marketing guy over-promised. Sometimes, the customer has described what they want, and we've provided a rough estimate at the beginning of the project. Sometimes, the business asked, got told yes and now Ralph does not want to go back saying it's not possible to deliver.

The reality is that if you can't deliver, you won't. Trying to hide that fact is ridiculous, you'll end up cutting features or being late anyway. It's better to catch these things early, involve the customer in deciding where to re-prioritise. Otherwise Ralph will make the choices for the business, and probably ask his development team to work over-hours. At that point you've failed.

The other reality is that predicting how long software will take is a dark art that is bound to be inaccurate. I'd probably say that as the complexity of a project increases, the probability of reaching an initial estimate drops to 1 in 5 for any reasonably complex scenarios. You can be a bit off or a lot off, but you won't get what you initially planned.

Ralph loves his excel and this does not fit with his model, and that's understandable. I know the complexity of the tasks I'm doing right now, got a few ideas about the ones in the future, but I have no way to predict how it will all work in 6 months. And I've never seen a single project that, 6 months on (or even 3 months on), still has the same requirements, the same deliverables planned and the same functionality in. Business requirements change and they often get shaped as the software evolves.

What do you do then? The same as you did, you give a rough estimate on how long to deliver the core functionality you describe in use-cases or user stories. Then you shape your project on each sprint to split between the minimum needed to deliver that functionality and the refactoring / framework-ization you deem necessary.

When hard choices are to be made, you'll often find they are about which bugs to fix or which refactoring or new code you want, rather than actual user stories being fulfilled. And that's manageable.

There's a school of thoughts in XP that advocates delivering the minimum amount of functionality and refactoring until you get a good enough solution. However, this is only applicable to applications with good code coverage (> 80%). Parts of your application built without TDD or without tests are probably impossible to put under tests easily, and refactorings become increasingly dangerous and expensive. In those instances you're probably better off rewriting from the ground-up. Remember, your prototype is *not* your v1.

This won't get used for long

Ah this one is by far my favourite of all. The first rule is that the prototype is your v1. It *will* end up being used, and will take ages to be decommissioned, if it ever is. Your v1 will try and make this usable, but you'll be stuck with the original design. The customer will not understand why your v1 cost so much more for a few improvements over the prototype. Ralph will not have the courage to say that the prototype didn't cut the mustard.

The only way to sooth the process is to hammer to Ralph: The prototype is not your v1. I know it's in prod and it works but it is *not* a v1. You can ensure it doesn't get used further by putting time bombs, erasing all the data every day and changing where your app is deployed on every release.

Just quick fix damn it!

This is also a common pitfall. It is perfectly reasonable in some instances to walk around an issue you cannot resolve. You document it and discuss it after investigating the problem and finding the root cause.

This is where Ralph comes in. Usually you describe in your daily that an issue has arisen and you need to investigate. Ralph sees a risk, and immediately will start pressuring for any investigative work to be stopped and a fix to be found. Under some circumstances it's reasonable, under most implementing a work-around for an unknown root cause will just remove the symptom without knowing the illness. You just left for later a big giant loophole in your code-base. It is sometimes the right thing to do but rarely.

Scrum doesn't work

This one is fascinating. Scrum is a fabulous methodology, but just like it is very difficult not to stop doing test-driven development under pressure, it seems terribly difficult for the newly appointed scrum master not to fall back into bad habits: micro-management and authority.

All these things happen because Ralph feels he is the one giving orders and splitting the tasks, and as such needs to keep control. This does not work. Let me repeat that. This does not work. A scrum master is there to relieve any impediments on writing software. The product owner decides what gets priority. The development team is self-organizing, because the development team is the one building the software. The devs build it, the scrum master doesn't. Ralph doesn't. So Ralph shouldn't decide, and that's a good thing.

It is good to loose control over the minor details. I'll offer you two reasons.

First, only the developers understand the complexity of writing code for the project on the platform they target. If Ralph has a development background, it was probably years ago and chances are, because he's a project manager now he's not writing any code. He can't decide on how things get done because he doesn't understand them. Then Ralph spends an awful amount of time and effort trying to understand the details of each bit of functionality to regain control. This is the worse scenario as any development planning, meeting and decision has to involve him. Ralph is now needy and has become an impediment.

Second, Ralph will work more efficiently with his colleagues if he's not constantly fighting for power. The product owner decides where the priorities are and which direction the dev team will adopt. Remember, the product owner is the voice of the customer. It's whoever decides what gets in the software. Ralph doesn't use the software, he's not the user. He doesn't talk to the users, that's the product owner. As such he has no idea what bits of functionality the customer wants to implement first. And he has nearly no control over developers because he's not the one building the software and is not involved in writing the code. If Ralph continues to try bossing people around about the code, it will end up impeding the dev team's capability to deliver.

Of course sometimes you end up with the absolute worst case scenario where the scrum master and the product owner titles are both given to Ralph. That's a recipe for disaster.

The daily stand up

This is way too common. Ralph has other issues to discuss, ranging from adding coloured cells to his excel spreadsheet to being explained a component's functionality. So you end up with No we'll do this meeting first and then we'll do the stand-up. You can see the face of developers when they realize they're going to sit around a table and watch a discussion that has very low impact on them they didn't intend on participating in: after all they came for a daily stand-up. Or you end up with we don't need to stand-up for stand-up meetings, a corollary where the purpose of the stand-up is not understood so the format is not respected.

So here's my rule of thumbs to know when you're screwing up: If you hear a developer moaning before the meeting because he knows it's going to end up taking ages; if you sit down; if the discussion is between two people and the others watch: you just ruined your stand-up meeting and the rhythm that's supposed to be associated with it. You got everybody bored and lost an hour of their time.

One last thing to any scrum master out there. You're supposed to track down how many tasks get completed, how many new ones get added, and with those numbers do your estimations on the likelihood of completing your sprint. If you don't do that, the nice cards on the board probably don't help anyone. Analyzing those tasks is what will let Ralph do his spreadsheet, if he's not following them he's not doing his job properly.

The planning meeting

Well this one is easy, it takes time, we write down all the new tasks, we update the product backlog, decide what we want to achieve for the next iteration based on the prioritisation of tasks agreed with the product owner.

However, old habits die hard, and it is overwhelmingly difficult for Ralph to accept that the planning is there to plan the current sprint, not to answer the question of how many months the whole thing is going to take. It gives a good idea of where you are and how likely you'll match your target, but it is in no way there to let Ralph write his excel spreadsheet for hours and hours. It's Ralph's job to understand what is going on and report to the business, it is not the developers'. Ralph, you're the one in charge of excel, embrace the process and keep the planning you sell to the business to yourself.

The post-mortem

I like calling it the post-mortem but there are many other names for it, from wrap-up to release party to the more common sprint retrospective. This is the moment where you analyze why you've not matched your targets, what you've done well and how you can improve the process.

This goes bad when the blame game starts being played. The only way to get something efficient out of a post-mortem is for everybody to understand and agree that estimates are exactly that, estimates. This also means that you accept that you're late and can explain what were the reasons, ranging from your lack of skills to dependencies on other components. No one should get penalized for encountering problems.

The half scrum

Another common misconception is that you can adopt a few bits of Scrum and be successful. I've never seen a project with a bit of scrum in there succeed. Neither have I seen a big plan project succeed without a very strong structure to compensate for the unreliable nature of software development. All in all, because Ralph can't decide which bits of a methodology he's going to use, he uses a bit of everything. This is a recipe for disaster and confusion.

The split responsabilites

This one is tricky. One of the most important bits is the work split. Having each developer work on a different component is a normal occurrence. However, you'll often find that on small teams, it is more efficient to work altogether on one thing rather than split each developer on each project. Assigning ownership to part of the projects to one-man team destroys communication between developers, reduces the rate at which they can code, and ends up more often than not with an inability to deliver anything in a sprint: You do half of two tasks instead of finishing one task well.

Ralph often likes to separate his eggs and have each developer in charge of one bit, so he can go and manage each of them individually. It becomes much easier for his excel spreadsheet. This silo development undermines the concept of working as a team, and often comes from Ralph trying to regain control on a project he has no visibility on. As we've seen before, visibility is there, but Ralph refuses to change his ways and embrace the reason behind agile. This is once again a recipe for disaster.

Conclusion

Here's a recap of all the bad habits Ralph has:

• He gives up code quality to try and achieve deliveries
• He's taking away from the business the choice of what gets delivered and the prioritisation of those elements
• He lives in fear of telling the business how things are really going
• He believes it will be easier to deliver now and refactor later (the prototype is your v1)
• He does not care about finding the cause of an issue and focuses only on the work-around
• He can and need to understand and decide how the software is written and who writes what
• He has to give orders (it's often the case that Ralph is the project manager but not your line manager...)
• He doesn't respect the daily meeting
• He wants to fill his 12 month plan and doesn't track the sprint backlog (the tasks on the whiteboard)
• He wants the help of developers to do his 12-month plan, because the tasks are not enough (after all he doesn't track them)
• He believes the plan is the solution to everything
• He believes he's good enough to reinvent a methodology by mixing bits and pieces
• He believes in splitting people to split tasks and regain control (silo development)

This Ralph is a disastrous scenario and very rarely will you encounter people showing all those signs. But if you try to deliver software in this day and age, and you can see in your project management more than a few of those points, I would advise extreme caution, as I believe you'll end up failing on your deliveries and ending up with a unmotivated team.

On a bright note, Ian Cooper told me once something that I kept at heart: everybody tries to do the right thing. Not knowing and fearing are normal things, failing is part of learning, and people willing to evolve overcome those limitations. Great managers are the ones that take the knowledge from their coworkers, embrace that change and adapt to and work with and for the people they manage.