In the early-mid 80’s, two people named Hirotaka Takeuchi and Ikujiro Nonaka wanted a better strategy for building products. They defined a flexible and all-inclusive strategy where the development team works as a coordinated unit to reach the common goal. They described this innovative approach as the “Rugby Approach”.
Scrum is not only one of the greatest inventions in the agile world but also one of the most popular frameworks. But with this popularity comes a great responsibility, which when abused, leads to controversies.
Scrum has not been immune to controversy, and its history of invention is a topic of frequent debate. Some professionals believe that Jeff Sutherland, John Scumniotales, and Jeff McKenna invented Scrum in 1993. And then there are others who vouch for Hirotaka Takeuchi and Ikujiro Nonaka as inventing Scrum in 1986.
While connecting the above dots, I have concluded that Hirotaka Takeuchi and Ikujiro Nonaka came up with the initial concepts of Scrum, including the word “Scrum” itself in their white paper, “The New Product Development Game.”
Sutherland applied the above concepts from the white paper and fine tuned it. Schwaber and Sutherland collectively presented their experiences during the OOPSLA 1995 conference. Subsequently, Schwaber and Beedle attempted to communicate Scrum through the first Scrum book Agile Software Development with Scrum.
As the Scrum community started growing, it was decided to create a platform to bring them together, which in turn leads to the birth of the Scrum Alliance (SA) and Certified Scrum Master (CSM) certification. However, controversies started brewing about transparency and the motive behind SA, resulting in the birth of Scrum.org.
The Internet is scattered with various theories and propositions of what Scrum is all about. Sutherland believes that Scrum is a framework with a set of best practices learned over fifty years. Ken agrees as well with this and gives a good analogy of comparing Scrum with playing chess:
The word “framework” means that much is not specified and must be devised by those using the framework. I equate Scrum to the game of chess. You can read the official rule book for chess. The moves, players, sequences, scoring, etc. are all specified.
There are people who argue that Scrum is a process but with the subtle difference that Scrum is not a defined process but an empirical process. This discussion does not stop here; someone has already argued whether XP and Scrum should be called either method or methodologies.
So, what is the Rugby Approach?
Have you ever watched a game of Rugby? The whole team has one goal – to move the ball towards the end-line as a collective unit. They keep passing the ball back-n-forth until they actually reach the end line.
Takeuchi and Nonaka felt that product development must be like a Rugby game where the team works as a collective unit instead of the traditional approach which can be compared to a “Relay Race”.
The Birth of Scrum
Two Gentlemen – Ken Schwaber and Jeff Sutherland can be considered the founding fathers of the modern day Scrum Methodology. In the year 1995, they both elaborated on the Scrum Concept and its applicability to software development and presented the same at the Object Oriented Programming, Systems, Languages & Applications (OOPSLA) conference.
Why Scrum is better
If you are an experienced Project Manager who is used to managing projects the traditional PM way, you may be wondering is Scrum Better? Are you?
I can’t really say Scrum is the Best Project Management Methodology because not all projects are the same. If you have concrete requirements which are base lined and would not change over the duration of a project, the traditional plan & build approach will work just fine. But, if you are building something new which the business has never seen, using the Scrum Approach would be much better because at the end of each Sprint, the customer is going to get a deliverable. Based on the customer’s feedback we can improve the product during the subsequent sprint cycles.
Let’s say, you are building a new product over a period of 1 year and during the User-Acceptance Testing Phase (UAT) the customer realizes this isn’t what he wanted. One year worth of development, cost and everything else is down the drain. Instead, if you had a delivery that happened at the end of the 1st month, the customer would’ve passed on his feedback immediately and we could’ve done course correction. Isn’t that a Benefit?
Because you don’t want to waste your time and money building a product no one will want to use or pay for. This is where MVP (minimum viable product) comes in; creating a product with the minimum set of product features that will give value to users, in order to test the concept and get feedback before continuing development.
The Scrum processes are very clear about the need to produce visible value in the form of working software on a regular basis. By delivering a product iteratively and incrementally (i.e. in sprints), we also maximize the opportunity for regular customer feedback and the return on investment.
So, how do we accomplish this?
Well, for a start we are split in teams of about 5-7 people each and those teams are cross-functional. This means that our teams have all the necessary skills needed to accomplish the work without depending on people outside of the team.
We also rely on self-organizing teams. This means there is no team leader who decides which person will do which task, or how a problem will be solved. Those are issues that are decided by the team as a whole, normally as part of our regular Scrum ceremonies.
We keep the team meetings to a minimum in order to optimize productivity, and also ensure an appropriate amount of time is spent without allowing waste in the process. Our ceremonies include:
- Daily Stand-up (aka Daily Scrum) – 10 min where each team member talks about what they did yesterday and will do today, and if they have any blockers
- Estimation meeting – the team gathers to discuss the requirements and estimate their size
- Sprint Planning – team commits to a certain amount of work at the beginning of the sprint and plans how to deliver it
- Sprint Review – at the end of the sprint, the team demos their progress to the stakeholders
- Sprint Retrospective – following the demo, the team discusses between themselves how to improve things next sprint