Agile Project Management – Agile on the next Level – Program Management (Part 4)

The Program:

• Implementation/migration of round about 25 instances with a Specific Laboratory Software, supporting ~30 laboratories world-wide
• Reduce support cost per instance by standardization (for existing and added instances)
• Development of a template (“foundation”) containing common functionality which can be influenced by configuration. Integration of the foundation into all instances. Provide all instances in operation with the current version of the foundation on a regular basis.

 

The challenges:

• 2-3 implementation projects parallel
  • Full scope not clear in the beginning
• Increasing number of instances in operation
  • Regular update of foundation version necessary to keep them streamlined in order to reduce support cost
  • Requirements and bugfixes from systems in operation have to be included into foundation development process
• Many and changing team members, part-time availability
  • Round about 12 team members (incl. development and support)
  • Changes due to boundary conditions triggered by external influences
  • 80% of people only part-time available for the program
• High interdependency between ongoing projects and Systems which are already in in operation due to foundation development and shared resources.
• Organization of communication process between projects and operation
• Balancing individual business needs on one hand versus streamlined standard software on the other hand

 

Why agile:

• Manage individual projects (introduction of new Software)
  • Decision for projects taken during run-time of the program
  • Sequence of projects changing
• Manage user stories across projects (details not available at start of the program)
  • Each new project delivers a slightly differentiating list of user stories
  • Each instance in operation delivers additional stories
• Manage process
  • Change process quite complex, adaptions to the process must be quickly implementable

 

The agile setup – how did we handle the challenges:

• In fact the program has been setup before we got in touch with the standard Scrum process (See our blog: What is Scrum?). So we used other role names, but some of them have exactly – amongst others – the tasks defined for the standard Scrum roles.

 

 

Orange = Business, Green = IT

 

 

• Scrum Master ~ Development Coordinator / Program QA
• Product Owner
  • Program Manager
    • Overall Product Owner
  • Project Manager and Application Managers
    • Product Owner for particular instances -> Prioritization and review/testing of stories
    • Write User Stories
    • “Imitate” the end user for sprint releases
• Global Change Manager
  • Scope definition for the foundation
  • Release management of the foundation
  • Organization of SME-Board
  • Prioritization
  • Product Owner for the foundation
• Architect
  • Knowledge of the implementation framework
  • Sets up development guidelines and general implementation approach
  • Gives the first estimation of requirements with a technical view
  • Better management of the extensive product backlog due to technical understanding, prioritization estimation
• Program QA
  • Set up of change management process for the program
  • Regular overall review of the change management process
• Additional meetings
  • Subject Matter Experts Board (SME) (bi-weekly)
    • Participants: Whole team
    • Reviews the requirements from a technical and functional point of view
    • Gives implementation recommendations as decision memos for the CAB (Change Advisory Board)
    • Discusses additional technical issues
  • Process Review Meeting (quarterly in the beginning, currently twice a year)
    • Participants: Whole team

 

The experiences:

• User stories: The definition of user stories is dependent on the target group; developing a template of user story definition fitting for all team members in different roles, with different views and different backgrounds, is a time-consuming task
• Testing: Developing awareness for testing right after delivering of implemented user story also took lot of time and patience
• The definition of project-related sprint releases is helpful to get quick feedback and reduces the effort for project managers (not every project manager has to test each increment)
• A clear definition of product ownership, incl. responsibility for successful product delivery, is vital for a successful project.

This was the last part of our small Series about Agile Project Management

The whole Series contains four pieces:

Agile Project Management – Basics (Part1)

Agile Project Management – What is SCRUM (Part2)

Agile Project Management – Agile Project Management in real Life (Part3)

Agile Project Management – Agile on the next Level – Program Management (Part4)

If you have any comments on our Articles, your Feedback is highly welcome.