Agile Scrum

Agile Scrum
We started this series on the Scrum methodology with an introduction (LINK), followed by two pieces on two of the most important roles in the Scrum framework (the Scrum Master and the Product Owner, LINKS), and an article on the framework itself and why it's called a framework for Agile working (LINK). After that, we have taken an in-depth look at some of the Scrum framework's most common events, from Scrum planning (LINK) and Sprints (LINK) to Daily Scrums (LINK), Scrum Reviews (LINK), and Scrum Retrospectives (LINK).  
We did so, because when it comes to Scrum, a project consists of Sprints and Sprints are built up of events. The role which each of these events plays and the way in which they take place can differ considerably based on factors like the the product that is being developed, the experience of the people involved in the project, and the preferences of the team members themselves. In general though, a traditional Scrum project contains at least the four previously mentioned events or ceremonies.  
With this article, we're taking a small step back in this series as we feel it can be both interesting and useful to study the relationship between the Scrum framework and general Agile methodology in more detail. We realise that this relationship can still be confusing at times, especially for people who are just getting acquainted with Scrum and Agile, and we have noticed that in many cases, a correct, clear explanation is lacking. By writing this article, we hope to address that issue for all of those people who are still struggling a bit to wrap their head around these concepts and their mutual relationships. 
In essence, the connection between the Scrum framework and Agile methodology is quite logical. Due to the fact that this, after all, is specialised professional knowledge though, it's very possible that it will sound more than abstract to a person who has never even heard of Scrum and Agile. The very first thing you should know, is that all of it has to do with project management. In other words, when we're talking about these concepts, we're talking about approaches to help make projects more manageable. Usually, this concerns software development projects, but in recent years, Scrum and Agile have also seen applications in other fields, including complex technology development projects and research projects. 
In order to clarify the relationship between Scrum and Agile, we have chosen to dissect both of the concepts separately. Very simply said, Agile is a project management philosophy. It's a combination of values, principles, and tools to make the managing of complex projects more fluent and more transparent for everyone involved. Later on in this article, we will go over the contents of this philosophy in much more detail. 
Scrum then, is a framework that can be used to implement the Agile philosophy in a project. It provides project managers with a set of roles that need to be taken on by the members of the team working on the project in question, a design for a workflow consisting of events or ceremonies and aimed at cutting up complex projects into many small bits, and a set of so-called artefacts, which can be considered as tools and solutions that function as the foundation for a successful workflow. 
So, to put it briefly, Agile is a general way of managing complex projects, while Scrum is a framework that enables managers to implement the Agile way. Imagine it like a football game: the rules of the game exist, but they can only be implemented correctly if the necessary framework is present, which consists, amongst other elements, of a football pitch with lines, two teams to play against each other, and a referee to guide the game and make sure that it starts and stops at the agreed upon times.  
So there are other ways of implementing the Agile methodology then? 
Defining the Scrum framework as a tool to help you implement the Agile way or methodology implicitly indicates that there is more than one way to help your organisation go Agile. The truth is that Scrum is not the only Agile framework and later on in this series of articles, we will study a few different frameworks as well. In order to already give you a bit of an idea of the kind of frameworks that exist as alternatives to Scrum though, we will briefly go through some of the most popular approaches here below. Hopefully, this will also help you better understand the relationship between Agile and Scrum. 

