Last October, Jake Edwards, Adam Waycott and I completed a two day course and an exam and became Certified ScrumMasters. What is Scrum? Scrum is an agile framework that allows us to focus on delivering business value in the shortest time.

We wanted to discover if Scrum could assist us to improve our internal product development, and delivery of our NAV implementations. The Agile values that appealed to us, based on how we already typically work, were:

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to change over following a plan

There were several Scrum characteristics that resonated with us during the course and caused us to re-evaluate our implementation tools and processes:

  • Utilises iterative development with continual inspection & adaptation
  • Embraces change as an opportunity rather than as a hindrance
  • Unifies the business with the development team
  • Recognises problems cannot be fully understood or defined up front
  • Delivers Potentially Shipable Increments
  • Delivers business value early in the project
  • Mitigates risk
  • Reduces of the cost of delay

Fenwick has now implemented the Scrum framework for its internal Fenwick Gold Development Team, with Jake Edwards as the ScrumMaster. We have seen improvements already.

Scrum is not a project management framework or a project management methodology. It is a product delivery framework. Adam Waycott and I sat down and looked at the Scrum characteristics and process and decided it was relevant to the Design and Development phase of our projects. We decided to tweak our Implementation Methodology and coined the phrase Scrumplementaion.

Scrumplementation uses the values and characteristics of Scrum combined with traditional waterfall project management. The major changes were:

  • More Workshop preparation so we have a database setup with sample data and likely processes
  • Less Workshopping budget to avoid trying to solve every fringe case up front.
  • Walk-throughs instead of Pilots
  • Budget reduction in Workshops allocated to Walk-throughs
  • Internal Acceptance Testing renamed to Project Team Acceptance Testing

Several years ago we changed our methodology to introduce Mini Pilots, as we found that having 1 or 2 day-long Pilots right at the end of the development and data conversion phase, increased the risk of missed requirements and inadequate solutions. We also found that the key project team members were not getting enough exposure to the solution until later in the project, leaving less time for testing and inhibiting their ability to become Super-users in time for User Training, UAT and and Go Live Support. To change the culture around pilots we decided to use new terminology, now we use the term Walk-throughs and we ensure enough budget is allocated to make them effective.

Walk-throughs are a demonstration of a single process, enhancement or functional area, to confirm that it is complete and ready for user training. There are several sessions throughout the design and development stage, and each session may range from half an hour to four hours. The process is iterative, so if issues are found during a Walk-through, configuration, data and/or enhancements will be updated and the Walk-through repeated until the process, enhancement or functional area is considered done.

The Walk-throughs also act as a training session for the Project team members so they can complete detailed testing following the session. We then have a potentially shipable increment much earlier in the project, reducing the project risk, and creating Super-users who help deliver a much better solution.