For the purposes of the discussion I define a "project" as a management structure with a start date, and end date, a budget and a goal. (It says "goal", but subsequent scribbling makes it look as if it says "goat", prompting one of my colleagues to quip: pick which one you want to sacrifice!)
My contention is that when people talk about managing Agile work they generally mean Scrum or these days Kanban (or something very much like them) and that these techniques talk mainly about the steady state of product development and how to control that. They have relatively little to say about what happens at the beginning of a "project". How to get one signed off, for example. Kanban seems particularly weak on this. Nor what happens at the end of a "project" when a set of features go into production. Scrum seems particularly weak on that. As a side note, when I first started working with banks it took me a long time to properly grasp that when they talk about the "delivery" phase of a project they don't mean the relatively trivial bit at the front where the programmers write code.
So, the conclusions of the group were that projects exist as a management structure to mitigate a certain kind of risk in a certain way. As such, I would not agree with this tweet (in reply to one I sent about the very session:
The concept [of a project] is superfluous as it does not add business value.
the concept seems to persist as (some people) believe that having projects allows them to protect money. They might be mistaken: thinking about risk in software development is often wrong, but the idea of a project cannot be dismissed out of hand.
The group observed that different stakeholders have different concerns at different size and time scales, and these are nested. Scrum and Kanban talk mostly about the innermost few layers of the onion.
There was a concrete recommendation: when communicating from the inner part of the onion (smaller scale, shorter time frame) to the outer, do not talk about "iterations" or "cadence" or much of anything time based. Talk about money: pay something in this range, get something in that range.
7 comments:
A useful revisitation of the whole concept of projects.
Of course, given that FlowChain expressly deprecates the project concept in favour of managing flow for the "steady state", I would like it. :)
How long will it take, do you think, before folks begin to appreciate that there are other ways than projects to manage work?
- Bob @FlowchainSensei
They've appreciated it forever.
A farmer might institute a project to, for example, raise a new barn but running a farm is all about managing flows.
Some IT folks appreciate it now. They may need their corporate paymasters to appreciate it before they can realize the benefits.
And we shouldn't forget that there are IT activities which can legitimately be managed as projects.
Keith, I was brought up on a farm and I must disagree. There are time sensitive and precise scheduling involved in farming in which the only criteria are seasons and weather. The flows may exist for feeding animals on a daily basis but everything else cannot be managed in a flow. Think about it...
Well said, Keith. I've been giving this some thought in the context of the PMI-ACP certification - every time I read any literature about it, it leaves me scratching my head. The basis of the PMI certifications is "embrace Agile principles and practices as a
technique for successfully managing projects." I'm honestly really struggling to see the connection.
@Paul I grew up on a farm, too. I think you say it yourself: the criteria are seasons and weather.
Imagine a farmer standing at the side of a hay meadow shouting at the newly-mown grass because the Gantt chart says that it should be dry by now but it's still too moist to bale.
Managing flows doesn't mean being insensitive to time. I recall all too many cold mornings forking trailer-loads of mangelwurzels to feed the lambing ewes. As you say, that wasn't a project. And it wasn't managed as one: we'd order more roots when the current pile got small. The roots take a few days to arrive, order when there are a few days' supply left.
My dad actually did spend a lot of time shouting at ewes for not dropping lambs when and where he wanted. Didn't help. Erecting the pens for the ewes to deliver in, that was a project and the end-date was a few days before the earliest delivery of lambs was expected.
But I would still say that overall the farm was a nexus of flows, which grew and shrank through he year, and had recognisable milestones,and had some projects embedded in it. But mainly it was about the flows.
Keith,
I agree with flows being a big part of how work is structured on a farm. But My Dad used last year's calendar to help him plan the time he had left before moving to the next phase of the season (not weather dependant). Flows were part of it but a project for him was his whole year which started all over again from winter to fall. Flows don't consider planning or resource needs for the whole project... err season. Sort of like a fixed end date with requirements that you can't change.
Great reading your bloog post
Post a Comment