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
- 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
- Program Manager
- Global Change Manager
- Scope definition for the foundation
- Release management of the foundation
- Organization of SME-Board
- Prioritization
- Product Owner for foundation
- Architect
- Knowledge of implementation framework
- Sets up development guidelines and general implementation approach
- Gives first estimation of requirements with a technical view
- Better management of the large product backlog, due to technical understanding, prioritization estimation
- Program QA
- Set up of change management process for the program
- Regular overall review of 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 memo for the CAB (Change Advisory Board)
- Discusses additional technical issues
- Process Review Meeting (quarterly in the beginning, currently twice a year)
- Participants: Whole team
- Subject Matter Experts Board (SME) (bi-weekly)
The experiences:
- User stories: Definition of user stories dependent on target group, developing a template of user story definition fitting for all team member 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 took also lot of time and patience
- Definition of project related sprint releases is useful 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 important for a successful project
This was the last part of our small Series about Agile Project Management
The whole Series contains 4 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.
