Scrum Project Management Approach

So you convinced your management to give you money for your modernization project? Now you will need to deliver! How do you make this happen?

When you read the article written by Paul Conte about the ‘Top 10 reasons application modernization projects fail’ you see that four out of the ten reasons for failure have to do with the way the project is managed, I quote:

1. Not following a business-driven approach to goals and priorities
2. Not delivering real value early and often
3. Not using an iterative and incremental project structure
4. Not getting the right people on the bus and in their right seats

My experience is that the Scrum management approach is a good project methodology to help you deal with these challenges.

The term Scrum originally comes from the sport rugby. The team tries to run a certain distance by working together and passing the ball back and forth. The team needs a certain amount of successful scrums to win the game.

In your legacy application modernization project you can use the same approach just like the IT team of Bemis Manufacturing did. I will not elaborate on the complete Scrum project definition – you can find it at https://en.wikipedia.org/wiki/Scrum_(development) – but I will highlight some the advantages of this methodology.

A typical Scrum project has various roles:

• The Scrum master (project manager) this the one that controls and measures the complete process.
• The product owner is the one that represents the business.
• The ‘Team’, a group of people with different skills that might be needed during a “sprint”.

The product owner and the scrum master write down the expectations and goals that need to be achieved in the project this includes all the (prioritized) deliverables. It is up to the team to determine how ‘heavy’ each deliverable is and which disciplines are necessary to realize it.

All the participants are now going to plan the sprints, a certain amount of time in which an amount of deliverables will be realized, for example four weeks.

During a sprint the defined deliverables must be:

• built
• documented
• tested
• and last but not least, at the end of the sprint they must be in production!

The participants put an amount of deliverables in a sprint based on the weight and priority.

When you put deliverables with a high priority (= business need) in the first sprints you will win confidence and gain popularity with the business.

Because of the short iterative delivery cycles there will be all kinds of advantages for the project.

The business is part of the team. They are likely to see deliverables within a few weeks after the start of the project, and they will be able to validate the deliverables.

• Business needs or rules that were not understood correctly are discovered almost right after the deliverable was build. The ink of the source code is still wet so the effort to correct the errors is relatively small.
• The product owner can make his/her colleagues enthusiastic about the delivered pieces and strengthen the foundation of the project.
• The close relationship with the business makes it easier to really understand what the business needs. Having a better understanding of the business will enable you to make useful suggestions about how to make their work more efficient and easier.

In a ‘traditional’ project, the team usually stays the same during the entire duration of the project. In Scrum development you work in sprints and that helps you to be more selective about the people you need for a certain sprint.

• The integration specialist is not necessary when you have a sprint that only has the user interface as a deliverable. So you can hire specialists more efficiently and probably save some money in that area.
• You can also determine if all the ‘seats’ are taken by the right persons pretty fast. Because the deliverables are relatively small, it is much easier to do quality assurance audits and determine if there might be people in the team that do not deliver the quality that is expected.

When a sprint is finished, you should have working deliverables that have been validated by the business. End-users will be able to work with these deliverables in a production environment.

In addition to the project management advantages in a Scrum environment, you will also be alerted much sooner in case technical decisions need rethinking. For example, it can be that an architectural decision is causing serious performance issues in a ‘real life’ production environment, that didn’t occur in the test environment. In a ‘traditional’ project it can take months before such issues are noticed, in a Scrum project it usually only takes a few weeks.

Like all methodologies it is a case of interpreting the theory. Depending on the size of the project and team, you will need to determine how strict you want to follow the methodology. For a project with four sprints and two team members, it might not be needed to have a dedicated scrum master, but it can still be very useful to define sprints.

These days requirements change fast and the business needs quick deliveries to keep ahead of competition. Scrum is forcing all the stakeholders to make it happen together and share the responsibility.