Managing Product Delivery

The core process that represents all the build activities

Here we look at the Managing Product Delivery core process and its activities that have been tailored for an agile approach to development.
The owner of this process is the technical team lead/ lead developer. The project manager supports the team lead in this process through the activities in the Facilitating & Controlling Project Delivery core process.

The main activities needed for a software build iteration / sprint

The different activities required to manage product delivery with 2, 3 or 4 week sprints

A couple of things to think about before we go through activities in this process.

Your focus should be on creating functionality and features that deliver incremental levels of capability to the organisation with each iteration. To help your team to do this efficiently you also need to look at optimising the flow work. Regularly evaluate how you work and look for ways of doing it better and faster.

Limit Work In Progress (WIP)

As a general guide you should limit the work in progress so that you can reduce lead times and make more frequent releases. This will enable your team to deliver better quality and at the same time build trust with your customers as they will see the results of their investment earlier and more often.
How does reducing WIP improve quality and lead times? By reducing the WIP, you reduce the complexity and the amount of information any individual has to retain and maintain in order to do the job.
I will do another artical on improving throughput that will go into this in more detail

1 Accept a work package

By accepting a work package the production team is formally accepting responsibility to work on the activities allocated to the work package. It is important that the production team is consulted on what is included in the work package rather than just instructed to get on with the work. We want them to be proactive and engaged.
For a software project the work package will consist of prioritised user scenarios and acceptance tests. See this as the prioritised input queue for development work.

2 Create tasks (Tasking / Collaborative analysis)

At the beginning of each week it is useful to take half an hour or so to quickly go over the work planned for that week. Tasking involves both the product owner and the technical experts who will develop the outputs. The product owner needs to be involved so that she/he can answer any questions that may come up and give clarifications. This will enable the team to share knowledge and decide who is best suited to deal with each requirement or if a couple of people need to be involved.
•Allocate 5 minutes to discussing each US&AT and writing up tasks; if more time is required assign the work to a dedicated team, so that other team members can get on with their work.
•Try and keep the weekly tasking process to half an hour.
•Developers should be prepared to make recommendations to the client on alternative options. This may mean that the client needs to re-write or update the User Scenario & Acceptance Test.

Tasking along with other activities is a great way to get new team members up to speed on what is happening in a project or even on an operational production line.
When necessary run extra tasking sessions during the week.

3 Execute a work package (Development work)

The name here is derived from the PRINCE2 standard. In software projects this includes work such as writing the code, creating the required functionality and testing it.
As the team is working they will come up with questions and recommendations that need to be discussed with the product owner. So it is important that the product owner or an end user is available to discuss different options. Any changes that fall within agreed limits can be implemented immediately otherwise they should be put through the change management process. The change management process will be tailored for each project; there is no one size fits all.

The production team as a general rule should be able to decide how they work so long as they deliver at the right quality and they achieve a reasonable production rate. Within the “Execute a work package” process the production team may decide to have the following as part of their work processes:

  • Test Driven Development
  • Pair programming (Tailored to suit each work package and individual)
  • Code refactoring
  • Continuous builds

  • 4 Quality Review

    In this process we are focusing on the quality of work. Any issues relating to the work package or iteration outputs will likely indicate a quality problem with how we work.

    The principle participants in this process are the Product Owner / Senior User (or an appointed representative), Business Analyst and Team Lead. The practice of carrying out quality reviews has several advantages.
    The practice of carrying out quality reviews has several advantages.

  • Improved understanding between users and production team/suppliers.
  • Team building, in the sense that we get a better understanding as to how others think and what their expectations are
  • Educational, new team members can get up to speed by listening in on the review and understanding more about the project product and what the product owner expects and what technical challenges that lie ahead.


  • To assist in this process the Users can carry out Acceptance Tests on the User Scenarios as soon as they are developed, they can submit any issues to the BA or Team Manager before the review. The Product owner/Senior User attending the review can sign off the work package if satisfied or reject the work package.

    By carrying out quality reviews often and starting early we have a much greater chance of uncovering any potential issues early on. This in turn increases the likelihood of delivering the capability that the end users need to realize the intended benefits from the project output.

    To enable the developers to focus on development work I recommend that the Business Analyst or QA person prepares and runs the review. The review comprises of 3 main phases, preparation, presentation and post review report.

    The following can help with improving quality in software development
    • Asking developers to write unit tests and automate them to provide automated regression testing
    • Using testers to find defects
    • Code inspections that are carried out regularly, you can use different means such as pair programming, peer review or code walk through.
    • Collaborative analysis and design
    • Use of design patterns
    • Use of software development tools that help identify mistakes

    5 Deliver a Work Package

    The objective of this practice is to formally hand over the Work Package to the Project Manager. The Team Manager must ensure that;

  • All quality activities have been carried out and approved
  • The products that are to be delivered by the Work Package are delivered, in accordance with the instructions in the Work Package.
  • Acceptance and approval documents have been signed off.
  • Update the Team Plan to show that the work is complete; the Project Manager will update the stage plan and project plan when the Work Package is accepted.
  • The delivery of work packages can be used as a means of measuring progress.
    Please note that this process and releasing code into the live environment are not the same.

    6 Retrospective (Lessons Learned and Continuous improvement identification)

    At the end of each iteration the production team has a “retrospective” where they analyze how the team can be more effective in doing their work. This is a good opportunity for the project manager to listen to the team and understand their needs. This is especially important when help is needed from outside the immediate production team.
    Use the retrospective to improve or change working processes with the objective of increasing throughput and reducing lead time.

    How Managing Product Delivery relates to the other project management processes

    There should be a clear demarcation between product development and project management. This will allow the production team(s) to focus on the immediate work and the project manager to focus other important issues as well as on resolving constraints before they become an issue to the production teams.

    It is also possible with this project management structure to have several product or service development teams using different development methods.
    We view methodologies such as XP, SCRUM and Kanban as very good production methodologies that work well with this project management structure and support the standard set up by the agile consortium.

    Comments are closed.