Welcome back! This is the third and final post where I discuss how we handle software projects at CSW Solutions. It’s time to talk about complex projects. Part 2 of this series mentions that complex projects are those where the technology and/or the requirements for the project are unknown.
Our past articles also covered that these projects needed to be broken down into smaller pieces so they can be developed and implemented. Now, we need a proper methodology for these type of projects. In summary, we need a methodology that can handle “change”.
The problem with uncertainty in technology and requirements is the introduction of changes more often than anyone would like. This is just a natural consequence of uncertainty and should not be considered a barrier to develop the project, but both the client and the development team need to be aware of it; instead of avoiding it, they all need to embrace it.
When we know changes are going to happen, we need to manage the project using a methodology that is aware of changes. There are numerous options for this, and they are all categorized under the single name of “agile methodologies”. The agile methodology we use at CSW Solutions is called Scrum.
Before continuing with our discussion, I need to emphasize that this short post is not meant to be a full description of everything that happens in a software project using Scrum, yet it will highlight the most important aspects of the methodology, so that you can understand how it is applied and how we can ensure with reasonable probability that the project will succeed.
When using Scrum for a project, we break the project in small time increments called “sprints”. Each sprint has a defined scope and duration. The duration is typically 2 weeks but this can be adjusted depending on the needs of the project.
The scope determines the features of the project that will be developed during the length of the sprint. Also, the scope must not change in the middle of the sprint; it can only change after the sprint is over. This is very important because while changes are allowed, they are only allowed in between sprints. These short periods of work also have the advantage that if something goes wrong, it will be identified quickly and the monetary loss would be minimal (should there be one).
In each project that is managed with Scrum there are specific roles that need to be filled:
Product Owner: Typically played by one person from the client side. It has a key mission, which is to establish clear requirements for the development team. The requirements are listed in a document called the “backlog” where they are prioritized so the development team knows what they should be developing next. A product owner is also responsible for changes in scope.
ScrumMaster: It’s like the orchestra director. The ScrumMaster’s responsibilities are to ensure that the project backlog is ready and current so it can be delivered to the development team, to facilitate all communications between the product owner and the development team, and do everything in his/her power to remove all obstacles that will prevent the development team from completing their work. This role comes from our side.
- Development Team: In charge of developing the project. That’s us too!
Given that the project is complex, communication is essential for its success. Scrum establishes that during each sprint, a number of meetings must happen to ensure any changes or problems are known and addressed properly.
At the beginning of each sprint, a two-part meeting called Sprint Planning takes place between the development team, the product owner and ScrumMaster (and anyone else who can provide value to the project). In this meeting the project backlog is analyzed and a new document called the sprint backlog is created. This meeting should not last more than 4 hours.
The sprint backlog is created by the development team and defines what can (and will) be delivered at the end of the sprint. Note that it is not the product owner nor the ScrumMaster who defines what will be worked on, but the development team. This might look strange, even risky, but doing so has its roots in the belief that empowering the development team will have a much better effect in the deliverables than imposing what needs to be done. In the sprint backlog, all tasks are broken down to chunks of 2, 4 or 6 hours. If a task will take more than 8 hours, it should be broken down.
Every day during the sprint, at the beginning of the day, the development team, the ScrumMaster and –optionally– the product owner meet for no more than 15 minutes in what is called the Daily Scrum. During this short meeting each member of the development team take a turn to express what was done the day before and what will be done during the day. It also must be stated what issues or problems he/she is facing that will prevent him/her from completing the work.
It is the job of the ScrumMaster to take note of those issues and problems, and after the meeting start working on eliminating or minimizing them so the developers can complete their tasks. Also note that during this daily meeting only the members of the development team will speak. This will keep the meeting short and concise.
At the end of the sprint, a final meeting called Sprint Review takes place; in it, the development team presents the product owner the deliverables of the sprint. After this presentation, the developers also have a meeting called Retrospective. A retro is an analysis of the sprint, where they expose the challenges they faced, and how they overcame them (this is similar to a post-mortem analysis), so everyone benefits from the experience.
Once the sprint is over, a new sprint starts and the whole process begins again. When does it finish? When all the items in the project backlog are completed, which means the project is done.
This is at a glance the methodology of Scrum. This is how we work at CSW Solutions to help you manage your complex software projects so they can be completed, even in high levels of uncertainty and change. Next in our agenda is a case study, so stay with us.