I know that I am slow) Finally continued reading “Management 3.0″ by Jurgen Appelo. Chapter 7.
I am really
very a bit tired because of all this hype.
Let me tell how it usually looks like when you are agile*. I mean “agile”. I know, I am mixing the issues of agile frameworks with the bad implementation issues. Please don’t blame me for that, as this is like real life – all possible mistakes are made and they are uniquely mixed.
*All characters appearing in this work are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
Creating software is easy. It’s like you are building a plane and they forgot to provide you the building materials and you have to install both wings on one side according to the specification but no one knows how to do it and the plane is already flying and they already sold 10x more tickets that you can put in the plane and suddenly the fire starts….
Ok, I worked too long as the project manager, so forgive me for being too optimistic. Let’s imagine you have a new project. That would be a great journey! Because this time EVERYTHING WOULD BE DIFFERENT. You wanted to be different this time, but ended up as usual…in the hell. So what is causing this permanent hell? I tried to point out the most obvious causes.
This time I would like to share my personal collection of manager’s errors which I have been made (at first I wanted to write “errors which I came across” pretending that other managers made them and I only witnessed these stupid errors) for the last 7 years.
This week our PM intern asked me about the best way to write the project status reports. I like when interns ask me questions. I can spend one more working hour speaking about the question topic, work, clients, projects and the hard life of the project managers. If I am lucky I can get up to 7-8 questions per day, so I can be pretty busy with that hard work.
Reading the twitter feed over the weekend I came across several posts about the employee engagement. What is employee engagement? To me it sounds like the old-fashion term used by HR managers. They talk about it a lot, they even can attempt to perform some annual surveys to measure it. The definition of it can also a bit different for the HR manager, top manager and the developer, who is working in your project team.
Managers usually think of the engagement as the willingness of the employees to live their life at work.
During the last several months our team came across 3 projects with the same issue – customers had the “almost done” project (usually customers state smth like “85%” or “95% done”) but they could not launch it, because the bug fixing process was endless or the “last crucial” feature was almost impossible to implement. Almost all of them were startups. We performed code review for them to be able to answer if we can handle it. From inside the products looked very similar. I think I even could tell all their development history by looking at these layers of code, covering each other like patches in a crazy quilt. We usually ended up with these clients arguing about one question – “Rewrite or do not rewrite all of that”. So I decided to write this post about the BIG rewriting.
Are you happy on Monday morning? What about Friday evening? We all know how office workers are waiting for the Friday evenings… Because work is hard. Because there is no more joy. Really? How people who are not feeling good about their work can produce something great?
If you ask any of your colleague when they felt joy at work they probably tell you about some challenge they faced and successfully solved or brainstorming, where their team produced a great idea. Also they can point out the time when they worked with a great passionate team of developers. Even if they were creating “one more social network”.
Show me your burndown chart and I will tell you how the things are going. To be honest I am amazed how simple the things became for the project managers (does not depend whose hat PM is wearing now – scrum master, product owner) now – you need only a few metrics to be able to plan and forecast with the same success rate as it was previously. The burndown (I personally prefer burnup) chart is a very simple thing – easy to explain, easy to maintain. But it is a powerful instrument in the hands of the scrum master and the team.
We are all used to just implement the well-known “best practices”, not even thinking much about the reasons they were created. Especially in Agile. We like all those rituals, as they make us fill as we are going the right direction. Just follow the rituals and you’ll be ok.PMs/Scrum Masters usually hate all these clever questions from the sarcastic developers, as the only thing they can answer is – “It’s obvious, stupid!”.
You can’t even explain, why 🙂 I want to write several posts about the most frequent questions managers can’t answer, so you are prepared and next time your team mentions it – you brains can shine in full managerial glory. Also I will use levels of the answers complexity, so you can always adjust them to your current audience.