The caption
Like the Scrum framework, this approach to project management originated in Japan. Based on the systems used by supermarkets to restock their shelves by continuously observing what's being picked off the shelves by clients, one of Kanban's main objectives is to avoid producing a surplus and therefore reduce waste. The different tools that come with the Kanban framework, like Kanban cards and a Kanban board, all help to visualize how resources move through the production cycle. This way, every person involved in the project can gain maximum insight into the process, while it also allows managers to address issues related to production shortages or surpluses in real time. 
Kanban also distinguishes itself in the way it puts team members to work. Ideally, team members “pull” in the tasks they will work on, instead of tasks being fed to them by a manager or supervisor. The framework implicitly states that a person can only take on so much work within a limited amount of time. Through boards and cards, the Kanban method helps team members to no exceed the limits of their productive capacity. This way, focus on the tasks at hand is increased. 
The main difference between Kanban and Scrum is that Kanban is continuous, while Scrum is iterative (or repetitive). Therefore, Kanban is better suited for teams that have a lot of unplanned work coming up, such as support issues, emergency fixes, or other urgent requests, during their Sprints. This way, the team can start working on items as they appear and re-prioritize tasks as needed, instead of waiting until the end of the Sprint as is the case in the Agile Scrum framework. 
Lean Software Development 
The Lean Software Development methodology borrows heavily towards the Kanban framework and that makes sense, because its design was based on Toyota's Kanban-based processes. To give you an example of this: Just like Kanban, Lean Software Development aims at reducing waste and achieving optimal value for the customer. The definition of waste is important in this sense, as it refer to building the wrong feature, team members waiting/multitasking/switching, and team members generally wasting time doing something that will never be used. There’s also the "pull" concept that comes from Kanban, where team members assign their own tasks based on their own capacity, as well as the notion that you should be respectful towards the people you work with and trust that each of them is doing the best he or she can. 
As far as the differences between Lean and Agile Scrum are concerned, the briefest explanation is that Agile Scrum is a software (or product) development framework, while Lean helps optimise such production processes. The principal focus of Agile Scrum lies on the people and how they function as a cross-functional team, while Lean focuses on the processes and how those can become as efficient as possible. Both Lean and Scrum are considered Agile techniques, but the former introduces two major concepts: eliminating waste (like the older Kanban methodology on which Lean is based) and improving workflows. 
The reason for which Kanban was used as the major inspiration for the creation of the Lean Software Development methodology is that its author, Mary Poppendieck from the American state of Maryland, was confronted with Kanban as IT manager at a large videotape plant. Or better said, she was confronted with Kanban practices by competitors from Japan, who were somehow managing tapes of higher quality at a quicker rate and cheaper cost. As a result, the plant were Mary worked was quickly becoming outdated, so she decided to restructure their own plant's processes based on a book about Kanban written by a manager at Toyota. The plant's output increased dramatically on a relatively short term and the Lean Software Development methodology was born.  
Extreme Programming (XP) 
To start with, the differences that exist between Agile Scrum and Extreme Programming are often subtle, but that doesn't mean unimportant. On the contrary, despite Agile Scrum and XP being very aligned, incorrectly understanding or interpreting the differences between the two can have a profound impact on the team. Before getting into the main differences though, we should explain what Extreme Programming is exactly about. 
This approach was designed and championed by Kent Beck, who was a Chrysler employee in the nineties. Basically, his idea was to take existing programming methods and take them to the extreme. Instead of code reviews at agreed upon times, for example, Beck advocated so-called pair programming, which simply said refers to a non-stop review of the code as it's being created. This became one of the basic principles of XP, though there are eleven more principles, including simple designs, small releases, and collective code ownership.  
As we stated before, despite the many obvious similarities between XP and Agile Scrum, there are also some important differences between the two: 
  1. Agile Scrum projects are built up of Sprints and at the end of each Sprint, ideally a new increment is finished and delivered. These Sprint usually have a duration of between two weeks for standard projects and a month for more complex projects. Extreme Programming teams tend to work in blocks of one or at the most two weeks long. 
  2. In an Agile Scrum-based project, as soon as the Sprint planning is completed and the team has committed to the delivery of a certain increment, the Sprint can not be adapted any more. The Scrum Master can cancel the Sprint in the worst case, but making changes to an ongoing Sprint is not allowed. As far as Extreme Programming teams are concerned, as long as they haven’t started work on a particular feature, an feature that hasn't been started yet can easily be replaced by a new feature of equivalent size (i.e. Workload).  
  3. The way in which priorities are set and handled thereafter also differs between Agile Scrum and XP. In comparison to Agile Scrum teams, Extreme Programming teams need to adhere to priorities set by the customer (the role taken on by the Product Owner in Scrum) in a much stricter way. As a matter of fact, XP teams have to accept the priorities as indicated by the customer and are required to work in that order. By contrast, the Product Owner within a Scrum team prioritises the Product Backlog, but the development team determines the order in which the indicated Backlog items will be developed. 
  4. The Scrum methodology doesn’t prescribe any engineering practices, while Extreme Programming does. These include things like the earlier mentioned pair programming, test-driven development, the focus on automated testing, simple design, and refactoring, just to name a few.  
