The Tutorial is your first guide to Scrum & Agile Software Development, and the purpose is to cover maximum Scrum related concepts, identify problems with their possible solutions and clarify the misconceptions. If you have any related questions/queries and want to be answered, don’t hesitate to put in comments area, I’ll try to answer at the earliest.
Let’s dive into it….
- What is Agile?
- Agile Manifesto?
- What is Scrum?
- Scrum Vs Waterfall Software Development
- High Level View of Scrum Framework
- Common Issues during Transformation to Agile Software Development
- Scrum Questions and Answers
Agile is a software development methodology/Project Management approach that focuses on delivering incremental business value to customer throughout the project as compared to traditional project management where value comes at the end of the project.
In traditional/waterfall approach, for years, we have been giving value to processes, writing comprehensive documentation, following a strict and unchanged plan, negotiation with customer over an agreed contract (undoubtedly those are important to some extent), but Agile value more to items on the left side. Check out below:
Under the umbrella of Agile methodology, we have multiple frameworks including Scrum, Kanban, Scrumban, XP, Agile Unified Process (Agile UP) and more.
SCRUM is one of the most complete and widely used framework. Below Graph provided by VersionOne indicates over 70% of the respondents practice Scrum (58%) or Scrum/XP hybrid(10%).
Waterfall approach has many problems due to its sequential behavior (working and completing each phase in order), it’s difficult to accommodate customer requested change if a process is underway. And we know for most of the businesses today, requirements are not stable and it keeps on changing. Using waterfall approach, we deliver Software/Product at the end of the project as a Whole/Big Bang.
As compared to Waterfall way of developing software (where we are doing all above things but ONE at a time and deliver the software as a whole at the end), in scrum, all the time we keep doing a little bit of all above (requirements, design, code, test & deploy) and deliver incrementally (small piece of potentially shippable software product i.e. an increment) and small iteration i.e. a sprint.
That’s certainly results in:
- More collaborative environment – each software increment is presented to customer and other stack holders to get feedback.
- Happy Customer – It’s always easy to accommodate customer feedback (as per priority) in upcoming sprints making more engaging and happy customers.
- Avoid Surprises – delivering small increments in small iterations certainly reduces the risk towards the end of the project.
- And many more…
Scrum is a framework where we can employ various processes and techniques to build softwares/products. Following is a high level view of scrum.
Scrum organizes the set of techniques and practices into 3 major areas including Roles, Events/Ceremonies and Artifacts. Let’s discuss/understand each one by one.
- Scrum Roles
- Scrum Events/Ceremonies
- Scrum Artifacts
Following are the key responsibilities of a product owner.
- Maintaining Product Backlog – Adding Features / User Stories.
- Express and Prioritize PBI (Product Backlog Items).
- Finalizing Release Date.
A Scrum Master must be doing following activities:
- Facilitate Team and remove impediments.
- Protect the Dev team’s time from outside disruption.
- Implementing/Enforcing Scrum Values and Practices.
- Coach Scrum Teams to be more productive.
- Takes an active role in mentoring and coaching teams related to the flow of work.
- Help Product Owner in maintaining Product Backlog.
Development Team is a self-organizing team of 3 to 9 members.
- Cross functional – Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
- Empowered by organization resulting synergized output (in terms of potentially shippable increment and team efficiency/effectiveness).
What is a sprint in Scrum? A sprint is the time allocation that is given for work completion (i.e potentially shippable product increment) and submission for review.
- Sprints are commonly 2-4 weeks long, although it can also be as short as a week.
- Work completed during a sprint should be demonstrable and shippable to production for customer.
- All scrum ceremonies including Daily Scrum Meeting, Sprint Planning, Sprint Review and Sprint Retrospective, along with development and testing are performed during the execution of a sprint.
- Product Backlog Grooming sessions are also done during the sprint, so that we should have groomed PBI (Product Backlog Items) those can be picked for upcoming sprints.
- Scrum under the umbrella of Agile accepts change, but change during a sprint is never encouraged. Scrum expects the team be clear about the sprint goals.
- There is no break between sprints; new sprint starts right after completion of previous sprint.
- It’s highly recommended to have a consistent sprint duration through out the project.
Daily Scrum Meeting:
Daily Scrum is a regular daily time-boxed meeting (maximum 15 minutes) by team members to discuss the sprint work progress and issues/impediments (if any). It’s not a status update given by individual team members to product owner or scrum master.
- Development team members normally discuss about their work from the last stand-up and then share what he/she is going to accomplish during the sprint before the next stand up.
- Also, discuss about any impediments/issues /dependencies etc. that can be a risk for the work.
Sprint Planning is normally done as the very first activity while starting a new sprint. It’s a time-boxed meetings where product backlog items are discussed to find out that how and what can be delivered as part of increment for upcoming sprint?
- Whole scrum team (Product Owner, Scrum Master, Development Team) participates.
- Clearly determining the upcoming sprint goals.
- Creating upcoming sprint backlog.
Sprint review is a collaboration event between scrum team and stakeholders at the end of the sprint, where development team showcase the work they have completed (i.e. potentially shippable increment).
- 2 hours event for two weeks sprint.
- development team demonstrate the actual increment done (not a POC).
- As per the agreed DoD (Definition of Done), Product Owner validates the product increment and discusses the updated status of Product Backlog.
- As per the customer or other stakeholders input, Product Backlog is prioritized that forms the basis for choosing works for following sprint.
As we know that Scrum is founded on empiricism and three pillars of empirical process control are transparency, inspection and adaption. Retrospective is the final team meeting in sprint that brings an opportunity for scrum team to inspect what is done in last sprint and adapt what is really working.
This event is attended by the Scrum Master and the development team (Product Owner can participate as a silent observer). Discussions are made on the overall team performance during the Sprint. Normally following 3 questions are discussed:
- What we did good as a team?
- What can be done better?
- What is the plan for improvements?
|Events/Ceremonies||2 Weeks Sprint||4 Weeks Sprint|
|Sprint Planning||4 Hours||8 Hours|
|Sprint Review||2 Hours||4 Hours|
|Sprint Retrospective||1.5 Hours||3 Hours|
|Daily Scrum||15 Minutes||15 Minutes|
The easiest way to look at the Product Backlog is a To-do list that features work items (Product Backlog Items) represents stakeholders needs that is valuable to the business.
- Product Owner is responsible for managing and prioritizing Product Backlog.
- No work will be assigned to development team directly unless it’s part of Product Backlog as PBI (Product Backlog Item).
- Items in Product Backlog are normally referred as User Stories represents customer/stakeholders needs. Sometimes we have technical stories as well to fulfill specific needs.
Sprint Backlog is a plan for delivering the product increment clearly representing sprint goal, including set of PBI (Product Backlog Items) picked for sprint. It’s basically a subset of Product Backlog chosen for a specific sprint.
- Development Team owns the Sprint Backlog.
- Development Team members choose work items themselves, product backlog items are never assigned.
- Sprint Backlog is updated daily to track progress.
This is the sum total of all the product backlog items that have been successfully carried out during a sprint in addition to previously completed increments. Although the product owner is the one responsible for dictating the release of an increment, it is the duty of the team to ensure that all the things listed in the increment are ready for release.
Agile is not just a different approach for developing software/products but it talks about changing the mindset and organizational culture for development, and that’s why, it faces a lot of resistance.
Even the organizations willing to use Agile for developing software/products, show much resistance in adopting it in it’s full essence. Many organizations just start using any of agile framework’s ceremonies and defining few roles considering them to be fully agile. But these organizations are not taking full benefits of Agile as the mindset behind it, is not changing.
Most of the issues are due to traditional mindset (we were working with for years). So, if we identify/understand the following issues and eliminate it by using the right approach, it will help us to benefit agile in it’s true essence.
- Water-falling the Sprint:
Problem: Executing the sprint in waterfall way (results in improper team utilization with no potentially shippable item produced). Starting all stories together, so developers are busy but working alone, and testers have no or very less work at the start of the sprint. Developers completing the work almost at the end of the sprint. In this way, testers are Free (or less work) at the start of the sprint but lot of work at the sprint end.
Solution: Instead of doing the same sequential way (starting all Items together) as we used to do in traditional Waterfall, we should break the work in smaller chunks and should deliver testable items as early as possible. That will produce more potentially shippable items earlier in sprint and also will have less surprises at the end of the sprint.
- Follow-up on Retrospective:
Problem: Good Retrospective is key for improvement and real change, but many organizations implementing agile will not be able to see a visible change even after multiple sprints. Reason is, in many cases action items during sprint retrospective are either not identified or even if identified, not properly followed or reviewed in subsequent retrospective meeting.
Solution: Any issue identified during retrospective should have a corresponding action item and it must be noted and have an assignee (also referred as an nominee or ambassador). Nominee’s responsibility is to follow through it during the iteration, and ensure respective action taken to fix the problem. Finally updating the team in following retrospective meeting. This is also referred as Ambassador technique.
- More will follow soon….
Traditional Project Management is command & control approach where Project Manager directs the team to get the work done. He manages the team and assigns the tasks along with handling customer end.
On the other hand, Scrum Master doesn’t direct the team but he is a servant leader who facilitates the team, empowers them to be able to get the work done on their own. No one including scrum master assigns task to development team but the self organizing team decides how to complete the tasks for increment.
Scrum Master removes impediments and coaches the team to be more productive. Product Owner in agile environment interacts with customer and other stakeholders for product features, prioritizing and release date.
What is scrum approach towards design? Should we have complete design upfront at the start of the project or we shouldn’t have any design?
As with scrum, we follow the approach of inspect and adapt. Its recommended to have just enough design upfront that is required to finish the task for the coming sprint. So, we keep learning with experience and accommodating what is required.
A thorough/complete design upfront will increase the risk of wasted effort in most of the scenarios.
As per agile manifesto, we respond to change over following a plan. In scrum, newly emerged requirements are welcomed throughout the project as long as it’s not disturbing our current in-progress sprint. Such requirements are added to Product Backlog and will be assessed in upcoming grooming sessions and re-prioritized the backlog accordingly.