Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Deborah Hartmann Preuss on Aug 22, 2006
"I'm just a bit skeptical I need a 'coach' to make sure I'm standing up correctly at my daily meeting. Some jobs appear only when business is good and are the first to go when times get bad. If we assume that eventually, times always get bad - then I guess we'll find out if Agile Coach is one of those."Fair enough - time will tell. In the meantime a number of "coaches" have taken up the conversation in comments on that blog entry. One, William, agrees that the role can be misused:
"I'm sure you're right that, in some organizations, coaches are in effect agile secret police. I think that's foolish, and a waste of money. The only clients I take on are ones where the team is interested in trying agile methods to see how they work for them. Like my boot camp coach, I help people improve in things they care about improving. You can create the appearance of change with externally imposed harrassment, but it's not real change, and you don't get the real benefits."William goes on to point out that a coach can actually work for the team, countering Tyma's assumption that coaches are agents of management: "There's also something I can do that employees generally can't: I can tell managers when they are the issue, when their well-intentioned efforts are screwing up the team. I end up doing this quite a bit."
Transforming Software Delivery: An IBM Rational Case Study
Case Study: IBM's Agile Transformation
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
William goes on to point out that a coach can actually work for the team, countering Tyma's assumption that coaches are agents of management: "There's also something I can do that employees generally can't: I can tell managers when they are the issue, when their well-intentioned efforts are screwing up the team. I end up doing this quite a bit."
I couldn't agree more. Another aspect a coach adds to the mix is a sense of objectivity. He or she is probably more objective than people involved in the project on a day-to-day basis, hence able to quickly assess a certain situation and advise on taking certain actions to improve, without being held back by politics for example.
Often this sort of dynamic occurs when well-meaning management is attempting to implement an agile-friendly change in the organization, but is doing it by fiat. Agile and Lean approaches to software development need management support, true. The strength of agility, however, as in lean, is the empowerment of teams to be their most productive, their most fulfilled as agents of software or product development. When management interferes with this, insisting that they do Agile "right" in a top-down configuration, it will typically be an act of disempowerment, which goes immediately against the aforementioned key lean and agile principle.
Ultimately, as with all approaches, it can be handled with sensitivity or with the hammer of Thor. But also, the participants can be open and inquisitive, or closed and cynical. The latter is also an obstacle for adoption, and can turn well-meaning coaches' efforts into quasi-gestapo evangelism in the eyes of a team. Cynicism is a communicable disease.
I've been part of a team that starting moving from a waterfall to agile approach a year ago. About six months ago we brought in some coaches to help us and I think it's made a marked difference.
When you're trying to figure out agile yourself it can be difficult to self-analyize. You also only guessing at how best practices are actually implemented. Having an "expert" to assist can speed the process along and help teams avoid classic pitfalls.
This is true of any consultant. If your team is picking up a new technology, you can bring in an expert to do training and coaching. Of course you can do it yourself, it just takes longer and you face the risks alone. Bringing in a process consultant is no different. And all the normal consultant practices exist -- the position should be temporary, clearly defined, and eventually unneeded.
I work where we have a huge diversity of skillsets. When we implemented Hibernate noone fought us or much cared. We just did it on our projects because it was what we felt was the right thing to do and noone disagreed.
UNTIL, someone decided HEY LETS have a BIG MEETING and get all the Non-Java people together with the Java people and HASH THIS OUT (when there was no visible or necessary conflict even on the support side)
Needless to say there is no point in doing hibernate anymore because teams of people with 10 year outdated skills dont know what it is and will shout it down because mgmt *under the guise of mediation* created a battle royale that DID NOT exist in reality to satisfy its own curiosity about the differing opinions it didnt understand.
I can see an agile mediator doing the same thing, its like a marriage counselor sitting around waiting for a fight that wouldnt have happened (or would have been resolved much better) if not for the assumption that it would happen and the UN of process needs to be there to stop the shooting.
Pretty crappy.
Often this sort of dynamic occurs when well-meaning management is attempting to implement an agile-friendly change in the organization, but is doing it by fiat.
Actually, it can just as easily be mgmt trying to implement agile with everyones input then never empowering anyone on any team to actually MAKE A DECISION which is worse that BY FIAT because it falls flat
By the way it should be double equals == :)
Interesting hypothesis. So, has anyone seen this happen?
I'm always skeptical when a so called expert starts out with an extreme position like coaching is about making people stand up straight at daily meetings.
Or maybe I'm just sensitive. :)
Ok, so many projects may not need a coach. If you're doing XP "perfectly" you probably don't need one. Does anyone know of such a project?
Even agile teams don't automagically transform into empowered, self-directing teams overnight. In some organizations, developers have been trained to be subservient and docile. It can take a while for teams to reach a point where they can stand on their own.
I do agree that the goal for any coach should be to work themselves out of a job. :)
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
8 comments
Watch Thread Reply