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 Shane Hastie on Oct 31, 2009
The Agile Australia 2009 conference ran in Sydney on 15 & 16 October 2009. Over 300 people came together to hear two days of sessions by local and international speakers.
The first keynote was by Jean Tabaka, Agile Fellow from Rally Software. She gave a talk titled 12 Agile Adoption Failure Modes, in which she identified a dozen common roadblocks that can prevent effective transformation to Agile techniques in organizations.
She stated that “most organizations have what appear to be suicidal tendencies”, then went on to list and explain the failure modes she has seen in the course of her work with companies across Europe and North America.
The failure modes are:
1) Chequebook Commitments
This is where management’s attitude is “we’ve made the decision, you do it” – disengaged, expecting immediate results without allowing time and without supporting the attitudinal/cultural changes that are necessary, not changing the metrics that teams and individuals are measured against.
2) Culture Doesn’t Support Change
Where the organizational culture is “anti-Agile” – with a deterministic, follow-the-plan approach; where standards of work are imposed from without and are not allowed to evolve as the teams learn new ways of working. Where the attitude is “apply the practices now, exactly like this”; where the PMO sees themselves as enforcers not as empowering the formation of a learning organization. “Be Agile but still follow the plan”.
3) Ineffective use of Retrospectives
There are three failure modes associated with retrospectives –
a) not holding them (the worst possible failure mode)
b) the Scrummaster or other leader filtering and/or disregarding what is being said in the retrospective
c) not having an action plan to apply changes from the retrospective
4) Ignore the Needed Infrastructure
Agile techniques need effective infrastructure support – TDD, continuous integration, automated testing, version control and other tools make Agile easier.
5) Lack of Full Planning Participation
Full team involvement in the planning and estimation is important for Agile project success. Not having the whole team involved creates waste – mainly from the time spent waiting for decisions to be made – and results in low levels of commitment from the team.
6) Product Owner – Unavailable or Too Many
Agile techniques make a lot of demands on product owners, and they need to be able to respond effectively. The product owner who is “too busy to do all this communicating” or who has to get confirmation for every decision impedes the project’s progress.
7) Bad Scrum Masters
There are a number of ways that the Scrum Master can impede Agile projects
Command & Control management lowers team morale, results in low commitment levels and actually lowers the teams IQ! (She cited studies showing the latter effect)
8) No Onsite Evangelist (even worse with distributed teams)
Agile transformations need nurturing, and where some the team is remote there is a high risk of the remote workers becoming “remote road kill”.
9) Team Lacking Authority
Agile teams need to be empowered, able to evolve their own ways of working. This requires time, space and support for team formation (forming-storming-norming-performing). High performance teams emerge in environments with positive feedback, Agile retrospectives provide an inspect-and-adapt cycle that encourages effective team evolution.
10) Not Pulling Testing Forward
Using a “mini-waterfall” sequential process inside iterations does not an Agile transformation make. The myth of 100% utilisation results in inappropriate pressure to build product as quickly as possible, which ends with accumulated technical debt. Shifting the focus to quality and optimising flow through the process instead of focusing on individual utilisation actually results in significantly higher productivity and output.
11) Holding on to Traditional Performance Appraisals
Individual performance appraisals are counter-productive for Agile teams. Rewarding heroic individual efforts over team contribution detracts from Agile success. Find ways to measure and reward team collaboration and contribution.
12) Reverting to Form
“Embracing the evil we know” – change is hard, and the temptation will be strong to revert to prior habits.
She discussed the progression from “this sucks” through “good enough” to get to the “kick ass” threshold in terms of Agile adoption and the resultant productivity improvements.
She ended her talk with a call to action – challenging the audience to select one item to address in the next 30 days, create an action plan to achieve the change, and commit to a personal retrospective in 30 days time examining the progress that has been made.
Her talk can be found at http://vimeo.com/7160163 and the presentation slides at
http://www.slatteryit.com.au/agile2009/Presentations/DAY1/Jean-Tabaka.pdf
Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand
18 agile and lean practices for effective software development governance
SCM best practices for multiple processes, releases & distributed teams
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!
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.
No comments
Watch Thread Reply