This is a guest post by Yaki Koren who is the lead coach in one of AgileSparks’s clients – Amdocs Delivery who are going through a very interesting transformation leveraging the Kanban Method, crossing the chasm techniques as well as several key agile practices. It is also where I spend a considerable slice of my time the last year trying to help make this happen. And now – here is Yaki…
Last May I gave a talk at Agile Israel about the implementation we did in my company. At the end of the talk a guy from the audience asked what is the down side to agile. I must admit I never thought of it as it looked quite perfect to me. Eventually I answered that managers who like to micro manage will find the move to agile difficult.
Now after more than a year of implementation I think I have a better answer to this question.
We are doing the transformation to agile in many projects. Some succeed more and some less. In small projects (around 10-50 person months of development) it seems to go well most of the time.
The problem starts with the big projects. Here you see great differences. You come to the daily meeting and you think you are in a different company.
In some projects (where it goes well) you see the project manager leading the meeting, setting priorities, making sure all are working together. In other projects the project manager couldn’t make it to the meeting so some other person from the project management team is facilitating the meeting (less of a lead and more of a facilitator). In these projects the various parties of the project take the agile spirit to the direction of the wild west, including show downs when the sun is high in the sky.
The down side of agile is that managers actually need to manage. It is a down side to some and an upside to others.
It is not a simple task moving from playing the commitment game to constantly navigating the ship through the stormy seas of software development. Some managers get a new spark in their eyes when introduced to agile, feeling revitalized with new zest and vigor. Some try to play the old game under the new dress and there things go awry and frustration follows.
When we start an implementation we ask the managers why do they want to go through this. Now we are starting to tell the managers what is the expectation from them. What will be the change in their day to day. We believe this will help us better align expectations with the managers and to make sure we have better results with the implementation.
I'm Yuval Yeret. I'm leading the Kanban practice at AgileSparks. This blog focuses on my experiences using Lean and Agile approaches to help organizations and people become more effective.
Top Posts & Pages
- My favorite Excel-based Agile Backlog Templates
- Kanban Method - Finding the Minimally Viable Change
- Explaining MVPs, MVFs, MMFs via the Lean/Agile Requirements Dinosaur
- How to use Kanban to help improve your recruiting process
- So what IS Scrumban?
- Don Reinertsen's Cost of Delay Intuition Exercise - a facilitator's guide
- Touching your electronic kanban board
- Scrum Sprint Commitment Rant
- Making Agile Teams work in real life - The quest for Stable Feature Teams?
Tag cloudקנבן agile lean kanban iterations engineering_practices velocity sprint Workshop LSSC11 Lean Startup LKCE11 conference QA LimitedWIP flow agile testing reading_materials greenpepper MMF Israel Commitment agile_testing Cycle_Time Agilesparks Training issue_tracking Organization relationships resources LSSC12 bugs SLA SPC test_case_management metrics RND Transition scrum classes of service Teams Continuous Improvement hr Slack project_management
This work by Yuval Yeret is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.