Scrum – Software Development Framework

There are several (or many) frameworks specific to software development. In this post I want to introduce you, my “I Power Seeds“, to Scrum.

I will also be posting other frameworks and models. The goal is to plant seeds or introductions to these frameworks and models for you to then dive deeper into the one that fits into your goals or those of the company you are with or looking to join.

I will be pulling in some details from resources such as websites, videos, and training workshops.

What are the Benefits of Scrum?
• Better visibility and efficiency
• Empowerment and autonomy
• Focus, improved productivity and forecasting

From Wikipedia

Scrum is a framework for managing work with an emphasis on software development. It is designed for teams of three to nine developers who break their work into actions that can be completed within fixed duration iterations (called “sprints”), track progress and re-plan in 15-minute Daily Scrum meetings, to collaborate and deliver work on every sprint.

Key ideas
Scrum is an iterative and incremental agile software development framework for managing product development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”, challenges assumptions of the “traditional, sequential approach” to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.

A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited. As such, Scrum adopts an evidence-based empirical approach—accepting that the problem cannot be fully understood or defined up front, and instead focusing on how to maximize the team’s ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions.

Note on capitalization. Many of the terms used in Scrum (e.g., scrum master) are typically written with leading capitals (i.e., Scrum Master) or as conjoint words written in camel case (i.e., ScrumMaster). To maintain an encyclopedic approach, however, this article uses normal sentence case for these terms—unless they are recognized marks (such as Certified Scrum Master).

In the literature, this is occasionally seen in all capitals, as SCRUM. While this is incorrect, as Scrum is not an acronym, it likely arose due to an early paper by Ken Schwaber which capitalized SCRUM in the title.

History
Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development in their 1986 Harvard Business Review article, “New New Product Development Game”. Takeuchi and Nonaka later argued in The Knowledge Creating Company that it is a form of “organizational knowledge creation, […] especially good at bringing about innovation continuously, incrementally and spirally”.

The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries. They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team “tries to go the distance as a unit, passing the ball back and forth”. (In rugby football, a scrum is used to restart play, as the forwards of each team interlock with their heads down and attempt to gain possession of the ball.)

In the early 1990s Ken Schwaber used what would become Scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna, developed a similar approach at Easel Corporation, referring to it using the single word Scrum. In 1995 Sutherland and Schwaber jointly presented a paper describing the Scrum framework at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications ’95 (OOPSLA ’95) in Austin, Texas. Over the following years, Schwaber and Sutherland collaborated to combine this material—with their experience and evolving good practice—to develop what became known as Scrum.

In 2001 Schwaber worked with Mike Beedle to describe the method in the book, Agile Software Development with Scrum. Scrum’s approach to planning and managing product development involves bringing decision-making authority to the level of operation properties and certainties.

In 2002 Schwaber with others founded the Scrum Alliance and set up the certified scrum accreditation series. Schwaber left the Scrum Alliance in late 2009 and founded Scrum.org which oversees the parallel professional scrum accreditation series.

Since 2010, there is a public document called The Scrum Guide that defines sort of an official version of Scrum and is occasionally revised.

Download the Scrum Guide: 2017-Scrum-Guide-US

Here are my I Power Seeds

Here are some key points and terms.
Roles
○ Product Owner
○ Scrum Master
○ Development Team

Artifacts
○ Product Backlog (PBI)
○ Sprint Backlog
○ Product Increment

Events
○ Sprint Planning
○ Sprint Execution
○ Daily Scrum (product increment)
○ Sprint Review (inspect and adapt)
○ Sprint Retrospect (inspect and adapt)

The retrospect is continuous improvement (CSI in the ITIL framework).

Teams should be no more than 3-9 people and contain cross-functional members so the team can do it all (this includes designers, architects, testers, programmers, etc.)

Scrum Master – Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The scrum master is not a traditional team lead or project manager but acts as a buffer between the team and any distracting influences. The scrum master ensures that the Scrum framework is followed. The scrum master helps to ensure the team follows the agreed processes in the Scrum framework, often facilitates key sessions, and encourages the team to improve.

Has no management authority over the team.

What you need in a Scrum Master:
• Empathy
• Knowledge
• Passion
• Communication skills
• Guidance and coaching (not telling)

(image from CBT Nuggets)

Sprints – the iterative steps.

Product Owner – oversees the Product Backlog Items (PBIs)
• Clearly expressing the PBIs
• Ensuring it is understood by all members
• Making sure it is visible and transparent
• Prioritizing the PBIs
• Refining
• They do not assign tasks

