I have spent a long time delivering different IT projects. Whilst the details vary, it is not hard to spot commonalities.
There is the part at the start where a need is identified. This might be building a business case or identifying a sales opportunity. The project springs into life if the need is of a high enough priority and someone is willing to invest.
Next comes the start up. This includes understanding what needs to be done and how it will be achieved. Whilst project delivery methodologies differ they have a concept for this start up stage, project initiation, inception or sprint 0.
The bit in the middle makes up the bulk of the project – delivery. It is where the main portion of the work occurs. It might be processional; it may be iterative but this stage can take from a few months to years.
And finally, there is a ramp down. The work is coming to an end and people are moving on to other challenges. Sometimes there is a big bang release and other times there is a gradual reduction of new features and a settling into a BAU style of working.
What is clear is that there is a start, middle and end. This is obvious in waterfall style projects but this is often the case in more agile projects. There can be the initial creation of the backlog, delivery of the high-risk stories, working towards to minimal viable product, knocking off the remaining stories and then stabilising the solution.
This is project centric thinking. However, no-one actually asks for a project. They want the result. So why do we think in terms of projects? Instead we should be thinking about products. Whilst a project and product may look the same initially, many projects stop when the product is actually becoming interesting: when the product is being used by real customers.
For this discussion, I classify a product as something that is live and being used by customers. For the team that own the product there isn’t a start, middle or an end – just what is next. There are new features to be built, support incident to investigate and resolve and the team have access to real customer feedback.
When the product is initially being build, prioritising the work is relatively straight forwards. The backlog order is defined by the product owner representing the potential customer. It does not matter how well this is done it is still a potential customer. Most agile delivery efforts will be striving to get the product live to real customers, to get real feedback, but more often than not we will be shipping early increments to stakeholders who are not the real customer.
Once the product is Live, in the hands of real customers, then the fun starts. You’ll actually see what they really want, maybe by interpreting usage metrics or by hearing what they say to your support team. Perhaps you use UserVoice to capture feedback and new features requests. Now you have work coming from multiple sources. You have a backlog of new features, but you also have features the customer is requesting. You’ll have live incidents to deal with and you may identify technical improvements through application performance monitoring tools like NewRelic.
The prioritisation of these different streams of work can become a challenge. When working with small product teams it is likely that the team will be responsible for all aspects of the product, so knowing where to focus at a given point in time can be difficult. A team has a fixed capacity to do work, or in other words, they can do a predictable amount of work in a fixed period. If they are focusing on delivering a feature it can be very disruptive to have to focus on an immediate serious support incident.
Therefore, the team needs to put in place structures and ways of working to deal with these scenarios. Being able to react to a problem and fix it immediately is of no value unless you have a means to get that fix in front of customers quickly. Therefore, focusing on foundations such as Continuous Integration and Continuous Delivery is just as important as finding heroes in the team who will drop whatever they are doing at a moment’s notice.
However even the best CI/CD technology stack in the world can’t help if you can’t ensure that your latest code is stable when you need to. There needs to be automated testing at all levels. You need a branching strategy that keeps unfinished features out of the main release branch or you need to be building new features on mainline hidden behind toggles.
Often, during project focused efforts you find the people who manage the purse strings challenging you on why their needs to be investment in these areas. Whilst they are useful, are they really needed to get the product out of the door? However, we know that they are essential for keeping the product going throughout its lifetime whether you are involved at that stage or not. And people will remember the product through its quality and flexibility not the project that was used to deliver it.