(2018-08-20) Mitchell Projects And Products In Scrum
Ian Mitchell on Projects and Products in Scrum. Agile coaching is a journey into irony. One of the chief discoveries you can make on this voyage is that the more experienced you become, the worse at the job others often think you get. (Agile Product Development)
You, however, have begun to question the received wisdom upon which the project model is even based.
the operational running cost of a project is unlikely to be reduced in the short term. You warn that agile development could actually prove more expensive
Also, there is likely to be improved transparency over certain hidden costs, such as technical debt, which might presently be compounding unappreciated.
These are not always observations which others wish to hear. There is a strong market for sweet lies and simple answers
"In fact", you say as you dig your own grave, "the very idea of having a project at all may need to be reconsidered. In an agile way-of-working we are more concerned about the delivery of products and services, the value of which is empirically proven by means of validated learning. We have less interest in the supposed efficiencies of temporary endeavors like projects, with their setup and teardown costs and other untracked forms of waste
Can't he understand the organizational change which would be needed to attempt the realignment he's suggesting?"
Of course you understand the organizational change which would be needed to replace a project model with products and services...and that's exactly where you were trying to steer the conversation. However, it's not a direction others wish to go.
You have to acknowledge the realpolitik of the situation...and that means learning to live with projects.
search for the string "project" in the Scrum Guide may prove instructive and worthwhile before any such conclusion is drawn
we also see a radical departure from convention in the assertion that a Sprint "project" cannot exceed one month in length. Most of the projects with which managers are familiar will be framed to last several months or even years.
When a project lasts longer than a month, traditional means of tracking headway are resorted to, such as documents, reports, and sign-offs at notional stages of completion. The critical issue is that none of these artifacts release value. Rather they proxy for value which is expected to be released at some future point.
An agile "project", in other words, is essentially predictable rather than predictive. It is predictable because empirical evidence of progress is made available in a timely manner
Edited: | Tweet this! | Search Twitter for discussion