Sir Francis Bacon: https://en.wikipedia.org/wiki/Novum_Organum
Eric Ries: http://theleanstartup.com/principles
This is just a comic version of this video: https://youtu.be/N7oz366X0-8
The original paper from 2003: http://alumni.media.mit.edu/~brooks/storybiz/kurtz.pdf
Cynthia Kurtz was co-author on the 2003 paper (https://www.cfkurtz.com/). This paper opened my mind to the fact that all four domains are always present in any situation: https://www.cfkurtz.com/Kurtz%202009b%20Wisdom%20of%20Clouds.pdf
These videos of a full day workshop with Dave go deeper:
I use Cumulative Flow Diagrams for spotting problems and as a communication tool for discussions with the team. I’m using Google Sheets to keep track of how many cards are in each column of our Kanban board. Every morning I have a coffee and add a row for the day before.
In Google Sheets, the CFD is a “stacked area chart”. A CFD based on real team data is crazy looking compared to most examples you see, which are usually simplified views of very stable systems. A real CFD shows the peculiar conditions of the team. I value that more than the throughput, cycle time and lead time metrics although these are important metrics that can have real value for the team.
At the LAST conference in Sydney a couple of months ago, the keynote speaker was Henry Mitzberg. When he said “efficiency is the enemy of effectiveness”, I was shocked - mostly at myself for not questioning the idea of “efficiency” before.
Before asking for any kind of size or complexity estimate, I ask “is this card ready?” and “is it as small as it can be…yet?”. If we agree that the card was ready and that it is as small as it can be, I suggest moving on to another card.
A few years ago I heard about the #NoEstimates hashtag that was causing a noise and confusion on Twitter - probably the Agile For Humans podcast. A bit later I started listening to the Scrum Master Toolbox podcast hosted by Vasco Duarte, where the approaches that underpin #NoEstimates come up quite often. Considering that Vasco literally wrote the book on #NoEstimates and is a tireless proponent of the idea, he is remarkably restrained on the podcast.
I’ve been looking for a silver bullet that will make this “resourcing” strategy somehow less terrible for trying to be agile but… there isn’t one. Whichever way you slice it, making people less than 100% on the team creates dysfunction.
It makes scheduling team collaboration opportunities difficult. It also means that people on more than one team spend more of their time with agile meetings than they should (think two or three lots of sprint reviews, planning meetings, retros…) - or they skip meetings because they have to. Perhaps most insidiously, it means that people are probably 100% ‘utilised’, at least. We know what happens to lead time as untilisation approaches 100%, right? It increases exponentially. So, basically, it’s a nightmare.
Sometimes I wonder if an organisation I’m working with is agile. There a moments of inspiring agility… and then something happens that’s really NOT agile. These obstacles of resistance, well meaning misunderstanding or just plain fear of change sometimes pile up on the “not agile” side of the scale and I think about whether there was some point in the past when I should have said “if you’re not willing to try this thing, or accept this thing, then we should stop trying to be agile for a while - call me when you change your mind”.
I’ve never been very confident trying new things for the first time in a retrospective meeting. I recently, and very belatedly, read Agile Retrospectives by Diana Larsen and Esther Derby and realised the importance of really covering the five stages they recommend. It gives the retro a solid structure and makes me more confident about trying new approaches within the structure.
At the moment I’m working with remote teams. We do retrospectives over HangOuts using https://realtimeboard.com/. The results are sometimes frustrating, often hilarious and always worthwhile.
A very experienced agile practitioner I met recently, expressed some annoyance about people calling themselves “Agile Coach”. He spoke of the high status that a Scrum Master used to have, which has shifted to the Agile Coach. He said “Do you know how much training you need to be an Agile Coach? None”.
If your organisation is doing scrum, whether “Agile Coach” is your job title or “Scrum Master” is your job title, you may well have the responsibility of being Scrum Master on a Scrum team for your organisation. You may also support the developers and the Product Owner on the scrum team with coaching and facilitation. You may work with the whole organisation to influence the system conditions that allow agile teams to thrive.
One anti-pattern I have seen is when an organisation has people with the “Agile Coach” job title and people with the “Scrum Master” job title. The Scrum Master works at a team level and the Agile Coach works across teams or with the management team. The Agile Coach has more rank because of who they mix with, whereas the Scrum Master role is all about “delivery”.
When it’s a straight choice about whether the role should be called “Agile Coach” or “Scrum Master” then the question might be about whether the team (and the organisation as a whole) wants to commit to only doing Scrum.
I would rather be called “Agile Coach” because it encourages me to have a flexible mindset, and because it stresses the coaching aspect of the role. Coaching is about supporting others to develop capability and that’s something I want to keep in focus. I have also found that there is plenty of training and learning I can do to help me be a better Agile Coach.
Software products and services need a business goal. We also need to know who the product is for, the problems it solves for them and why it’s better than the alternative. This is the sort of value proposition statement we need to articulate so that we can make good decisions during the long and complex process of making software:
<statement of need>
THE PRODUCT IS A
<key benefit, compelling reason to buy>
<compelling statement of differentiation>