Product Owner has management over the scrum team, but a Scrum Master does not so they should not be the same person.

There are no Project Managers in Scrum, there is an overlap of skills, and a benefit is there no micromanagement.

There is a very strong recommendation to never have the same role as Scrum Master and as the Product Owner. The roles are different and need to be different people to have a successful Scrum process.

Need only one Product Owner – decisions by committee takes too long – Scrum is agile and quick. This is key. How many times have we seen projects delayed or stalled because of “death by committee” – Scrum removes that and while it is very agile.

There are also no sub-teams and no titles – everyone is a “Developer” – such as there are no team members who only test, that way everyone is in the Scrum process from start to end and everyone has a wide breadth and depth of skills and experience to encompass all facets from coding to testing to deployment.

This type of teams or groups are small and everyone is focused on team work rather than “my work”. This model keeps everyone more engaged than other software development models.

Within the Scrum framework, the teams are cross-functional and self-organizing team members. The teams need to have members who are responsible to self-organize and the Scrum Master will help them stay on task.

Product Owner tells the team what needs to be done. The Scrum Master does not do this, they are there to coach, encourage, help reduce or mitigate distractions. The team itself tells each other what needs to be done – tasks, etc. What a concept right?!

An example of a key role of the Scrum Master is to mitigate distractions from the development team to ensure the sprints are effective and efficient. This is critical to agile and fast development

I will give you an example of a similar instance that I put into place with my development team. The company I joined allowed the end user to contact the developers directly to offer suggestions and report issues. I changed that process by hiring a development manager (Scrum Master) and I was the Product Owner. The development manager coached them, offered ideas, and kept them on task by having short meetings. The users were directed to let me know what suggestions and concerns they had. Even though this was not a formal Scrum framework in place, it was similar in nature and I saw immediate results. Development time was decreased by as much as 75% as the development team could solely focus on development while the manager coached them and resolved issues immediately and I took care of the Product Owner responsibilities. In the end, the end-users and my staff were engaged and happy with the pace of software development.

All team members are equal which makes it easier to collaborate and share – TRUST and ACCOUNTABILITY are high. (two facets of a successful team)

Others in the team help out to complete the overall goal versus one person moving along to something else.

PBIs – Product Backlog – these are the list of changes or requests needed or requested.

Feature has to have Value (like ITIL). This is a key concept, there must be value. Scrum is agile and if you add a bunch of bells and whistles, that might never be used, is slows down development (opposite of agile development).

List of requirements in Scrum is flexible, plan-based approaches are fixed.

Product Backlog Items (PBI’s can include anything and are added from the Process Owner)

Sprints should not be longer than 4 weeks and the Scrum Master enforces this with the team.

Everyone in the team attends, not necessarily all the stakeholders
• Process Owner brings the Sprint Goal
• Sprints should be sustainable

Sprint – start with highest priority PBI’s.

Sprint – use Task Flow Board much like a Kanban (see other post for more details).

A Sprint is completed or done when the Product Owner and Developers agree upon.

Daily Scrum – has to happen every day, same place, same time – time boxed and lasts only 15 min – just to touch bases. It should include just the developers with the Scrum Master orchestrating it but not dictating assignments. The Scrum Master must keep things on pace if the Process Owner sits in.

Developers pick a time for each Sprint – such as 2 weeks – but can change depending on what works for the team. But then once changed, stick to it so it does not keep changing. Short and consistent Sprints is key as it helps keep focus on priorities that the team set for each Sprint.

Scrum Execution – working Product Increment comes out of it – what will be done over the next “2 week” Sprint.

Sprint Review – about 1 hour meeting for every week for the Sprint, should be no surprises, demo what was done, informal and collaborative.

Sprint Retrospective – held after each Sprint to look at the Scrum Team and should be less than 1 hour per each week of Sprint where the team comes up with an action plan or plan for improvement, action items, and is a way to help the team feel better about improvement. This is a time-boxed inspect and adapt activity for the Scrum Team to examine their processes, relationships, and tools.

5 Scrum Values:
These core values of Scrum are really important to understand. They keep the software development going in a fast pace while providing encouragement, engagement, sustainability, and producing significant results.

Resources

CBT Nuggets
I really enjoy this format and it works for me as they are short videos with a short quiz after each video. I personally like this format as it gives me short bits of information and provides me time to take notes and reflect and research further on what I learned in the 6-8 minute videos. I noticed I have learned and retained a lot more in this format then watching one long video or even doing an online live course.