Waterfall vs Agile approach: Scrum Framework and best practices in software development
Common Problems in Traditional Project Management
In traditional project management common problems have been identified as late delivery, being over budget or the wrong outcome being delivered. It is particularly disappointing for a client to receive an end-result which is very different to the one asked for and envisioned.
Firstly, we are going to examine the ‘Waterfall Approach’, one of the oldest methods of software development. This approach is sequential usually results in starting from scratch. The requirements are known and each stage is signed off before the next one commences. For this method extensive documentation is required as this is the primary communication medium.
The steps followed are:
- Analyse
- Design
- Build
- Test
- Deploy
In theory, this is a perfect approach given that all the requirements are fully understood and not complex.
The Agile approach is based upon the 3 steps of outline, analysis and design plan. There is a working solution in each integration, and each is reviewed and refined regularly.
Waterfall vs. Agile- which one is best?
Whilst both approaches have pros and cons. The Agile approach is often better at meeting customer needs and is more interactive. Following this approach the features are variable, but the quality, time and cost are fixed. What differs in the Waterfall approach is that whilst the features are fixed, in contrast the time and cost are variable.
In regards to feature prioritization, in the Agile approach features are prioritized and issues are solved according to priorities, this increases funding efficiency and prevents total failures. However, in the waterfall approach features are not prioritized, which leads to either complete success or failure, thus, often resulting in starting from scratch.
Be Agile
‘We all succeed or We all fail!’
‘Go the distance as unit passing the ball back and forth’.
(Takeuchi Hirotaka, 1968)
This approach focuses on an outline requirement rather than detailed requirements, solution and plan.
Baseline Plan (3–9 months) vs. Commitment Plan
Where does your project fit?
Is it Empirical (based on observation) or defined?
The Agile Manifesto
In February 2001, 17 software developers, including Kent Beck, Mike Beedle (author of the first book and earliest papers about Scrum) and James Grenning met to discuss lightweight development methods. They published the Manifesto for Agile Software Development to define the approach now known as agile software development. Some of the manifesto’s authors formed the Agile Alliance. This Alliance is a global non-profit organization dedicated to promoting the concepts of Agile software development as outlined in the Agile Manifesto.
So what is the theory behind their manifesto?
According to the Agile Manifesto adaptability and individual customer needs are key. Certain things are prioritized. For instance, individuals and interactions over processes and tools, working software over comprehensive documentation and customer collaboration over contract negotiation. In addition, responding to change is seen as more important than following a rigid plan. Whilst all items are recognised as having some significance, the later items are given more value and hence prioritized in the approach. The Agile manifesto was influenced by the scrum approach.
Find out more at: http://agilemanifesto.org/
Agilebut & Scrumbut Syndrome
‘Scrum’ is a framework of how you would use the Agile approach. Now we will examine Agilebut syndrome and common problems that often arise when in use.
Issues arise in cases such as ‘We use Agile but…’
- ‘our roadmap is fixed and a year old’
- ‘we don’t have a release plan’
- ‘we create a detailed plan or architecture’
- ‘we manage the team tightly’
- ‘we don’t prioritize features’
- ‘we know our requirements, no need to talk to customers’
- ‘we don’t do planning meetings’
Here, we will explore 4 common problems further…
Common problem One: There is no product owner or the organisation has multiple product owners
Case 1: There is no one in the organization to prioritize features or no prioritization methods
Case 2: The priority set of one Product Owner does not match with the priority set of another Product Owner, as they have a different understanding or what is important
Common problem Two:
Sales and Marketing teams or Management often make promises to customers about features or make assumptions that features will be delivered in a certain time. As this is not reality and is not fulfilled, individuals tend to blame the development!
Common problem 3:
This problem arises when it is thought that the agile approach can be followed without getting any customer feedback. Despite creating a perfect technical product, if it has no value to the customer it is useless. The customer is predominantly the most valuable team member.
Common problem Four:
For those who think it is necessary to stick to the plan in order to be successful. This creates problems, because iterative development is well planned but is planned in a different way to waterfall. The plan needs to be flexible and adapted along the way in order for the Agile approach to work.
Scrum Framework
Scrum is the most widely used agile methodology, popular with many software development teams.
Why is the scrum approach so widely used?
It is a wrapper for existing engineering practices and does not strictly define principles or how to guidelines. A benefit is that it is scalable; it can be scaled from a single team to an entire organisation. Scrum is the lightest of all Agile methods (AUP, Lean, XP etc.) with five core values (see below) and three roles:
· Commitment
· Focus
· Openness
· Respect
· Courage
Its role is to detect and remove anything that gets in the way of developing and delivering products.
To meet the Agile goal of delivering new software capability every 2–4 weeks; there is a concept of multi-level planning:
Release Plan> Typically every 3 to 6 months
Sprint Plan> Typically every 2 to 4 weeks
Daily Plan> Daily
The Roles of Scrum
The required roles of scrum are split into three parts; the scrum team, product owner and ScrumMaster. Firstly, the scrum team focus on the how, who, timing and delivery. A scrum team (size 7 +2) is self-organising, and cross functional with no pre-determined roles. It is responsible for self-organising tasks and committing to the work. In contrast to many teams, in a scrum team no one assigns stories or tasks to team members, the team must self-organise. Authority is given to whatever is needed to meet a certain commitment. Therefore, it is up to the team to take initiative, focus on solutions and co-operate. It must be a self-directed, motivated and multi-skilled unit.
The Product Owner focuses on the what, when, signoff and vision. They define the features and write user stories. Responsible for the development schedule and prioritizing Product Backlog, they also decide whether to accept or reject stories. This role can be summed up by the acronym ‘Dark’- standing for ‘Desire’, ‘Authority’, ‘Responsibility’ and ‘Knowledge’ (the knowledge being both Business-orientated and Technical).
The ScrumMaster, often referred to as the coach, coaches the development team and is responsible for productivity. They are responsible for facilitating Scrum ceremonies, and are the ones who establish and enforce Scrum rules, and are likely to be primarily responsible for the success of the process. The ScrumMaster shields the team from noise and removes obstacles, they enable close cooperation across all of the roles.
Scrum Artefacts
Scrum Artefacts consist of product backlog, sprint backlog and burndown chart. The product backlog is a continuously evolving queue of stories created by the Product Owner with input from other stakeholders. It is owned and prioritised by the Product Owner. The sprint backlog is the list of tasks required to get the agreed ‘Stories’ done. It accepts or rejects these stories. Thirdly, the burndown chart shows the estimated amount of effort remaining, as well as demonstrating the actual vs. ideal progress. The burndown chart should be publicly visible.
Pigs & Chickens!
The Team, Product Owner and ScrumMaster are known as ‘pigs’ because they are committed to Sprint. Other stakeholders are referred to as ‘chickens’ as they are not committed to the sprint goal.
Scrum Routines
Ceremonies are defined as follows:
Daily Scrum Meeting (Everyday @ 9:00) for 15 minutes
During this meeting 3 questions are asked:
- What did you do yesterday?
- What will you do today?
- What is blocking your work?
Problems arising are solved outside of the meeting, and it is not a reporting session!
Sprint Planning (held on the last day of sprint in the afternoon) for a maximum of 8 hours
This is timeboxed to 4 hours + 4 hours. Priority items are explained by the product owner, the overall sprint is agreed. The team predicts and commits to what it can get “done”. The result is an agreed Sprint Backlog. In the second part of the meeting, the team decomposes the sprint backlog items into tasks. Tasks are estimated by the team; they need to be complete enough for the team to make a commitment.
Collectively, the Scrum team and the product owner define a sprint goal in the planning meeting. It is usually one sentence of descriptive text. The success of the sprint will later be assessed during the Sprint Review Meeting against the sprint goal.
Sprint Review & Retrospective
The sprint review is also held on the last day of sprint @10:00–11:00, the retrospective is essentially a look back or reflection and lasts for a maximum of one hour
Here in the sprint review, achievements are acknowledged, the ‘chickens’ are invited to the review. A demo of everything that has been done in the Sprint takes place, and the product owner signs off the sprint of the tests are okay. The sprint retrospective takes place at the end of the sprint before the planning meeting (sometimes referred to as “poker”). It is a short workshop session, designed for the team to review lessons learnt and discuss actions for the next Sprint. There are no ‘chickens’ involved in the retrospect (with the exception of the end of release retrospective). An action plan is made at the end of the retrospective meeting.
Meaning of the term ‘Done’. If something has met the sprint goal, has passed the acceptance test and has met policies and procedures, then it is done.
What is ‘Spike’?
Spike is a learning activity. Spike is something that you do not understand in advance- when you do not know what exactly it is or how to implement it. It is timeboxed, you will need to limit how much time you will spend researching.
User Stories
These user stories need to explain the who, what and why (including functional, non-functional and non-software features). Sprint stories should be doable in 1–5 days. If it takes more than 5 days (compound story), decompose it. For Complex stories (if no way to split up) — spike it as not enough is known. The Product Owner can decompose it with stakeholders. Back of the card- a high level acceptance test posed in the form of questions (not detailed tests) — testers should come up with these.
Can you cancel a sprint?
If sprint is cancelled actions are required. Firstly, a retrospective meeting is held to discuss the shortcomings and what went wrong. The sprint is stopped, and a re-plan is formed. The team wait for the iteration to end and then the sprint is started again.
Best Practices?
It is thought to be best practice to combine approaches. For instance, mixing Agile Management Practices with Scrum Framework and merging with XP and Lean engineering practices is recommended for the best outcome. Scrum can customize up rather than customize down. XP consists of coding standards, pair programming where possible, test driven development, continuous integration and collective ownership. Lean is formed of several guiding principles. These include amplifying learning, allowing the team to make decisions to empower them and seeing the software as a whole, rather than in parts. Building integrity is a fundamental principle of lean, the system must work the way the customer expects it to. The delivery should be as early as possible. In contrast to decisions, which can be made as late as possible, so decisions are based on facts rather than assumptions. Thus, the lean approach shows us to ‘Think big, act small, fail fast; learn rapidly’.
