Out of 75ish people only 3 raised their hands. That’s not a lot of people. All three handraisers were fellow speakers and agile practioners.
I was one of them. Interestingly, I had hesitated to raise my hand. Have I been on teams who finished early? Sure thing!
Yet, right before asking, Allan had dissected common definitions of “projects” and “project success”. One of the success criteria is “on scope”.
Now when you look at “my” early delivered projects, they were not on scope. We were able to call it a day early, because we had cut scope. While building it we identified parts that didn’t add value and decided not to build these.
For a moment there, I was debating with myself whether that’s “cheating”. It could easily be judged that way from a traditional point of view. I mean, isn’t it easy to deliver early if you skip bits? Anyone can do that, can’t they?
I did raise my hand in the end because it’s not cheating to me. Quite the opposite, “responding to change” is at the core of agile. Finding out more while you do the project and adapting to it: If you find out you don’t need even half of the stuff you thought was important you get to finish early. Yay!
And it ain’t easy either. Simple, but not easy, for two reasons: 1) Finding out what can be left out is tricky. 2) Letting go of planned scope is psychologically difficult.
At TopConf Linz 2017, Allan Kelly posed a question to the audience: “Have you ever delivered a project early?”
Out of 75ish people only 3 raised their hands. That’s not a lot of people. All three handraisers were fellow speakers and agile practioners.
I was one of them. Interestingly, I had hesitated to raise my hand. Have I been on teams who finished early? Sure thing!
Yet, right before asking, Allan had dissected common definitions of “projects” and “project success”. One of the success criteria is “on scope”.
Now when you look at “my” early delivered projects, they were not on scope. We were able to call it a day early, because we had cut scope. While building it we identified parts that didn’t add value and decided not to build these.
For a moment there, I was debating with myself whether that’s “cheating”. It could easily be judged that way from a traditional point of view. I mean, isn’t it easy to deliver early if you skip bits? Anyone can do that, can’t they?
I did raise my hand in the end because it’s not cheating to me. Quite the opposite, “responding to change” is at the core of agile. Finding out more while you do the project and adapting to it: If you find out you don’t need even half of the stuff you thought was important you get to finish early. Yay!
And it ain’t easy either. Simple, but not easy, for two reasons: 1) Finding out what can be left out is tricky. 2) Letting go of planned scope is psychologically difficult.
Once more I come to the conclusion that the trick is not to work superfast but to selectively do less.