Building a Bridge from the Current State to an Agile State

In Agile, Business Analysis, Lean, Product Management, Product Owner, Product Teams, Project Management, Scrum, User Experience by [email protected]

The Chronicles of an Enterprise Agile Transformation (Part Four)

Finally, we got to the “heart” of the presentation where the engineering lead described how we were going to change our thinking from our current state development practices to our proposed new state of Agile development. The following diagram was presented as an overall high-level mapping of current state to the Agile state.

The Engineering team walked through each phase providing guidelines for each stage  of development throughout the project life cycle. They went phase by phase, providing a bridge between the current product development methodology (waterfall/incremental) phase to the new Agile methodology phase.

 

Greg Geracie, Actuation Consulting, Take Charge Product Management, Steve Starke

Agile State Flow

 

Editorial Note: I took issue with this diagram because it didn’t call out the Project Manager role. There seemed to be some assumptions being made that a project manager was now equal to a scrum master. To read more about this debate check out my blog post on http://www.planbox.com/blog/.

Below are the guidelines by phase that were presented:

Requirements Phase to Release Planning Phase

Guidelines for the Release Planning phase:

Release duration should ideally be 3-4 months and no more than 6 months

  1. Define your project team: Following roles should exist on all teams
    1. Product owner, Scrum Master, Development Manager, Architect, Developers, BAs, QAs, Operations representative
  2. Review project goals and minimal marketable features (MMF) needed for a viable release
  3. Categorize high-level requirements into features
    1. Break requirements into functional themes
    2. Create technical themes (plumbing and architecture related) and operational readiness related themes. List specific efforts needed related to deployment, performance, administration, and monitoring of the application in production
    3. Meet with Operations to incorporate their feedback
  4. Conduct overall release sizing based on high-level requirements
    1. Best and worst case estimate by themes with the team. If estimates are different from the original estimates that were provided in the investment planning process, then discuss the discrepancy with the product owner
    2. Capture all assumptions being made during the sizing effort and review these assumptions with the entire project team

Analysis Phase to Technical Feasibility Phase

The Analysis phase in the current product development lifecycle would now be called Technical Feasibility. This new phase would consist of the following guidelines:

No more than 4 weeks long for a 4-6 month development project

  1. Team to create stories for conducting technical feasibility at theme/feature level
  2. Product owners to work on the detail requirements. This work can be captured as stories with design details in the story narrative OR in a separate document.
  3. Team to review the detail requirements at theme level and brainstorm on the technical approach
  4. Conduct Reveals with the product owners and the entire project team to review progress
  5. Team to create technical approach document(s) by theme
    1. The purpose is to document the decisions made by the developers and the architect
    2. In lieu of detail technical specifications, we recommend, data and process flow diagrams, architecture  diagrams (e.g. if a 3 tier architecture, components by tier, web services architecture etc)
  6. Create product backlog for implementation
    1. Stories by themes created by the product owner
    2. Stories estimated by the team – A story should ideally be 3-5 days of effort
    3. Team to create pre-requisite technical (plumbing/architecture) stories for the functional stories
  7. Conversation with the product owner on total effort being spent by theme (and if it has an impact on the project schedule, revise the project schedule and get approval from stakeholders)
  8. Revise the Release Plan

Iteration Zero – Get Ready for Development

This, Iteration Zero, was a brand new phase for the development lifecycle. The following were the guidelines:

  1. Project created in source code repository
  2. Foundational technical proof of concept  provided (this could overlap with technical feasibility)
  3. Test driven development and continuous build infrastructure in place
  4. Check licenses of all Open Source software for compliance and verification of all 3rd party software and versions to be used
  5. Test strategy and planning 
    1. Setup environments
    2. One of the environments should match in setup/configuration to production
    3. Additional environments that might be needed: Operations testing, UAT, Automated regression testing

Iterative Development

The Development phase in the current product development methodology would now be explicitly called the Iterative Development phase. The guidelines for this phase are below:

  1. Daily Scrum meetings and daily feedback to the team on progress with iteration burn down chart needs to occur.
  2. Team iteration planning for the upcoming iterations should be occurring
  3. Iteration tracking should be done by the Scrum Master
  4. A “working” product delivered with every iteration. “Working” being defined as being able to be tested and integrated, but not yet pushed to production. It may take several completed features before a release is pushed into production.
  5. Cross-functional team reveals need to occur to demonstrate new functionality
  6. Team retrospectives must be conducted by the Scrum Master to discuss what went well and what needs improvement
  7. It’s important for Agile teams to discuss operating mechanisms like the ones listed below. These are provided as examples only for guidance:
    1. Encourage separation of environments to ensure the team truly has a working product every iteration e.g. Developers should not be performing demonstrations of code from their own workstation at the team reveals
    2. BA/QA should acceptance test every story before its considered ‘done’
    3. Developers should not have access to the acceptance test environment. Software should be deployed automatically and the software is required to work in any environment without the team configuring it manually.
  8. In order for a story to be considered complete, it needs to work in an environment other than the developer’s workstation.
  9. Story should only count towards the velocity of the iteration if the story passes BA/QA acceptance test i.e. meets the ‘Done’ criteria
  10. Code complete at the end of development cycle.
  11. Product defects should be handled in the following manner:
    1. Defects should be part of backlog grooming
    2. Defect triage with the product owner needs to occur in order to prioritize defects
      1. Critical – handle right away, take priority over story
      2. High – schedule in the upcoming iteration
      3. Normal – schedule with product owner’s feedback
    3. Defect iterations should be scheduled in order to catch-up on defects if defect backlog gets too big

…At this point during the presentation, time ran out. We would have to meet again to discuss the feedback from senior leadership and what the planned next steps needed to be to continue the transformation.