Describing Agile and Scrum 101

Agile doesn't mean nor imply quicker, cheaper, or shorter than other options, but to be able to take the right decisions and to adapt based on your learning and the current needs. It's about constant learning in terms of what's needed and the way of working within the team. This leads to higher efficiency over time.​

Agility didn't just start in the 2000s when it became famous.​ The first signs of Agile methods in aviation can be found as early as 1943 in the Lockheed Advanced Development Programs, the mysterious Skunk Works, the development department for secret projects of the defense and technology company Lockheed. Within 180 days, the project team was supposed to develop a response to the Germans' overpowering Me-262. So Kelly Johnson 'stole' all the necessary personnel – technicians, engineers, pilots – and gathered them in a tent. They were able to fully concentrate on the development of their aircraft, the P-80, and used other Agile methods – even if they wouldn't have called it that at the time. They were actually able to reach their goal after just 143 days.​

Nevertheless, the lean management and principles developed by Toyota in the fifties are fundamental for Agile approaches and, therefore, inherited. Toyota started out as a system to manage production efficiently avoiding interruptions. ​The philosophy is to produce time-efficiently with the following factors considered: ​​

• Employees ​​

• Operating resources ​​

• Costs ​

• Planning and organization of all internal and external company activities​​

In the nineties Toyota finally started to bring Lean Management to other industries.​​

While the Lean Principles and the first formal Agile way of working found their way into software development with Extreme Programming (XP) and then Scrum in the eighties and nineties, the Agile Manifesto was created in 2001 in the Snow Bird Ski Resort in Utah when an alternative to documentation driven, heavyweight software development processes was agreed by a group of independent thinkers about software development. See more at https://agilemanifesto.org/history.html.​

As well in 2001, the Toyota Motor Corporation summed up their philosophy, principles, and values in an internal document they referred to as The Toyota Way 2001.​​

The Lean Thinking began in Japan in the Toyoda Steamed Silk Looms optimizing their production to high efficiency. Toyoda then began to produce steam engines for the automobile industry. ​Thanks to the needs of trucks during the Second World War, Toyota entered the automobile industry. ​

Toyota’s Lean Thinking became effective by following jidoka (identify the problem, stop the machine, find and eliminate the error, implement mitigation) and kaizen (continuous improvement). Both principles have been fully adapted by Agile methods.​

This requires to follow the Lean Triad, avoiding anything unnecessary:​

• Muda (Waste): In what area is the opportunity that you’re trying to create? Anything that doesn't help to achieve the wanted value is to be eliminated.​

• ​Muri (Overburden): Too much – unreasonable load on people, processes, or machines​. It slows you down, holding you back from the goals.​

• Mura (Variability): Variability has a negative impact – quite often seen in varying sizes of requirements that make it difficult to understand or estimate.​ Workload needs to be balanced for continuous improvement and efficiency.​

All three apply to people, processes, tools, and equipment (machinery)​. Any problem or issue could have elements of all three.​

With the Lean Principals in mind, Agile finally follows the PDCA principle for continuous improvement adaptation. ​

We plan what we're supposed to deliver, execute the plan, checking the results or the outcome in terms of delivery as well in terms of way of working, and finally, identify improvement or change activities, if needed, including them in the next planning.​

This approach deals with complexity and uncertainty, by 'slicing the elephant' into smaller pieces and learning from them, bringing light into the darkness, step by step. Dependencies are managed effectively as not all of them have to be satisfied at once and only the necessaries are tackled. Some might even become irrelevant. At the same time, we review how we worked together, improving interactions between people or working on required knowledge. ​

Finally, this all leads to more transparency step by step.​

Over the years, software development has been going through a huge maturity experience. We've seen a big change of paradigm. As stated in the figure, The Reality of Software Development, some dreams that we would like to be true are as follows:​

• The customer knows what they want​.

• Developers know how to build it​.

• Nothing will change along the way. ​

But in fact we face the following reality:​

• The customer discovers what they want as we go. ​

• The developers discover how to build it as we go​.

• Many things change along the way​.

This is best summed up by the following quote from Henrik Kniberg: "In software development, an empirical approach generally yields better results than a prescriptive one. Our current approach can be improved."​

Any framework is only a framework as long the Agile principles aren't understood and used.​ Agility basically stands on the following six pillars:

