As suggested in the July roundup, this is the first of a few posts expanding on tweets that have sprung to mind while writing (or thinking about writing) my third book, working title Right to Left: The digital leader’s guide to Lean and Agile.
Years ago, in my past life as a manager (which I still re-enter from time to time as an interim), I learned that there was little value in me tracking tasks. What mattered to me was the deliverable. Interestingly, I noticed that when I visibly stopped taking an interest in tasks, most of my team members followed suit. I said “It’s completely fine by me to tasks on the board if that’s what works for you, but I’m not going to ask about them”, and soon the task stickies disappeared.
As a team, we made rare exceptions for features that failed our “2 day rule”, which is to say features that at a very rough guess would require more than a couple of days worth of development. Experience taught us that these were disproportionately risky, so it seemed justified to insist on some kind of plan. Of course what actually happened was that most of these big features got sliced into smaller features, and then everyone’s happy to go back to feature-level tracking.
Stop tracking tasks, and no longer does the tracking system drive the developer to work in a way that doesn’t seem natural. A bit over here, a bit over there, then back to the first bit… if the tests say it’s fine, it’s fine! Two people with different skills working together on the same feature? Go for it! And at a stroke it eliminates the anti-pattern of “tasks for quality” – ie separate tasks for unit tests, refactoring, and the like (in the global department I ran more than a decade ago, these tasks disappeared when I asked why these things weren’t happening as the code was being written; I guess my predecessor didn’t see things in quite the same way).
And then there’s the whole question of when a task can be said to be “done”. How do you that some low-level piece of work is really done if the feature as a whole isn’t yet working? Somehow I think that this may have come up before….

Public workshops (US, UK, IT, DE)
- 24th August, Seattle, WA, USA: Core Agendashift: Facilitating Outcome-Oriented Change (Julia Wester)
- 9th-11th October, Brighton, UK: Agendashift + X-Matrix Masterclass (Mike Burrows, Karl Scotland)
- 9th November, Brescia, Italy: Pre-conference workshop: Facilitating Outcome-Oriented Change (Mike Burrows) Note: the booking page is now up
- 3rd December, Munich, Germany: Core Agendashift: Facilitating Outcome-Oriented Change (Julia Wester)
What if we put agreement on outcomes ahead of solutions?
Agendashift™: Serving the transforming organisation
Agendashift Academy: Leading with Outcomes | Home | Store
Links: Home | Subscribe | Become an Agendashift partner | Events | Contact | Mike
Resources: Tools & Materials | Media | Books | Assessments
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter
Hi, Mike! You also can’t estimate when you’ll be done with a big feature by estimating/pointing tasks (or tasks masquerading as Stories). Tasks are process inputs; estimating when you’ll be done requires measuring outputs (tested, integrated, not broken, multi-layer, working stuff).
LikeLike