XI. Embrace Product-Oriented Delivery model

Create cross-functional teams to allow Business and IT work together

Many of us in the software delivery space have worked on a project in some shape or form. These projects would normally start with an initiative where organisation decides to deliver XYZ project to either help the business move forward or enhance clients’ experience, or both.

These projects will normally encapsulate a random selection of developers, testers, business analysts, team leaders of various sorts, and of course the project manager. Project manager’s role is to create a roadmap for the XYZ project delivery from which they’ll be able to derive a delivery date, normally referred as go-live or big bang date.

What tends to happen with the project-oriented delivery model is that all, quite literally all, activities pertaining to the delivery of our XYZ project will be accounted for, estimated and projected into future dates upfront. So in the end, probably few weeks since project kick-off, you end up with a Gannt chart which from the stakeholder point of view gives something tangible to hold to because as far as they are concerned - this is the date they’ll see XYZ live.

How often has the go-live date been met in this project-oriented model?

Think Product

The product-oriented delivery model is an approach where long-lasting, product-oriented teams are formed to build and support the product going forward. There’s no concept of end date as such as the work and requirement is discussed in terms of features and minimum viable product (MVP) delivery.

What MVP means is that the team will focus on the top, must have features, of the product and deliver these as soon as it’s possible for the business to realise value from. As it stands for the team, the core structure of product team is as follows:

1. Development Team: in other words, these are to DO-ers working and delivering features
   • Developers
   • Testers
   • Analysts
   • Infrastructure, Operations, Security members

2. Product Owner: mediator between business stakeholders and the product team

3. Scrum Master: facilitating the ceremonies and smooth collaboration between product team members and stakeholders

As opposed to projects which tend to be delivered in a waterfall model, hence the Gannt chart mentioned earlier, the product teams will work in an agile software delivery pattern adopting Scrum. This brings few material advantages:

1. Product Backlog Refinement: Less time spent upfront estimating the entire effort and projecting dates
2. Sprint Goal: More time dedicated to delivering business value fast and early
3. Spike: Possibility to trial ideas, innovate and fail quickly
4. Scrum Ceremonies: Bonds team members together right from the start of the scrum
5. Daily Stand-up: Ability to react to adverse events quickly with little impact to long-term expectations
6. Sprint Review: Transparency and open communication at the stakeholder level

« Previous | Next »