What's the really exiting thing about the Agile development movement? Is it getting to ship working software? That's pretty good. Is it not having to lie about status all the time? That's great too! Is it being able (and allowed, and required) to take true responsibility for our work? Wonderful stuff! But I don't think these are the best part.
I think that the best part is that we were starting to normalise the idea that programmers are valuable knowledge workers who collaborate with other valuable workers in the business as peers. Big chunks of the industry had to (re)learn how to do all that shipping and telling the truth and stuff in order to get to that point, but that's only the means. The end is to be dealt with by our paymasters as if we make a genuine contribution to our businesses. And even that is only a starting point for the really interesting stuff.
And now along come folks shouting about Lean. A lot of them are Agile folks looking (quite properly) for what to do next that's better. And the message seems to be: programmers are operators of a technical workflow, and nothing else. They pull to-do items from a queue (which someone else manages) and work them through various states of a purely technical nature until they can be handed off into production (where someone else creates value using them). Again and again and again forever. And it is claimed that if they are organised this way then they will be more efficient and shipping those to-do items than if organzied in other ways. This is almost certainly true.
In which case it is going to be hard to avoid being shoe-horned into that mode once the development managers wake up to it. Back down into the engine room. Back to being, rather more literally than before, a cog in a machine.
The Agile approach to developing software (or, something a lot like it) is gaining more and more interest because, along with the stuff about getting to look up at the stars it is actually a more productive way to develop than a lot of the incumbent approaches. If Lean is more productive again but doesn't even have that social stuff as a hidden agenda, I'm not sure that we as inhabitants of this corner of the industry will turn out to have done ourselves much of a favour.
11 comments:
The opposite spin would be Lean/Kanban is useful only in organisations where the developers are incapable of contributing to the business.
After having read the Poppendieck's book on the Agile Toolkit Lean, I could not disagree to your post more. I see the problem in the people who try to use Lean principles, but didn't understand how to translate them from assembly-line workers to highly-educated software developers (and testers on a side note). Just as there is a problem with developers, that do not produce software in a effective manner using refactoring, tdd, measuring code coverage for development progress. Those hasting developers are harming the picture our customer get from us as a profession. In the same manner misinterpreting Lean to an approach similar to manufacturing standards from the 1920s is harming us - in a different way, but it's still harming.
Our responsibility is to adress this problem, openly talk about and get everyone to the understanding of the problem and work out compromisses to deal with it.
" Lean is more productive again but doesn't even have that social stuff as a hidden agenda..."
Im not sure where you got your info and understanding of Lean, but it differs somewhat from mine. From Poppendiecks Lean Software Development article in C++ Magazine (7 pages) back in 2003, two of the principles are:
* Empower the Team
* Amplify learning
And a bulletpoint:
*Organize for direct, worker-to-worker collaboration.
Focus on human interaction and the individual is key to Lean thinking
What you describe is Taylorism. Lean is quite a bit different. I agree that poorly implemented Lean might be Taylorist, though.
Here's what I do. I squirm around and find where the muck is sweeter. I inform my fellow worms of what I did and what I found. The smart ones try similar things and tell what they did and what they found.
Soon we are somewhere better than where we were.
Insightful.
First thing to say is that "Lean" is a made up word. Just like "Agile". To get beyond the inferences associated with these arbitary labels lets look at concrete prototypical examples of each. The TPS as performed at Toyota extended taylorist ideas by augmenting them with the notion that human psychology is as equally important as applying scientific method. Edward Deming started off life as a statistician, and the TPS started off with time and motion studies and statistical process control.
I wasn't part of the C2 project, but if you take the discourse on the c2 wiki (http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap) as indicative of the culture, then the ethos was much more focused on exploration, shared learning and creativity.
I'm not saying that there isn't good stuff in both, but they do have a subtly different focus. This is hardly surprising since motor car manufacture is not software development. Software development is a much more creative process.
We'd all do well to remember that.
I agree with you that we need to make sure tools, such as Kanban boards, are used with the right philosphy. Your concerns echo a lot of the criticisms of Lean in manufacturing where people have forgotten the importance of respect for people. As this author argues:
'Unfortunately, not only have most senior managers been unaware of, or, ignored the “Respect for
People” principles for decades, but almost the entire Lean community outside of Toyota Motor
Corporation has done so as well.' http://www.theclbm.com/respect_for_people.pdf
I'm a PM on a team that's moved from Scrum to a more custom approach using a Kanban board which we've been continuosly improving for the last 12 months. I share your concerns that Kanban could force developers "back into the engine room". Kanban, as I see it, is just a (pretty simple) tool - it can be used for good or bad effect (e.g. a Command and Control manager will use it very differently than someone interested in team collaboration).
I spoke with some developers on my team about their experience of working with a Kanban board and they said it has made it easier for them to visualise the flow of work and to work "higher up the value stream". We use the approach that columns on the board are based on work which needs to be done and not on the person that needs to do it. At the moment our specialist Business Analyst is visibly "at capacity" in the "Analysis" column, so it's clear to the team that in order to be able to start more work someone needs to go "up stream" and perform the analysis work. This has meant developers who are interested can pick up the analysis and "collaborate with other valuable workers in the business as peers" to find out what needs to be done.
I really like the visibility that our Kanban board gives to the flow of work so that we can see issues like this and work as a team to overcome them.
I try and stay away from fights about the "brands"/philosophy of Scrum or Lean. I'm mostly interested in continuing to learn, reflect and improve the delivery of software in the particular context/system I work within. I do like the concept that "respect for people" is at the heart of what Toyota does and I spend most of my time reflecting on Demming's idea that "most work robs workers of the right of pride in workmanship" and how I can avoid having that outcome for people I work with.
Sorry Keith, but your description doesn't match my experience. I have found that by extending the value stream using kanban, we actually encourage a focus on the whole business rather than an us and them. At Yahoo!, the business became far *more* engaged with engineering when we moved to kanban.
@Karl, you have nothing to be sorry about. I'm not surprised that your experience is different from what I'm concerned will happen in places that adopt what they think is what you're doing wihout the benefit of (1) your input and (2) actually understanding what you're doing.
See Benjamin Mitchell's comment about for some evidence that I'm not completely off-base.
Hi Keith. A more serious response: I find nothing in the documented agile processes either that demands that the business and development stakeholders collaborate to decide business requirements. Scrum teams have a backlog drawn up by the customer with the help of the Scrum Master and then are expected to motor through the implementation of those features releasing every month or so. XP has release planning and iteration planning "games" in which the customer decides the relative priority and acceptance criteria of each feature and the development team can influence that plan by highlighting technical risks. The onsite customer role in XP is there to give rapid feedback on what is being implemented and quickly answer questions, not accept input on the business side of things. Crystal Clear is like XP in this regard, except it stipulates even less.
In what I have read, Kanban is used at an even smaller scale than these processes. It is a way for a development team to make their own work practices visible but says nothing about what those practices are or how those practices interface to the business that is paying for the development.
An XP or Scrum team can work through a backlog with great technical success and deliver something that does nothing useful if the business decision maker makes wrong decisions and the development team focus solely on technical outcomes. Or, they can act as a more active participant in the project and influence it in a more productive direction. I see nothing in Kanban/Lean that will be different: neither better nor worse. At the end of the day, project success is up to the openness of the organisational culture and the experience and motivation of the people involved. Agile project management techniques give people the tools to stay on track, but they've got to choose the tracks. Karl Scotland describes a Kanban flow that emphasises collaboration here: http://availagility.wordpress.com/2009/02/25/an-agile-workflow/
I agree with the essence of your concern though: IT projects should be run as a collaboration between end-users and developers. I've worked on projects where developers knew the business better than the business people, and a collaborative attitude was a great success. I guess that the published Agile processes do not address this because they were written by IT consultants who are brought in to improve development processes but do not have business-specific expertise, not by business consultants brought in to improve the way a specific business is run.
@ Nat, very cogent. You're right, as described the Agile processes don't emphasise collaboration, either. Which is a shame. If I had known then what I know now I'd have been making a fuss about that, oh say, in 2000.
Feels a bit as if I'm going through some sort of professional coming of age: the wheel is coming around for another turn and I'd really rather not have to go through all that re-learning the basics stuff again.
Post a Comment