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:

• Process and gates to manage the budgeting and requirements gathering.
• Project managers to allocate resources, parcel-up pieces of work to different people and then chase them up, creating summaries and reports for stakeholders.
• Governance and steering groups reassure the organisation with a sense of control.

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.

So, what does the alternative look like..

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:

• Better solutions – created from multiple perspectives
• Less stress as team can focus on their work and not be distracted
• A sense of common purpose and endeavour can raise moral, less solitary working.
• Organisational resilience as skills are spread between team members
• New arrivals can get up to speed faster and blended into an existing team. Important in organisations with increasing rates of churn
• Key-man risk can be mitigated with no isolated developers.
• Quality improves through peer review and join responsibility for code quality.

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.

Further reading

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

Tweet.

Agile can be seen as an interplay between its two overarching goals of building the right thing and doing it properly. Although 'Interplay' is putting it positively, as they often compete for resources and spend much of the time far from a harmonious balance

The dominance of Scrum in the Agile landscape has perhaps had us focused too much on the left hand side of the picture. We’re slowly correcting this to appreciate the importance of the counterbalancing right.

Of course the more technically-aware have been working hard on this for many years. However, it’s still quite shocking just how few organisations have really grasped how important, and difficult, it is to build the thing right.

Such an imbalance is probably the fastest way to accumulate technical that we have yet invented.  

Helping stakeholders understand this picture enables them to appreciate the true Agile picture and the consequent levels of investment in skills, people and tools that are needed.

Luckily Agile has some very good and established patterns to ensure we can achieve this balanced state.  

Yin and Yang speaks of complimentary and interdependent forces in a dynamic system, just like those we try to work with in software development

Build the right thing..

Is achieved through a number of established Agile principles and practices. 

Get close to users and understand their real requirements

• The Product Owner role in Scrum, and its equivalents in other Agile approaches – clearly identify the person with domain knowledge who we can hold accountable for ‘what’ is built.
• Well established ways to deeply understand requirements e.g. User stories, Specification by Example or Feature Driven Development
• These both enable us to hear the ‘user’s voice’ amongst the complex hubbub of development
• Early, frequent validation of our deliverables keeps us aligned to expectations
• More telemetry and metrics of how the solution is actually used help to validate the solution provides us with the final feedback loop

Build better solutions through closer collaboration and on-going emergence

• Daily collaboration within the team and between the team and PO or users encourage emergent solutions, informed by multiple perspectives.
• We have found ways to unleash the creativity of intelligent people and tapped into the collective, focused purpose the team.

Don’t begin to develop software that is not properly understood or may become blocked

• Definition of Ready (for development) ensures we don’t start to work on requirements that we don’t understand or are too big or ambiguous.

Align overall development capacity to changing organisational priorities

• Portfolio Backlogs act to align development capacity with the organisation’s evolving priorities in a single place, transparently.

And.. the Agile Manifesto says

• “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”.
• “Business people and developers must work together daily throughout the project. “
• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Build the thing right

Summarises the technical rigour that many organisations appear either unaware of – or find too difficult to try.

Prevent bugs or find them quickly when cheaper to fix

• Test Driven Development, Continuous Integration help to prevent defects – or find them rapidly
• Cloud-like technologies mean we can finally afford to do performance testing earlier in the process

Keep focus on the code quality

• Peer review of code, clear coding standards and pair programming help to move good practices around a team and establish accountability amongst peers for the work they are doing. This is much better than trying to ‘police’ the quality by an architect or other external role
• Code quality tools like SonarQube track key trends, like complexity or maintainability, over time. Alerting us to any negative drift in the trends of complexity and maintainability.
  • If I were using outsourced teams, this would be an easy, transparent and fair way to hold them accountable for the quality of their work - and yet so few companies do this.
• Refactoring and principles of ‘internal open source’ also help to maintain the focus on code quality.

Make the solution resilient and adaptable

• It is certain that the solution will evolve over time. Well documented code, wrapped-up in automated testing is a fundamental pre-condition to that process of evolution.

Focus on finishing high quality work

• The team’s ‘Definition of Done’ and Scrum’s emphasis on shippable quality every sprint helps to embed quality in the team’s daily work.
• Slicing work up into small chunks means we get more of into the done column more frequently

Building it right, through to live

• The ability to reliably deploy the solution into live is a key part of building it right.
• The automation of testing, build, environment-creation, configuration and deployment are relatively new though already indispensable set of disciplines and capabilities.
  • All brilliantly summarised in Jez Humble’s book ‘Continuous Delivery’

And.. the Agile Manifesto says;

• “Continuous attention to technical excellence and good design enhances agility. “
• “Simplicity - the art of maximizing the amount of work not done - is essential. “
• “The best architectures, requirements, and designs emerge from self-organizing teams”.