Arranging work around projects is a significant impediment to the creation of a responsive organisation. Hopefully this simple illustration shows how focusing on projects generates waste and delay – and the good news, there is an alternative.
Clarification: Following some feedback I suggest you read this in the context of any project where value can be delivered incrementally - typically IT projects. (5th Dec)
Project-centric thinking allocates ‘resources’ to the project. A team-centric approach takes the work to the team.
Project-centric thinking first creates the somewhat arbitrary artefact called a ‘Project’
It then attaches a number of key elements like; a budget, project manager, requirements and shares of different ‘resources’
Projects artificially create a large batch - where highly valuable features are made unnecessarily dependent, and therefore delayed, by lower value features.
When you include the other projects, the picture becomes complicated.
This complexity appears to need process to bring a sense of order and so we introduced:
However each of these interventions generates waste.
A Catch 22, where both the complexity and the attempts to deal with the complexity, introduce waste through task switching, delays and non-value-adding activities.
A note on waste: I am using the lean definition of waste i.e. any activities undertaken by an organisation that consume resources but do not add value. Where value is defined by the user.
In a picture as complex as this we begin to focus inwardly on the process rather than on the user and the flow of value.
Please don’t read this as a dig at Project Managers. These activities (not the role) are systemic and have emerged through an understandable, but ultimately misguided attempt, to manage and plan our way out of complexity.
Keep the teams stable, with all the human benefits that gives us, and take the work to the team.
Stable cross-functional, co-located teams develop trust and effective ways of working.
They bring other benefits too:
A way-of-working based on Agile principles and practices brings a simpler, calmer picture of how value flows.
A portfolio backlog is created that includes all the work to be done. Not forgetting non-functional work and those smaller nuggets of functionality with a potentially high ROI and user benefit.
Portfolio backlogs help move towards a more continuous flow of smaller batches of work. This improves the predictability that the business craves.
Work is taken to the team.
The work might be 'accompanied' by a Product Owner who is clear about the opportunity, knows the domain and is best placed to maximise the return from the investment that is about to be made .
A single parcel of work is taken to the team.
This could be a Release lasting a few months although preferably a smaller MVP or shippable increment. The smaller the better.
Bigger pieces of work can be given to more than one team and split down into backlogs for each team.
Note: work in the portfolio backlog is not made up of projects but of releases of projects, each of which can be shipped to live. Giving us earlier value, less risk and more predictability.
This simpler, calmer picture of work being taken to the team requires fewer Project Management non-value-adding activities, like resource planning and delegation and instead focus on value-adding work.
Governance can add value by guiding and validating work.
If you want to explore this further then there is plenty more on the #noprojects tag on Twitter
Alan Kelly has been talking about this for a while. http://www.allankelly.net/static/presentations/Oredev2016/Oredev-BeyondNoProjects.pdf
and InfoQ has a good article https://www.infoq.com/articles/noprojects1-projects-flawed
Email Bazil Arden
© Copyright 2018 RippleRock