, , , , ,

With the movement toward agile software development and agile project management; and with all the training available from certified scrum trainers, agile certified practitioners, and product owner, and with the move of software development to near-shore and off-shore location; why isn’t there any training on how to transition a scrum team from one location to another and more importantly, why does a hybrid agile approach seem so bad? The perception is that if you are not using “pure” agile then you are prone to fail in your attempt to utilize agile to achieve all of its benefits.

But there are times in organizations that leadership decides to go in a direction that is in direct opposition to the agile manifesto and the twelve agile principles. What is a certified [agile] project manager to do? Complain about the lack of “pure” agile commitment? Become a martyr and work against the interests of leadership? No, what a certified [agile] project manager would do is find a way to incorporate the best practices of the project management with the twelve principles of the agile manifesto in way that leads to team growth, increased productivity, and more efficient project delivery in an iterative way.

The agile team decided to use scrum as a framework but with caveats. We had to incorporate approval gates and work with a project management office where I was required to provide status updates, manage change, and obtain approval for budget and release management. This resulted in a hybrid agile approach called DiPD®, Disciplined iterative Project Delivery®. The iterative framework is typical of any scrum development workflow with a few exceptions. One, I did not release at the end of every sprint; two, I needed approval to move from project intake to release; and three, I used documentation.

Starting with the product backlog, also known as a work item list. It contains uniquely ranked stack of user stories so the team can focus on delivering valuable functionality. The ranking of the user stories aids the business stakeholders to decide which functionality is more valuable than others (e.g. MVP1, MVP2, etc). Having MVP2 user stories in the backlog that are not being worked on is acceptable and means the team hasn’t gotten to them yet. User story dependency is included so the team doesn’t work on a user story too soon; this prevents work disruption.

Project Scoping Current State (Business Ideas)

This is important to our team for the following reasons:

  • First time our team is made aware of the entire project.
  • This is formal notice given to our team to proceed with maturing the Project.
  • While change requests have the business needs defined, they do not include all the assets necessary to build out the solution.
  • This introduces the project to the larger team so they can become aware.
  • This identifies dependence among user stories which aids the Product Owner in aligning the Project for future sprints and releases.
  • It provides a high-level estimate of effort of business decision can be made.
  • This is the formal handoff from our team to our client of the analysis performed.
  • Business has the opportunity to resubmit or stop the project.
  • This formalizes the project into executable work for future delivery.

This is where our team provides the estimates, acceptance criteria, and user story dependency back to the Product Owner, and where our client can approve / reject / hold the change request.

 Epic and User Story Maturity (Product Backlog)

This is important to our team for the following reasons:

  • The business analyst works on only approved projects.
  • The Scrum Master can provide awareness of the approved user stories with each of the teams.
  • The Scrum team members have vetted the general requirements and posted needed questions/clarifications ultimately back to the Product Owner for maturity.
  • The content of user stories is complete; all questions/clarifications have been made; and all acceptance criteria are adequate for development and testing to successfully deliver.
  • The Scrum team members understands how to approach the testing of the user stories’ functional and non-functional aspects.

This is where our product backlog is built with a goal of keeping it healthy so work can be continually ‘pushed’ to the team.

 Acceptance (Sprint Backlog)

This is important to our team for the following reasons:

  • Allows our team to fill out sprint capacity.
  • Allows our team proactively make adjustments to sprint work due to changes in resource availability or prioritization.
  • Sprint and release placement aids our client in knowing when an approved project are planned for release.
  • Our client can notify their Partners accordingly.
  • Their Partners can begin assigning resources UAT.
  • Our team is able to ready the approved project and user stories for sprint planning activities.
  • Our team is able to provide a sprint roadmap to the team.
  • Our team is able to provide a release roadmap to LE.
  • Our client is able to realign partner priorities and communicate expectations.

Our client and our team are able to baseline the sprint

Approval Gates (PMO)

Agile, by its nature does not have approval gates. However, in all of the companies I have worked, I have never been able to deploy code to a production environment without having to obtain some level of approval. So in reality, there is an implied approval that has to be obtained before moving forward with a deployment. There are mandatory approval gates my team must adhere to as work moves from idea to working code in a production environment.

This is important to our team for the following reasons:

Gate 1: Defined business ideas

  • Our client is able to filters unviable projects from coming to our team.

Gate 2: Estimation approval

  • Our client determines if business case is relevant based on estimates provided.

Gate 3: Backlog maturity

  • Our client reviews functional solution for MVP and determines if the solution is supporting business need.
    • Our client needs to understand what they are signing off on so it meets the business need preventing rework and future story creation.
    • Our client needs to plan UAT, engaging their partners, aligning external parties around the functionality that is being defined.

Gate 4: Sprint planning

  • Our client defines the priority of work among all projects.

Gate 5: Sprint demo

  • Our team and our client signoff on expected work, the sprint increment, in accordance to quality requirements.

Gate 6: Our client provides our team with release approval.

Both our team and client are assured that modifications work as expected in the end-to-end environment and decides whether work will be released

The Results

There is a lot to like about the DiPD® model. For starters, I was able to increase scheduled release frequency, year over year by 45%. I was able to increase scheduled out of cycle releases year over year by 300%. I was able to add and train a second scrum team using the DiPD® framework and deliver a digital download platform that had failed in a larger company, in 7 months. And finally, I was able to successfully transition development from the U.S. to Bangalore, India in 4 months. There is still a lot of work to do but the hybrid framework is working for my team and my client. And remember, quality is not what you or I deem it is; quality is what the customer deems it is. Specifically, when a product of service completely meets a customer’s need, quality is delivered (PMBOK®, 5th Ed.).

To close, using a hybrid agile software or project management approach isn’t a bad thing. With the challenges facing companies today, following any framework to the letter is a huge risk. You need to incorporate the best practices of project management with the twelve principles of the agile manifesto in way that leads to team growth, increased productivity, and more efficient project delivery in an iterative way. Move to pendulum from bureaucracy to agility…iteratively™.