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 Vikas Hazrati on Mar 13, 2008
Our Customers shouldn't care about Agile development. Our Customers have a business responsibility that includes but is not limited to development of software. They should be interested in ...Ron mentions that as software developers the teams should be interested in getting the software right and making sure that the customer is pleased. He proposes that if the team has already spent enough time educating the customer about Agile and still the customer is not interested then the team should just stop advocating Agile. He also suggests that this in no way means that the team should start panicking, they should identify what is working well and what is not. Later address the areas of improvement in small batches.
-- getting software that the users need;
-- software which will work reliably;
-- software which comes into being as quickly as possible;
-- getting software should take little effort on their part;
-- they could work in ways that they find easy and natural.
I would invite them to a retrospective (and not call it "retrospective" if that might scare them off), proposing the theme "how we can better work together". My goal would be to find the top 3 things they expect from us and to tell them the top 3 things we expect from them. I'd propose we do those things for about six months and see how it helps the relationship.Given the history and all the software projects that are being executed it is not difficult to imagine the inability of the customer to be fully involved with the team, however as the discussion suggested situations could be worked out without giving them an explicit flavor of Agile. The group seemed to agree that the customer knows best and the development team should not try to force Agile on the customer. The customer should be able to work in his preferred way and the development team should try to align itself in a manner which makes the customer succeed.
Case Study: IBM's Agile Transformation
Agility at scale, become as agile as you can be
A practical guide to choosing the right agile tools
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
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!
I agree with you on that the development team should not force agile processes on to the customers, I have observed so many times in my current company that the product owners and requirements gathering team are not interested in adopting agile processes because they have already doing great job in their work areas ( according to them ), so in these cases, i think its good for everyone not to force anyone to adopt agile practices.
Thanks
Puneet
"They should be interested in ...
-- getting software that the users need;
-- software which will work reliably;
-- software which comes into being as quickly as possible;
-- getting software should take little effort on their part;
-- they could work in ways that they find easy and natural."
Agile supports all of these. The customers shouldn't care if it is Agile or not as long as they contribute and are part of it. The team should do their best to engage them as little as possible i.e. they need to do their bit to help the customers make better informed decisions
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.
2 comments
Watch Thread Reply