Today I will not be discussing a new technical framework or a design pattern, today I decided to talk about another very important aspect in software development, product development methodologies. No matter what the product is, being it software or not, some sort of a development strategy has to be applied in order to have your team workefficiently in reaching the desired goals. In this blog I will discuss some of the older development approaches used in the past while explaining the reason behind the shift to more agile techniques such as SCRUM.
the good old iterative approach
Most of us still remember the good old waterfall approach and while it is not as popular these days with most of the companies as it was a few years ago, some of the bigger companies still opt to such a methodology when it comes to building large products with a very clear plan and vision. Choosing a development strategy depends much on a number of factors such as the team size, goals, requirements change rate and the industry you're working in. If the requirements of the industry are rapidly changing than an approach such as the waterfall model might not be suitable due to its nature of defining the specifications and requirements at an early stage with a very low threshold for change after the design and specifications have been approved. In the waterfall approach most of the time is spend in the initial design and specification stages where all the neccesary preprations are made to cater for all the needs which might arise during the development stages. The main problem with the waterfall approach is that it does not give the team the opportunity to learn more about the product while it is being built. How many times have you started working on a project and you realize half way through that some important features are missing or should be alterted to suit the needs of the end users? How many times do project managers and product owners realise that a project has been dragging on for too long and due to unforseen circumstanses, the purpose of the project has become absolete? Throught the years, the IT industry has emerged as one of the fastest paced industries in the world and getting the requirements right from the very beginning is very expensive and also risky.
...moving towards an adaptive philosophy
The short comings of incremental software development methods and the lack of ability for the development teams to adapt to enviromental changes concieved the idea of an adaptive approach where the development team is able to adapt to new changes, goals and requirements established during the development lifcycle. The idea of agile development revolves around the individual team members and interaction amongst them rather than the specific processes and tools used; it revolves around the idea of having a number of 'working' features rather than comprehensive documentation; it revolves around constant feedback from the users or consumers rather than an intial contract negotiaition and most importantly it revolves around the teams ability to respond to changes in a timely manner rather than following a strict plan.
SCRUM and Agile techniques
SCRUM is a term intially coined by Takeuchi and Nonaka in a study conduced back in 1986 where they compared high performance, cross functional teams to the Scrum formations used in Rugby. SCRUM focuses on the team's ability to adapt new requirements while continously delivering 'complete' micro features. Working on small chunks of features helps the team manage their resources better while staying focused on delivering functional chunks of software rather than negotiating specifications though analysis and documentation. It encourages creativity and allows the team to easily respond to new changes set up by the business requirements. It focuses on building what is needed most at this point in time through the collaboration of both the development team and the product owner prsenting the business requirements.
There are three main roles within every SCRUM team:
Product Owners
Product owners are responsible for mantaining the 'product backlog' which is basically a list of features known as user stories prioritized and organizsed based on the business requirements.
Development Team
The Development team(s) is responsible to build what has been committed for the sprint duration (a period of time during which the team will work on a set of features) and also to estimate the work involved for the product backlog items helping the Product owner making better decision when prioritizing the work to be done.
Scrum Master
The job of the Scum Master is to facilitate the Scrum process. Making sure that the Scrum process is followed and the team is able to work as smoothly as possible with the minimum number of distractions. It is the Scrum Master's role to shield the team from any distractions during the sprint while helping all the team members follow the Scrum process as effciently a possible.
Befor I go through the Scrum process and explain how a number of features are tackled in Scrum I would like to explain a few other important terms which you will see quite often in Scrum terminology:
Sprint
A sprint is a defined period of time during which the team can work on an agreed number of features. Depending on the team size and the specific project you're working on a sprint is usually between 2-4 weeks.
User Story
A user story is a way on expressing a feature or a number of features that satisfy a functionality meaniningful to a user. To make sure features are rich in value to our user's requirements, features are expressed as user stories for example "As a User I would like to be able to login using my email and a password" or "As a user I would like to download a list of movies and export it to a file".
Story Points
Story points are a unit measurment used to measure the effort it takes to solve a particular User Story. It does not nessecarily convert to hours or day, its just a way for the team to be able to indicate how much work is involved and give the product owner a better vision of how long it can take the team to complete that particular user story.
Product Backlog
The product backlog is simply a list of user stories managed by the product owner. Any business need is translated into a number of user stories and added to the product backlog. During sprint planning meetings, the team will measure and discuss the difficulty of each and every user story and the product owner will then update the product backlog accordingly.
SO how does it work
1) Business Request
So how does SCRUM work and what makes it so effective? As you've probably guessed, the whole process starts from a business request. The Product owner together with the Scrum Master (if required) will split the business features into a number of user stories. The product owner in the mean time will prioritize the user stories depending on the business requirements.
2) Sprint Planning
Every sprint begins with a Sprint Planning meeting. During the sprint planning, the SCRUM team will meet up to discuss the items on the product backlog, re evaluate if neccessary and commit to a number of user stories. It is common practice that the team who will actually work on the user stories carry out what is commonly referred to as 'Poker Planning'. The team will basically tackle every user story one at a time and assign it a number of story points. The team will iron out any differences in story point for any user story and without the intervention of the product owner will decide on a number of story points for each user story in the product backlog.
This will give the Product Owner another chance to reprioritize the product backlog knowing the effort it takes for each and every user story. After the prioritization takes place the team will then commit to a number of user stories from the product backlog. The team are essentially committing themselves to complete those user stories by the end of the sprint and presenting the owner with shipp-able features at the end of the sprint.
3) Sprint
The team will then start the sprint each of the team members committing to a number of user stories. The Scrum Master can help the team split the user stories making sure that all dependencies if any are tackled at the earliest so as not to slow down the team performance.
4) Daily Scrum meeting
Every day, the team will carry out what is referred to as the "Daily Sprint Meeting". During this meeting each and every member should discuss the following:
- What they have been working on yesterday
- What they plan to work on today
- Any obstacles encountered
The Scrum Master should take a note of all the obstacles encountered and make sure to monitor the progress on each and every user story so as to help the Product Owner understand where the team stands in terms of progress. The Scrum Master will usually use the "Sprint Burndown" chart to monitory the team progress. The Burndown chart is essentially the total number of story points remaining on the sprint against the number of days remaining for the sprint such as the one shown below:
Several tools such as Visual Studio Online will update the burndown chart automatically given that each team member gives an update on each task and user story daily.
5) Sprint Retrospective
At the end of the sprint, the team will meet up with the product owner to discuss the progress done and present the shippable features produced during the sprint. The product owner will examine the features and update the product backlog from the beginning. It also good practice that the team uses this opportunity to discuss any general blocking issues or problems the team encountered during the sprint. The Scrum Master is responsible to take note of all the issues and work on solutions so as to make the team more efficient in the coming sprints.
6) Repeat the Process
That is it! The process is then repeated untill the product backlog items are exhausted.
The Scrum Process can be easily explained using the following diagram:
I hope you have a better understanding of what Scrum is. There are other situations and benefits which I did not mention in this blog but I could keep going forever. I have been using Scrum for quite a while now with different companies and different team sizes and from my experience I can say that Scrum is a very efficient and effective methodology as long as the few Scrum rules are properly followed. In some cases, depending on the particular scenario, one may need to tweak some of the variables around however, the 6 steps I mentioned should always take place in one form or another.
Thanks for reading and as always, if you have any questions do not hesitate to ask.
Shaun