• Iterative and Incremental​

  Usually you're iterating through the same process or cycles (the name is depending on the framework) building the solution step by step. This means that every time a piece with a certain value is being delivered incrementally. Each delivery is a smaller piece of the big solution. When using cycles, they should be between one and four weeks long. At the beginning of each cycle, you need to figure out what are the most important things to do right now. At the end of the cycle, you'll demonstrate what was achieved and is working and will welcome feedback on it. By that full transparency is created.​

• People-Centric​

  Teams are based on trust, which requires that each individual is building an understanding of each other and is able to count on them. Teams have to be self-organized. Team members know best how to deliver the planned items and shouldn't be commanded from outside. Otherwise, creativity is undermined and individuals get demotivated.​

• Focus​

  The team focuses on one thing at a time until it's done, trying to avoid work parallelization as much as possible. Each change from one topic to another is taking effort, losing concentration, increasing the cognitive load (up to 20% loss). Nevertheless, as there might be waiting times for further input from other teams or the customer, there are items being worked on in parallel. This needs to be kept to an absolute minimum. If the wait time is too long, the reason needs to be identified and mitigated.​

  Defer the requirements definition until just before you build them – just in time (JIT).​

• Cross-Functional Teams​

  Dependencies are increasing the complexity, not only technically, but between teams in terms of communication and collaboration. Each team should be as independent as possible in their work. Therefore, cross-functional teams are needed, having all the knowledge and expertise they need to deliver their piece of work. This becomes more crucial the bigger the project is and the more requirements have to be scaled. Create cross-functional teams that include both business and technical people.​

• Learning​

  Continuous improvement requires continuous learning. Making mistakes is something good and encouraged as long as you learn from them, knowing the next time how to do it better and trying to avoid doing the same mistake again. This leads to efficiency and also to transparency in terms of uncovering the unknown. In the best case, you find out what you do not need, which leads you to finding out what you need or how. Therefore, better fail early to learn fast. The earlier you learn, the higher the chances are to be better and faster over the time of the project. If you just fail late, it might have an impact on many things you already worked on.​

• Adaptive Planning​

  As you learned, you don't always know exactly what is needed and requirements might change due to knowledge, market, or law changes. In a complex environment, you usually follow a moving target. Embrace this as something positive, as this leads you to what is really needed and not simply thought as needed. Promote adaptive planning and a people-centric approach.​

To help understand the benefit of using an Agile approach, consider the following analogy: ​

The traditional waterfall (WF) approach can be likened to shooting a goal. You can plan as much as possible, but it isn’t clear you hit the goal with that one shot you have as many factors can disturb it. (Goal Keeper, wind, bad hit of the ball, another player, and so on.)​

Agile is more like driving a car. You have a destination in mind, but you constantly react to obstacles and can adjust your route or even change your destination as your goal might not even be the destination but a certain value (for example, having a great dinner).​

Bear in mind that changing the destination (or, in a project, the deliverable) may entail additional workload. This change must be formally agreed upon – and actually chosen and requested – by the customer. Therefore, it’s worth remembering that neither an Agile nor a Waterfall approach is the solution for everything.​

The trajectory of the ball, once it's launched, can't be changed – it scores or it’s missing. One possible trajectory.​

In Agile, we can have multiple trajectories that are leading to the target or the target can change since the moment we started on the trajectory.​

To better understand the difference between the Waterfall and Agile approaches, we'll take Scrum, which is the basis for SAP Activate.​

Waterfall follows five consecutive phases: planning and analyzing the needs, designing the solution, building it, testing, and, finally, deploying it.​

Within Scrum, we do follow the same phases but within smaller cycles, again and again. Only the first cycle might not deliver something, as it often is seen as a preparation cycle. ​

As the slide shows, the Agile Scrum approach is simply cutting a Waterfall approach into smaller chunks, allowing adaptation and replanning. Some call this an iterative Waterfall, which is right as long you don’t follow the Agile principles.​

The Agile Manifesto came about as the result of a meeting in February 2001 that brought together several software and methodology experts, who then defined the Agile Manifesto and Agile Principles. The left side is valued more than the right side, but still, the right side is important and necessary. If we start to focus more on the left side of the four paradigms, we start to concentrate more on value delivery, adapting our efforts, in an Agile way, to what is really needed, with a lean management approach.​

