I got a very interesting reply on my latest blog post concerning the harvesting of the passion of the developers. Kevin E. Schlabach rightly pointed out that you could misinterpret my suggestion to leave some time for developer’s own initiatives and ideas.
So, just to make it clear; product owners can, if they think that the developers have great ideas, keep this in mind and when scheduling deliveries, leave some slack so if a developer comes up with a great idea, you as a product owner can choose to prioritize this. As Kevin points to, this is not up to the developer to decide. He can come with suggestions just like stakeholders, but just like everyone else, he cannot decide on priorities.
I’ve also been in situations where developers have thought up an idea and just started working on that instead of the stuff that needed to be done. To be frank, I’ve had some serious problems with this and finally had to take very drastic steps to end this, so I know that this is an important and serious problem. Serious, since other stuff isn’t being done, and dangerous since cheating in a team in contagious. It spreads to the other developers.
When you instead harvest the developer’s ideas you place them on the backlog like everything else. But I do like to make the guys happy sometimes and push up something on the priority list if it’s a really good idea and something which is truly valuable to the customer. But as a product owner, I am responsible, and it’s my decision to take.
Thanks, Kevin, for pointing to the risks for misunderstanding of my point of view. Keep the comments coming! I’m agile in point of view.
Most of the software developers I’ve worked with want to solve the problems of the users. Many are real professionals with the attitude of a craftsman. Many are innovative about different solutions. And most of them love to write code.
If you take a developer who wants to solve problems, is a craftsman, innovative and loves to write code you are sure to hear loads of good ideas of what he could do, if he only was given the opportunity.
Many times, his suggestions are not highest on the priority list from the business people. And then you run into the situations when his stuff is never done. Yes, I know that there are other stakeholders who’s ideas never becomes a reality too, but this guy stands there with his hands deep into the code every day, thinking about those things he could do, given that he get the opportunity.
So, you should leave some room for that in your plan. For example, if you’re using scrum or another iteration based method, let the guys pick one thing if they are successful in a sprint.
If you’re doing kanban, you can be a little bit more spontaneous. The other day, one of the developers came up with a great idea. I could see the passion in his eyes. He really wanted to do it. And I could hear that he’d given the thought a lot of thinking (this proved to be correctly later). Since we’re in a situation where the next stuff on the list cannot be completed due to lacking resources of a specific competence, I was considering what we should do next. So, why not? So, I said to him to go ahead. Given that the stuff in progress is done, this will be next.
I think we’ll get so much more code/function/quality out of this than we would have if the stuff had been done with someone who didn’t think this was his stuff, someone who wasn’t thrilled about the idea. And this joy about his work will probably continue after his work with this is done. Just because now it’s done.
But besides from sometimes prioritizing the stuff the developers have passion for, one can also help developers becoming more passionate about all the other stuff. And that is best done (I think) by including them in discussions, requirements and story writing.
Yesterday, I replied on Lasse’s weblog concerning Ken Schwaber, perhaps not on purpose, differentiate between managers and professionals by stating:
"I expect 20% turnover in professionals and 40% turnover in management as Scrum gets implemented"
I guess that even if Schwaber didn’t mean to say that managers are not professionals it’s somewhat related to the, for me anyway, rather common input from developers when it comes to meetings:
"Are we finished, I really have to get back to work."
What that means is that meetings are not working. And what are managers doing: spend their days in meetings.
So, how do you become a professional manager? I’m not native to the English language so my taste of the word probably differs from a person for which English or American is a native language, but for me manager is someone who manage something or someone. And for me to manage is to handle, perhaps even take care of. And now I don’t mean the mafia style "take care of" but more the thoughtful taking care of. There’s a lot of feeling but also not only emotional feelings. There is a logic to how one takes care of the person or the situation. To be able to take care of a situation and a person I need to know what I’m doing and why. And if my methods don’t work, I have to think of another way of doing it.
So, for me a professional manager is a person who knowingly handles situations and people. I guess it’s mostly a mindset. A good manager like a good leader does not care about the title, he cares about his work and people. So, why do we suck at this in the eyes of the developers? Well, how can you handle what you cannot see? How can you care about people who’s work you never take part in?