Passing a course and being coached is great. However, the real learnings come from the tailoring of good practices from methodologies to real projects. Being a real practitioner cannot be gained from a qualification alone, so we practice and learn lessons.
Below is a summary from a recent CMS migration project for a large magazine responsive website. The project management approach borrows practices from Scrum and some relevant artefacts from PRINCE2.
Project Summary
- The work was more complex than estimated, with new tasks being uncovered each week.
- The additional 30 days effort and slow average velocity (due to unplanned tasks and blockers being investigated) delayed the completion of development, but the original launch date of 09-Sep-15 was achieved and delivered to budget and scope.
- Some of the main test phases were required to overlap with User Acceptance Testing to achieve the desired launch date, as development did not complete when planned or re-planned.
Burndown Chart
With an estimated Total Project Effort (green line) of 103 ideal man days and an estimated 70% focus factor, the Planned Remaining Effort (blue line) was due to complete on 31-Jul. This date was later revised to 21-Aug, giving the Revised Planned Remaining Effort (grey line). However, as unplanned tasks increased the Total Project Effort (green line) to 133, the Actual Remaining Effort (red line) completed on 03-Sep.
The table below shows the numbers behind the chart.
Practices
- 10 day iteration (Sprint) planning in Trello, daily stand-ups with a physical task board, demos, retrospectives, burndown charts, velocity measurement and various charts created in Google Sheets.
- Source code management and versioning with GitHub and continuous integration using Jenkins.
- Quality upheld by coding standards, code reviews, some pair programming, developer testing, sprint demos and formal QA. Testing scope, responsibilities, defect priorities, acceptance criteria and approach agreed in a Test Plan.
- Relevant documentation – Test Plan, Test Cases, Release Notes, Weekly Highlight Report, Project Costs and a regularly updated RAIDD (Risks, Assumptions, Issues, Dependencies & Decisions) Log.
Learnings
- The Product Backlog Refinement and Sprint Planning meetings were not comprehensive enough. Although raised in the Sprint Retrospective meetings, there was no appetite during the project to have extensive planning sessions – even if the sessions were split.
- However, at the Post Project Review Session, the team finally concluded that more detailed planning sessions were necessary, to help reduce the occurrence of unplanned tasks and blockers.
- Although some unforeseen work is inevitable, the team agreed that there needs to be a balance in Agile between doing work and planning work, i.e. upfront thinking.
- The value of upfront thinking needs to be shared by the team before planning sessions can be wholeheartedly supported.
- Now the team have learned this lesson (the hard way) and really value planning, they support the principle of planning and practice planning in subsequent projects as a natural extension to their daily tasks, rather than due to enforcement by the Agile Coach / Scrum Master / Project Manager.
