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
- So what IS Scrumban?
- Don Reinertsen's Cost of Delay Intuition Exercise - a facilitator's guide
- The Toyota Kata - Book Review and Thoughts
- Kanban Method - Finding the Minimally Viable Change
- Addressing some myths and misconceptions people have when considering Kanban
- Explaining MVPs, MVFs, MMFs via the Lean/Agile Requirements Dinosaur
- My thoughts on how Kanban and TOC Critical Chain relate
- How to replace the timebox-based motivation when using Kanban/ScrumBan
- Starting with Managers Kanban (also called Product Stream Representative Kanban)
Tag cloudTraining Teams Organization engineering_practices hr QA LSSC11 test_case_management SLA relationships lean iterations LimitedWIP SPC reading_materials Workshop metrics resources greenpepper kanban project_management flow קנבן classes of service RND agile_testing agile Transition scrum LKCE11 Israel agile testing issue_tracking conference MMF Continuous Improvement Commitment Slack velocity LSSC12 Lean Startup bugs Cycle_Time sprint Agilesparks
This work by Yuval Yeret is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.