The Agile Manifesto reads as follows:​

• Individuals and Interactions over Processes and Tools​

• Working Software over Comprehensive Documentation​

• Customer Collaboration over Contract Negotiation​

• Responding to Change over Following a Plan​

For the principles behind the Agile Manifesto, see Unit 6. ​

Those 12 principles, mainly coming from software development, underline the four previous paradigms and can be reused in any Agile project, regardless of whether they're software development or another type of project.​

As mentioned a couple of times already, Agility doesn't only consist of frameworks and tools but, more importantly, of principles, paradigms, and values. Only when these are combined and practised form the so-called Agile Mindset.​

Scrum is an implementation of the Agile mindset, one framework out of many. It's a lightweight process framework for Agile development, and the most widely used one.​

​

A process framework is a set of practices that must be followed for a process to be consistent with the framework. ​

Lightweight means that the overhead of the process is kept as small as possible to maximize the amount of productive time available for getting useful work done. ​

​

The Scrum process is distinguished from other Agile processes by specific concepts and practices, which are divided into the three categories of Roles, Artifacts, and Time Boxes. These and other terms used in Scrum are defined in this section in further details. Scrum is most often used to manage complex software and product development using iterative and incremental practices. Scrum significantly increases productivity and reduces time to benefits relative to classic Waterfall processes. Scrum enables organizations to adjust smoothly to rapidly changing requirements, and produce a product that meets evolving business goals.​

An Agile Scrum process benefits the organization by helping it to do the following:​

• Increase the quality of the deliverables​

• Cope better with change (and anticipate the changes)​

• Provide better estimates while spending less time creating them​

• Be more in control of the project schedule and state​

• Continuous improvement of work and way of working​

• ​

Scrum follows an empirical approach by introducing certain key performance indicators (KPIs) the teams are using to improve their way of working on one hand and by providing more transparency over progress and the work done or still to be done. Furthermore, it does introduce self-organized teams, spreading responsibilities on different shoulders for intensive and efficient communication and collaboration instead of centralizing them.​

The origin of Scrum terminology comes from the game of rugby.​

The scrum is a means of restarting the game after a stoppage that has been caused by a minor infringement of the laws (for example, a forward pass or knock-on) or the ball becoming unplayable in a ruck or maul. The scrum serves to concentrate all the forwards and the scrum-halves in one place on the field, providing the opportunity for the backs to mount an attack using the space created elsewhere.​

When Jeff Sutherland cocreated the Scrum process in 1993, he borrowed the term scrum from an analogy put forth in a 1986 paper by Takeuchi and Nonaka, published in the Harvard Business Review. In that paper, the authors compare high-performing, cross-functional product development teams to rugby teams using the scrum formation when they restart play. ​

You can see some of today’s characteristics of a scrum on a project and relate it to the sport or just think about it in our projects. ​

The Scrum team consists of a Product Owner, Development (Implementation) Team, and a Scrum Master. Around them, in our SAP projects, we also have a Project Manager and Stakeholder. Those roles are further explained in a later chapter.​

• Defines the features of the product. Decides on release date and content.​

• Prioritizes features according to market value.​

• Can change features and priority at every iteration.​

• Accepts or rejects work results.​

• Ensures that the team is fully functional and productive.​

• Enables close cooperation across all roles and functions and removes barriers.​

• Shields the team from external interferences.​

• Ensures that the process is followed. ​

• Invites team members to daily stand-up meetings, iteration review, and planning meetings.​

• Moderates the Scrum team events​

​

• Cross-functional, seven plus/minus two members.​

• Selects the iteration goal and specifies work results.​

• Organizes itself and its work.​

• Has the right to do everything (within project guidelines boundaries) to reach the iteration goal.​

• Demonstrates work results to the Product Owner​

• Project Planning​

• Resource Planning​

• Monitoring time and Budget​

• Stakeholder Management​

• Risk Management​

• Overall Project Responsibility​

  ​

Represents business user or anybody else with an interest in the project​

Scrum introduces these events that are supposed to be the only needed events. Besides them, the teams have various technical syncs on demand, but no further planning events are needed. There might be some more events required for interteam communication when scaling.​

The details can be found in the figure and will be discussed in later chapters.​

