A point of view on SCRUM

Having worked in the industry for over 11 years, I have seen projects implemented in a number of different ways. In my current role I am working with an extremely detailed and rigorous project methodology that is based on Waterfall. While I am a certified Scrum Master, I think that marrying the best of agile and waterfall you will have a methodology that satisfies the development teams, our clients and project and programme management.

For me the fundamental difference between waterfall and SCRUM is selling products vs projects. While I am not promoting either methodology, it is interesting to consider and discuss the merits of each.

The following points describe the key areas that will help establish a high performance Scrum team:

- Estimates are provided by the team. Estimates are based on the teams ability to deliver.
- Team velocity is based on the current actual ability of the team.
- High performance teams, understand each other and work from project to project as a delivery team.
- Software is an art, more than a science. Ensuring software quality will inevitably take time. Working on software until it is right, trading off features is the right approach provided your client accepts that they may not get everything that they want.
- There is no leadership. One person is not responsible for driving the project to completion the team is.
- Assessing the delivery approach during a sprint retrospective, helps the team re-organize and optimize the delivery process.
- Sprints help organize the focus o f the team for the next period of the project.
- Having a Scrum Master removing impediments, allows the team to focus on delivery and not have to deal with issues that don’t add value to the project.
- Things change over time, on large projects it is difficult to estimate whether we will reach the 6 month target date. Scrum does not implement end dates, it lets the project take its course.
- Problems are detected earlier rather than later. The client gets to see the product regularly and does not test the product at the end of the project.
- Having the team report directly to the Product Owner means that they are no longer shielded by the project manager. This enforces accountability.
- Teams are self organizing, this lets team members focus on the areas that they are interested in.
- Using a backlog to identify features and requirements allows the team to have visibility on what is going to be delivered in the lifecycle of the project. Scrum promotes visibility to all stakeholders.
- Daily scrum meetings allows the team to refocus their effort daily and each team member must report on what they achieved, what they are going to achieve and what impediments they currently have holding them back.
- Producing code early on in the project allows the client to start getting the benefits of the product much sooner than in a traditional waterfall methodology.
- There is an inherent increase in the ability of the team to cross skill and grow their knowledge through osmosis and the collaborative nature of the Scrum project.
- When a problem is found, the entire team is stopped to focus on resolving the issue, while this stops the entire production line, the team learns together and the problem is resolved much quicker than when one person focuses on the problem.

The following observations help clarify the role of SCRUM:

- There must be inherent trust between the product owner and the team.
- Scrum teams are typically between 4-9 people. On a large project you will need to have multiple teams, with multiple product owners and SCRUM masters .
- Scrum aims to keep the development team happy and productive removing the unnecessary structure and rigor that stops them from producing code, which ultimately adds the real business value.
- Scrum implies that software requirements are emergent, meaning that as you go you will discover new requirements. Your client must understand that you are going through a discovery process. Discovery takes place for the duration of the process and not like in waterfall, up front.
- A scrum master is a servant leader person. They need good people skills and do not take a leadership position within the team.
- Scrum aims to make the project more visible, notifying all of the stakeholders of the teams velocity (ability to deliver). Clients must understand that if the team mix is not right, the velocity will be low. New teams will also have a low velocity. Teams that work together on multiple projects will have a much higher velocity.
- Teams must be groomed over time.


The following points are where I see challenges in using Scrum on some of the projects that I have worked on:

- Teams must be co-located. Scrum relies heavily on human interactions, collaboration and knowledge sharing. This will not suit the nature of distributed projects.
- Relying on extensive human interaction means that information is not always documented.
- Organizing work in sprints and starting development right away, removes the ability of the team to focus on research. Going directly to code before understanding the design options available. This approach assumes that you have an experienced and mature team that understands the application domain. This will work well in in-house IT departments where people work in the same environment for a prolonged period of time.
- Re-factoring comes at a cost. Waterfall reduces the amount of refactoring by doing all of the planning and design upfront.
- The project is not outcomes based, this means that the end product is not known upfront and the client only says its done when they are satisfied that they have what they want (which may or may not entirely be what they had initially envisioned). The client can change the scope during the project and on fixed price contracts this is detrimental to the project.
- The small team size, 4-9 members will mean additional resources to facilitate multiple teams. Additional Product owners and scrum masters.
- Each team member is expected to know what they are doing from day one. Coding starts as soon as possible.
- There is a huge emphasis on face to face communication while this is good for the team to bond, the knowledge is not recorded. If people leave that knowledge leaves. The low focus on creating documentation means that you don’t have anything to go back to when there is a dispute with the client, hence the inherent trust with the client that is a requirement.
- Scrum implies that the team will be happy and that attrition is naturally low. Attrition is a reality and the knowledge that is lost during a project, must be recorded somewhere, specifically on large complex implementations.
- There are huge contractual implications if the understanding of the team and the client are vastly different. Scrum will work in an organization where the team understands the application domain and requirements. Typically these type of resources belong to in-house IT departments.
- Scrum assumes that the team will do what is required to deliver the product, including business analysis, design, testing and coding from day one. While the analysts and designers have not yet uncovered the actual design, the coders will not be able to start and if they do there will be inherent re-work.
- There is a lot of bargaining and negotiation with the client as to which functionality is delivered first, typically our clients expect everything to be completed. SCRUM projects must have the ability to push back and the understanding from the client that this is part of the process.