Crystal is actually a set of Agile methodologies that is very much focused on people, like Agile Scrum is, and consists of several variants, such as Crystal Clear for teams of up to eight people, Crystal Yellow for teams up to twenty people, and Crystal Orange for teams of up to fifty people. Alistair Cockburn, who authored the foundation of the Crystal methodology in the early nineties, has said that “Crystal is a family of software development methodologies, which works with the power invested by people, and is extremely light and stretch-to-fit”. The basic idea of Crystal is that the more people there are on a team, the more critical the project is, the more controlled the project type is, and the more structured and rigid the development approach needs to be. 
Like Extreme Programming, the Crystal approach is very similar to the Agile Scrum methodology, apart from a few small differences. Crystal teams, for example, are allowed to accept changes per project and team size requirements, while Scrum teams, as we know, need to strictly stick to a Sprint once it has been started. The more flexible nature of Crystal is also reflected by the fact that Crystal teams deliver according to (fluctuating) criticality, while Scrum teams need to largely follow the priorities in the Product Backlog as indicated by the Product Owner.  
One aspect where the Scrum approach offers more flexibility though, is at delivery. A Crystal team can not change any of the project's parameters as soon as the process and budget have been finalised. Seeing as customer requests are accepted and even encouraged by Scrum teams, changes can still take place after the project or budget has supposedly been finalised. This is also why clients of Scrum teams will often have more questions and requests than the clients of a Crystal team. 
We hope that by explaining a bit more about some of the other Agile frameworks that exist besides Scrum, you have gotten a better idea of the relationship between Agile and Scrum. Like we wrote before, there are plenty of other methodologies and frameworks as well, such as Feature-driven Development (FDD), Adaptive System Development (ASD), and the Dynamic Systems Development Method (DSDM), but the three above are some of the most popular and widely implemented frameworks. Seeing as this series is about Scrum and its many facets, we will take a look at the advantages and disadvantages of the framework next. 
Agile Scrum: Advantages and disadvantages 
Scrum is definitely one of the most frequently used out of all the frameworks of the Agile methodology, but that does not mean that it only has advantages, as we will explain below. It's an approach that is characterised by development cycles of fixed duration, known as Sprints, and by the optimalisation of development time for a software product. It is often seen in the management of development projects for software products, but it can also be used in other business-related contexts.  
Advantages of Agile Scrum 
  • The team's motivation 
The way in which the Scrum framework was designed tends to lead to motivated development teams. Sometimes, the lack of oversight and insight that very complex projects sometimes bring with them can be very demotivational for people working on the project. By dividing the project into many smaller parts, the project in question and its goals should become easier to understand for everyone on the team. Few things are more demotivating than unattainable goals in a business setting aiming for maximised efficiency, so setting realistic goals for Scrum teams will encourage programmers to meet the deadlines for every Sprint. 
  • Transparent in all directions 
One of the key words in the Agile Scrum framework is transparency. In many cases, this refers to an internal transparency within the team that is the result of team members very regularly communicating with the rest of the team in regard to important topics like the set goals, the way of working to achieve them, and potential issues they might be having. Another advantages of this mindset is that it can also allow the rest of the organisation to have a clear, unobstructed view into the Scrum team's processes and results. Like that, everyone in the organisation can closely follow the development of new features or products. 
  • Constant quality control 
Agile Scrum-based projects are focused on the people working on the project and providing them with the framework they need to delivery optimal product value for the customer. As a result of such projects being cut up into Sprints and each Sprint ending with a Review and Retrospective of the finished work and how the team handled the Sprint, quality control is basically constant. It's not hard to see how this can benefit the final quality of a delivered product. By closely inspecting each increment as soon as it's delivered, Scrum teams often end up with less mistakes when it comes to the final delivery of the product.  
Disadvantages of Agile Scrum 
  • We just stated that the division of complex projects into smaller Sprint is a big advantage for development teams, and this is absolutely true, but it does come with a risk. By segmenting projects in such a manner, it can happen that the development loses track of the project as a whole, of the big picture, so to say. The Scrum Master needs to pay close attention to whether he or she detects this in the team, because every product is developed for the benefit of the organisation, so during development projects, an understanding of the big picture needs to be maintained. 
  • One of the pillars of Agile Scrum success is cross-functionality. Scrum teams consist of people with different functional skills and specialities as they all work towards a common goal. This is an important step towards fostering independent and self-learning teams. The risk is that this approach can lead to insufficient role descriptions for the members of the Scrum team in question. This can lead to confusion and will surely have negative effects on the team's productivity and efficiency. 


Scrumboardy admin
Leave a comment