The Agile Product Backlog in Scrum is a prioritized features list containing short descriptions of all functionalities desired in the product. Typically, a Scrum team and its Product Owner begin by writing down everything they can think of for Agile backlog prioritization.​

In the simplest definition, the Scrum Product Backlog is a list of all things that need to be done within the project. It replaces the traditional requirements specification artifacts. These items can have a technical nature or can be user-centric, for example, in the form of user stories. The Backlog will be prioritized and rated, defining the sequence. Based on the learning during the project, some items might not be required anymore and be removed. New items might also appear.​

​

We also have the Sprint Backlog. The Sprint Backlog is a list of tasks identified by the Scrum team to be completed during the Scrum Sprint. During the Sprint planning meeting, the team selects some Product Backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each User Story.​

A Scrum Board is a tool that helps teams make Sprint Backlog items visible. The board can take many physical and virtual forms, but it performs the same function regardless of how it looks. The board is updated by the team, ideally, in real-time, and shows all items that need to be completed for the current​ Sprint.​

It visually displays current project work, specifically work that has been taken into the current Sprint. At a high level, it shows what hasn't been started, what is currently being worked on, and what has been completed, all Sprint based. ​

It mainly benefits individuals who are actively working on the project, such as the development team, but also those who aren't, such as stakeholders. Nevertheless, the Scrum Board belongs to the Development Team and is only allowed to be maintained by them. ​

Scrum Boards can either be physical or virtual, but they must be accessible and display project work. Physical boards often use a white board, wall, or magnetic board. The project work is written on index cards, sticky notes, or magnets. Virtual boards use software designed to look like the physical boards, but they're viewed and changed electronically. These are best for remote teams that aren't located in the same place. Today we usually have virtual boards from software such as Jira or Solution Manager. Cloud ALM also offers such a view.​

Scrum Boards are highly customizable. Your team should feel empowered to experiment with the layout in the spirit of adaptation. See what works well and adjust if necessary; inspect and adapt as needed.​

For a Scrum team, a typical Scrum Board has columns and rows. Each row represents a User Story or other itemization/chunking of work if you don't use user stories. Developers on the team may start with these columns on a Scrum Board:​

• Sprint Backlog​

• Doing​

• Needs Review or Needs Testing​

• Done​

• Impeded​

Some teams may use colorful sticky notes representing each backlog item or user story. The developers move the items from Doing to Done as the group progresses. They can also add extra columns like Blocked or Impeded for any obstacles.​

Progress on a Scrum project can be tracked using a Release Burndown Chart. The Scrum Master should update the release Burndown Chart at the end of each Sprint if it's note done automatically by the tool.​

Otherwise, most Agile Project Management tools such as Jira or VersionOne produce the burndowns for both Sprint and Release based on the updates on the Scrum Board.​

The horizontal axis of the Sprint Burndown Chart shows the Sprints and the vertical axis shows the amount of work remaining at the start of each Sprint.​

A Burndown Chart is a graphical representation of work left to do versus time. ​

The remaining work (or Backlog of the Sprint) is often on the vertical axis, with time along the horizontal. This isn't only useful to see actual performance but also for predicting when all of the work will be completed.​

The Burndown Chart should consist of the following:​

• X axis to display working days​

• Y axis to display remaining effort (Story Points or Person Days, elaborated later)​

• Ideal effort as a guideline​

• Real progress of effort​

Teams usually first have to find their rhythm, understanding how much they can achieve in a Sprint and how to rate/estimate Sprint items. Usually after 3–6 Sprints they have a good understanding based on the learning of their Burndown Chart, making their planning more reliable.​

The Burndown Chart is also used by the Scrum Master to better understand the performance of a team, discussing improvements to reach their plan and commitment.​

In summary, there are various tools and techniques used in the day-to-day flow of an Agile project. ​

Teams use the Product Backlog. This can be a simple spreadsheet (for example, using the Product Backlog template accelerator in the methodology), or it can be a more sophisticated backlog management tool, such as VersionOne or Jira, Cloud ALM (or still SAP Solution Manager Focused Build).​

The results of the Sprint planning are brought on to the Scrum Board. The team uses the Scrum Board as a visible tracking mechanism and displays the Sprint progress and any blockers.​

The team conducts a daily meeting. These dailies are meant to be a synchronization between team members about progress and help needed. ​

The Burndown Chart helps to understand progress and issues versus their plan and estimates.​