Work, even in agile organisations, will often take the form of projects: units of work ranging in length from a couple of weeks to many months which, when shipped, yield value for your organisation.
Why is thinking in terms of projects helpful?
- Scope: Making big, needle-shifting improvements will require commensurate ambition. Projects motivate a framing using which we can both imagine those changes and consider the practical steps taken in realising them.
- Coordination: Projects of any reasonable size will necessitate multiple people working together whose efforts have a compounding effect. Projects are a means by which you can muster those resources.
- Risk: Projects need to deliver results, and so you must consider what obstacles, if unaddressed, could impede you in that delivery 1.
All of which is very helpful for us in delivering that value - but certain conditions apply when working in this fashion. You must have:
- Clarity: Projects must have a very clear desired outcome, given some starting point, and an understanding in how the work being done moves you towards that outcome - coordination of multiple people cannot happen without it. If that clarity is not there, you must provision it.
- Focus: Digressive yak shaving is not your friend in these circumstances (unless, of course, you’re in the business of yak shaving - in which case, go wild).
- Momentum: The default state of a project is to not ship 2 - a high throughput of code changes is the project’s activation energy and maintaining it takes constant effort. Allowing friction to creep in, slowing feedback loops, extinguishes a sense of progress and erodes motivation.
What’s the alternative to project-based thinking?
This contrasts with Incremental Improvements as a means to deliver change. In that mode of work, you may be digressive and curiosity-driven, not demanding a clear result other than that you learned something or left things in a better place than you found them 3.