The other day I was asked to discuss how we can improve the way one of our software development teams works. Well, actually it was rather something like “Pawel, help us to implement Kanban” but, as it soon appeared, it wasn’t that simple.
A typical discussion about implementing Kanban
Me: So where do we start?
Colleague: Um, I’m not really sure if Kanban is really for us. Convince me.
Me: I don’t want to. If something doesn’t suit your team I’ll be the last person to convince you to implement it.
Colleague: So where do we start?
Me: Maybe with problems you and the team have. I guess there are some otherwise we wouldn’t be talking now.
It isn’t about applying recipes
The discussion changed its course. We immediately switched from discussing Kanban to talking about issues and looking for a solution which would be suitable in each and every individual case. If one of problems is people don’t want to have yet another place to do task management, and they can’t abandon either of current systems, introducing Kanban board may not be as great idea as it initially appears.
If you start discussion with the conclusion already fixed in your head you will not only miss opportunities to improve but you also risk applying the wrong cure and making the situation worse.
It is OK if you just don’t know
A couple of times through the discussion I came up to the point where I had no idea what the right solution might be. And this is perfectly OK. It’s not about playing knowledgeable person. It’s about giving the good advice or not giving any advice at all.
What more, admitting that you don’t know the answer is just a starting point for digging deeper. Each of these moments triggered some changes in our analysis. If we can’t go further here, maybe we should try there. Let’s stop talking about techniques which may or may not work and make a fast-paced Q&A session about potential issues the team may face. Or maybe let’s do mental walkthrough of processes the team covers.
As it appeared each time we admitted that we don’t know helped us with coming up with a reasonable conclusions at the very end.
Adjust tools for people, not the other way around
When you know some method or approach and it works fine for you, you are always tempted to apply it in other environments too. The problem is other environment means other people. As a result your approach may not be so great anymore.
But who said you can’t change the approach? Are methods we use some kind of dogma? Actually choosing a subset of techniques or practices from any given methodology is usually better than not using them at all. And if you choose wisely even a couple of small changes may yield significant improvements. So yes, do adjust methods before applying them.
That doesn’t mean people shouldn’t change ever. Of course they should. But motivation to change should be intrinsic and not enforced from outside, i.e. because manager told so.
A funny thing is that with this approach you can end with similar conclusion to the one you started with. The difference is now you are more likely to succeed as, even though you aim at the same target, you will choose different way to get there.
And in case you were curious, yes, we eventually came back to Kanban.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
4 comments… add one
“Adjust tools for people, not the other way around” – It is my life’s ambition to find an HR department that thinks that way ;)
In small companies it often looks like that. Actually I may be biased because I work long years with developers but unless you own a factory I believe people buy-in is a key factor of success when it comes to changing pretty much anything.
Actually I disagree with two points here
“unless you own a factory” buy in is essential. Buy in of the right people is always essential. at least line managers must be involved in understanding the problem the proposed change is meant to be solving and the rationale, as they will be involved in making the proposed change work. Most factories have little side rooms behind locked doors where failed investments gather dust…
.
2. sometimes its much smarter to adjust your people to well designed systems. Take a fast food restaurant. If I was starting one from scratch I am sure that I would be better off buying a local off the shelf market leading software package, containing all the wisdom and needs analysis of hundreds of my competitors. than trying to automate my own processes.
Of course there may be features benefits you don’t want in an OTS pacage but devising your own processes and building IT systems to match only makes sense if you are sure your best efforts are going to be better than industry best practice. finding out what industry best practice is the bigger challenge in my view
Richard
buy
Richard,
You point a gap in my argument, which is dealing with those, whose approach/practices are wrong and who don’t want to change.
Yes, you don’t need buy-in of virtually everybody in the team although it would be better that way. If you have key people with you it should be enough… for the start. The trick is however how you define key people, but that’s the other story. Actually if you have all the influential folks supporting you the rest should follow.
But then, there are some who won’t follow and won’t change. And a question arises whether their value outweighs harm they do to the team. If not it is another decision what you’re going to do with the issue.
Regarding adjusting tools for people I thought more about practices than software applications. If we think about fast food restaurant these tools would be about the way you cook meals. If a new better way of making burgers means only that it would take a minute longer to prepare it people likely will take a shortcut and use the old method.
In terms of software development team a number of these practices is optional. New better ways of building software work only as long as people consider them as valuable, especially that all those new practices in short term mean more work. From this perspective forcing people to change yields rather poor results.
But of course, switching from Eclipse to XCode back and forth shouldn’t be a problem. After all these are only tools to write code. And if someone goes dramatic just because of that it is a question mark put under their name.