Minimum Desirable Agile in a Scrum Framework

Agile nowadays is a fashionable term just like artificial intelligence and machine learning. Every organization wants to use these words to describe themselves or their products. But, can an organization become agile just because it describes itself as agile? I don’t think so!

Being a certified scrum master myself and having been a part of the product development lifecycle as a product manager and product owner, I have seen various flavors of agile. It all begins with ‘we have our own agile processes’, whenever I have started working for an organization.

While it is perfectly fine to customize the agile processes as per the needs of an organization, I think there are certain minimum considerations for an organization to label its product development lifecycle as agile. In fact, agile frameworks like scrum allow for that flexibility, unlike the traditional project management body of knowledge, where inputs, outputs, processes, templates, etc. are being defined in a straitjacketed manner.

The way I have understood agile is by imagining an athlete on a track. Even the terms like sprints used in scrum help me associate with this imagination of an athlete. Being agile is to be flexible in terms of requirements planning and the phases itself. It is about constant adaptation to meet the goals. One of the common goal is to optimize value, however that value is defined and to deliver that value incrementally. So, this athlete a.k.a. the organization develops a stamina to win races and attain business goals over time.

I consider the following as absolute minimum requirements in terms of understanding and practice for the product development lifecycle to be called ‘agile’ in a scrum framework.

First of all, the three pillars of scrum must be known to everyone on the team. They are the basis and form the core ideas of the scrum framework.

1. Transparency: Significant aspects of the process must be visible to all stakeholders including the development team.
2. Inspection: scrum artifacts and progress towards a sprint goal must be inspected with a regular cadency within the sprint to detect undesirable variances and course correct.
3. Adaptation: This is the course correction part where aspects of the process and its results that are outside acceptable limits are adjusted.

Secondly, the following roles are needed. It is not enough just to have these roles but the people in these roles should also be capable of performing the basic tasks associated with these roles

1. Scrum master:

• Coaches the team
• Removes impediments
• Facilitates scrum events

2. Product Owner

• Expresses product backlog items
• Orders the product backlog to best achieve goals
• Ensures that the product backlog is visible, transparent and clear to all
• Ensures the the development team understands product backlog items

3. Development team

• Is responsible for the ‘done’ increment
• Creates sprint backlog
• Sizes and estimates work

Note that the same person may be performing more than one role, particularly in startups. It is not uncommon for the product owner to also discharge the responsibilities of a scrum master. However, the person must understand the responsibilities of the roles and must be capable and able to execute those responsibilities.

Thirdly, the following scrum artifacts are required. These artifacts either feed into a scrum event or are an output of a scrum event.

1. Product backlog: It is an ordered list of features, functions, requirements, enhancements and fixes. Each of these will have a description, an order of priority, an estimate and the value they deliver.
2. Sprint backlog: This is a list of items that the development team pulls from the ordered product backlog. In fact, the adjective ‘ordered’ is a misnomer because product backlogs are supposed to be always ordered.
3. Potentially releasable product increment: This is an incremental feature, function, enhancement or a fix that is delivered by the development team at the end of each sprint. Ideally, this will match the sprint goal that was decided as part of the sprint planning. Potentially releasable means that the increment in question has been reviewed, tested and documented.

Lastly, the following scrum events, when meaningfully held add a lot of value and bring life to this whole process.

1. Product backlog refinement: The product owner is responsible to keep the product backlog refined. This means that all items that have been identified must have a place in the product backlog with their respective description, order, estimate and value. Again, some of these will be added in an evolutionary manner. Note that this is an ongoing process unlike the events below which follow a cadence.
2. Sprint planning: A sprint is a time box of one month or less during which a potentially releasable product increment is created. Sprint planning is the event where the team gathers together to pull items from the product backlog, brainstorms the product backlog items and creates a sprint backlog and an overarching sprint goal/s. To do this, the development team will also decompose the functionality to be done into smaller level tasks so that appropriate estimation can be done. This event is time boxed for 8 hours for a 1 month sprint.
3. Daily scrum: These are also known as daily stand up. This is an event that takes place in the same place at the same time every working day. This event is time boxed for 15 minutes per day. Note that this is an accountability session where team members are made accountable for their time. Gone are those days of ‘Taylorian’ methods. The main objective of this even is to inspect progress. The three questions that every member answers are

• What did I do yesterday that helped the development team meet the sprint goal?
• What will I do today to help the development team meet the sprint goal?
• Do I see any impediments that prevents me or the development team from meeting the sprint goal?

4. Sprint review: This is an informal event where the scrum team showcases working product and collects feedback. The stakeholders help resolve impediments and provide feedback. This event is time boxed for 4 hours for a 1 month sprint.

5. Sprint retrospective: The objective of this event is to inspect and adapt the scrum itself for continuous improvement. As the name itself suggests, the team retrospects to find out what went well, what did not go so well and what can be done to improve in the upcoming sprints. This event is time boxed for 3 hours for a 1 month sprint.

So, these 3 pillars, 3 roles, 3 artifacts and 5 events form the core structure of a scrum framework, which is a popular agile framework in action today.

I hope that this article gave you a bird’s eye view of the scrum framework. I will zoom in and provide more details, while also adding my own experiences about scrum in future articles.

Until then, good bye!