I have included some agile is awesome videos. But to be fair, agile is not always awesome. So here are a couple of great videos that show the pain of going agile – from the point of view of an passionate agile PM. The first video shows his attempt to go agile in a large organisation – “I want to run an agile project” I want to run an agile project Then I guess he resigns, because now he has joined a consulting company who want to run all their projects agile. Hopefully life will be better, but sadly … … Continue reading Agile is actually really hard videos
Last century I learned about something called TQM which was all about empowering teams and improving processes. Now I am learning about agile and design thinking concepts.
These are great approaches and we have learned many things over the years, but some things have not changed.
For example, one thing common to all of these approaches is the concept that failure is good.
Failure is learning, so it is better to “fail fast” or “learn and pivot” than to avoid doing anything until you are sure it is safe.
But to be honest, when I fly from city to city I would prefer that the pilot does not fail often. In fact I hope he or she has flown the same plane a lot with other less important people, before taking me up and away from the safe ground I was on.
So, should be happy when we fail?
(warning – this is a very long read for a blog, but I thought I would send it out and fail to interest you rather than stop to think it through properly)
I recently ran a course for product owners and said that the product owner or BA facilitates the elaboration, slicing and general understanding of stories WITH THE TEAM.
Some of the crew asked how to do this and the following is what we came up with in the class.
It is commonly accepted wisdom that agile development is an IT thing, now making its way out into “the business”.
But it appears to me that the bus drivers in a city called Perth went agile without the IT guys showing them the way.
(warning – this is a bit of a long read).
When a small team is working with great rhythm, it often looks like there is no upfront planning or design … and sometimes that is in fact the case.
But more often than not, that small team is integrating into an existing “ecosystem” of products, services, internal processes, team structures and IT systems. And generally speaking the small team is building something complex that needs both some foresight and some willingness to learn and improve the system’s designs customer expectations or company direction change.