Agile ways of working
In today’s world, every software company claims to be agile.
This post is a condensed version of the official Scrum Guide. I have not changed the intent of the guide but have added context based on my experience and removed details where I felt it was obvious. However it is true that what is obvious to me may not be obvious to another person. So if something in this post doesn’t agree with your understanding of scrum, please read the scrum guide.
What is Agile?
If you go searching for information on what agile software development is, you’ll run into the good old Agile Manifesto website.
The concept was born from experience working in large software development projects at the time. Some engineers got together and decided to create a better way of working on software. This, if understood and applied correctly, will significantly improve the software development lifecycle.
The essence of agile focuses on 4 key values which you can see on the landing page of the agile manifesto website:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to change over following a plan
The group that gathered to create the manifesto even drafted twelve principles that all point back to the values that I have just pasted above.
When you think about it, the values stated all seem like common sense. Principles give structure to common sense. And that is exactly what was done there.
What is Scrum then?
In software developer terms, you can say, Scrum is a concrete implementation of the Agile manifesto.
It is a lightweight framework that enables you to implement the Agile manifesto and therefore achieve the twelve agile principles.
As the Scrum Guide says, scrum requires someone called the Scrum Master to foster an environment where:
- A Product Owner orders the work for a complex problem into a Product Backlog.
- The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
That sounds a bit too simple! Is that really it? Yes. That is the essence of it.
The foundations of scrum
Scrum is founded on
Empiricism - knowledge comes from sensory experience Lean thinking - reducing waste and focusing on essentials
Three pillars of scrum empiricism
Transparency - Work done must be visible to all - those doing the work and those receiving the benefit of the work. Remember that in a scrum, you are collaborating with the customers. It is not them and us, it is just Us that includes the customers.
Inspection - Progress made towards the goals must be inspected frequently and diligently
Adaptation - In case of any deviation from what was previously agreed on as acceptable, then the corresponding results must be adjusted as soon as possible to minimize further deviation.
Essential values to implement successful scrum
Irrespective of adopting the scrum framework, these values are essential to create a good team.
A good team must be able to highlight problems, hold each other accountable and be able to understand that when questions are asked it is not personal. Questions are raised in the team so that everyone understands the value that is being developed and is not distracted by anything else.
Humans of scrum
The fundamental unit of scrum is a small team of people called a scrum team. It consists of:
- Product Owner
- Scrum Master
- Software Developers
The team must be cross-functional, i.e members have all the skills necessary to create value in every agreed upon interval called sprint. They are also self-managing - no one tells them who does what, they decide based on what they have found and how.
Ideally, the team must be small enough to remain nimble and big enough to complete the work that delivers value in a sprint. If the team is big, then it is better to split the team into multiple cohesive scrum teams where each one is focused on the same product. Therefore sharing the same Product Goal, Backlog and Product Owner.
The scrum team is responsible for creating a valuable, useful increment every sprint.
The three types of accountability in Scrum
The creators of the usable increment in each sprint. Responsible for the following:
- Create the sprint plan - the sprint backlog
- Adhering to the definition of Done
- Adapting the plan everyday towards the sprint goal
- Holding each other accountable as professionals
Although scrum defines this group as developers, it does not dictate that there is no quality assurance experts or software development engineers in test in this group.
The person responsible for maximizing the value of the product that the scrum team is working on.
Accountable for managing the product backlog by
- Effectively communicating the Product Goal
- Creating and communicating product backlog items
- Prioritizing and ordering product backlog items
- Ensuring that the backlog is transparent, visible and understood
Whether they do it themselves or delegate it, they are the one accountable. This role is not a committee but a person. Any changes to the product backlog must be approved by the Product Owner.
Accountable for establishing Scrum as defined in the scrum guide and for team’s effectiveness. Ensures that everyone understands scrum theory and practice within the Organization and the team.
This is the role that ensures that scrum is done right and the person in this role must know the concepts of scrum and value delivery in detail. The responsibilities of this role is that of a servant leader, coach and educator. The person is a champion of Scrum and is responsible for ensuring that scrum events take place and are positive, productive and within time-box.
Each event in a scrum is a formal opportunity to inspect and adapt Scrum artifacts. The Sprint is the longest event and is a container for all other events. These events are designed to enable transparency and must not be skipped as this might lead to a lost opportunity to inspect and adapt. They keep everyone in sync and accountable.
The heartbeat of scrum - ideas transformed into values here. They are fixed length events - 1 month or less and subsequent sprints remain the same length to ensure consistency.
During a sprint:
- No changes must be made to endanger the sprint goal
- Quality must not decrease: a good Definition of Done, ensures quality is baked into development
- Product backlog is refined as needed
- Scope is clarified and renegotiated as more is learned
Every few sprints, it is good to check if the value being delivered meets the product goal, in some contexts - these maybe the Objectives and Key Results. You may size the sprint based on a reasonable interval required to deliver value.
As scrum is best applied for complex and uncertain development, a sprint maybe cancelled if the sprint goal has become obsolete! However, the Product Owner is the sole person with the authority to do this.
The initiation of the sprint happens in this event. All the work to be performed in the sprint is agreed and the resulting plan is created by collaborative work of the entire scrum team.
The product owner ensures everyone understands the product goal and how the product backlog items are mapped to it. Attended by the scrum team and sometimes even external stakeholders where necessary.
The main takeaways from sprint planning are:
- Why is this sprint valuable?
- What can be done in this sprint?
- How will the chosen work get done?
Why is the sprint valuable?
Product owner is responsible for communicating how the product could be made more valuable in the sprint. The scrum team then decides what the Sprint goal must be.
What can be done in this sprint?
The scrum team selects items from the product backlog to be done in the current sprint. They may refine it again to refresh shared understanding of the product backlog item. How much work can be done in a sprint is something that comes with experience.
The more the developers learn about
- past performance
- upcoming capacity
- definition of done
The better their forecasts will be.
How will the chosen work be done?
For every product backlog item, developers must plan the work necessary to create an increment that meets the definition of done, by decomposing the backlog item into smaller work items that can be done in one day or less. The developers are in charge of breaking down product backlog items into increments of value.
The sprint backlog
The Sprint goal, the backlog items chosen for the sprint, and the plan for delivering them are collectively known as the sprint backlog.
The length of the event
Scrum guide definition is to have a time-box to a maximum of 8 hours for a one month sprint.
The purpose of the Daily Scrum is inspection of progress towards the sprint goal and adapt the sprint backlog as necessary, adjusting upcoming planned work. This event is primarily for the developers of the Scrum team. Others may choose to attend if convenient. It should not be longer than 15 minutes.
If the Product Owner or Scrum master is working on items in the Sprint Backlog, then they participate as Developers too.
This is not the only time in a day that developers talk to each other, but this is the preferred start of a day. The focus of the daily scrum must be on the progress towards the sprint goal and must result in an actionable plan for the upcoming day, thereby helping create focus and improving self-management.
This is a great opportunity to communicate/identify impediments and promote quick decision-making.
In order keep the daily scrum concise, it is best to stick to answering the following questions, in the context of making progress to the sprint goal:
- What did I do yesterday?
- What am I going to do do today?
- What is stopping or slowing me down from making progress?
Sprint goal achieved early
If the answer to the first or the second question in the daily scrum has nothing to do with making progress towards the sprint goal, then the development team has:
- either misunderstood the sprint goal
- or the sprint goal has been achieved already
In the first case, attend scrum training.
In case of the latter, the development team must be focusing their efforts to refine and start working on the next most important product backlog item from the product backlog after discussing with the product owner. This does not mean that the developers must change the sprint goal. This is an opportunity to set the scrum team up for success in the upcoming sprint too. A head start must always be exploited to deliver more value.
- Inspect the outcome of the sprint
- Determine future adaptations
Scrum team shows off the outcome of their sprint work to key stakeholders and discuss the progress towards the larger Product Goal.
All attendees after reviewing what has been accomplished, collaborates on what to do next. This next thing might be something that is already in the Product Backlog or maybe ideas that might later be added to the Product backlog. Sometimes, it could also be where stakeholders decide, to change what the next highest priority is. Either way, the outcome mostly affects the Product Backlog.
The sprint review is not just a presentation but a working collaborative discussion session.
Length of the review
Recommended time-box is a maximum of 4 hours for a one month sprint and hence must be adjusted accordingly for shorter sprints.
- identify how to increase quality and effectiveness
The scrum team inspects:
- How did the last sprint go with regard to individuals, interactions, processes, tools and Definition of Done
- Blameless postmortem of assumptions, decisions that slowed progress
The scrum team then identifies the most helpful changes to improve effectiveness and addresses them as soon as possible. It is important to discuss and action only the most helpful changes and not everything as time and effort is limited in a sprint.
The retrospective concludes the sprint.
Length of the retrospective
Time-boxed to a maximum of three hours for a one-month sprint must be adjusted accordingly for shorter sprints.
These are things that represent work or translate into value. Every artifact also contains a commitment to ensure it provides the information that enhances transparency and focus:
- Product backlog has Product goal
- Sprint backlog has sprint goal
- An Increment of value has Definition of Done
These commitments reinforces empiricism and the scrum values for the Scrum team and stakeholders.
This is a developing, ordered list of what is needed to improve the product. It is the only source of work undertaken by the scrum team.
The product backlog requires regular refinement activities to help develop a shared understanding of the backlog item and to help better break it down in smaller more precise items. This is an ongoing activity and must be done regularly to ensure that the backlog items have sufficient details and a size and priority associated to it.
Commitment: Product Goal
This is a statement that describes the future state of the product which can serve as a target for the scrum team to plan against.
The product goal is often the only thing defined in the beginning, every backlog item that emerges, describes what will help fulfil the product goal. It is the long term objective for the scrum team that they must either fulfil or abandon before taking on another one.
This is a combo of:
- the sprint goal - the why
- the set of product backlog items selected for the sprint - the what
- the actionable plan for delivering hte increment - the task breakdown and order of execution - the how
This is a plan by and for the developers. This must be inspected and adapted regularly throughout the sprint as more is learned.
Commitment: Sprint goal
The single objective for the sprint that helps create focus and coherence, encouraging the team to work together towards a common goal.
The sprint goal is created during Sprint planning and if during the sprint the work turns out to be different from what was expected then the developers must collaborate with the Product owner to negotiate the scope of the sprint backlog within the sprint without affecting the sprint goal.
This is a concrete stepping stone towards the Product Goal that meets all the conditions in the Definition of Done.
Every increment must work together and must be usable in order to provide value.
A sprint can result in multiple increments and all of these increments are discussed during the Sprint Review.
Commitment: Definition of Done
A formal description of when an increment meets the quality measures required for the product. A developers must conform to this definition as a minimum. In some organizations, there is a standard definition of Done for any work done.
If the work done for a product backlog item does not meet the Definition of Done, then it cannot be released or event presented for Sprint Review. It must return back to the product backlog for future consideration.
If multiple scrum teams work together on a product then they must mutually define and comply with the same definition of done to ensure best practices are followed throughout.