Agile Scrum in DevOps Ecosystems, Part Two

Thusi Hettigama is a Manager in the Project Management Office at Green House Data and a DevOps enthusiast. Follow him on LinkedIn.

In Part 1, I introduced key agile concepts including the history of and essential roles required for Scrum practices. I described a real-world example of how DevOps could have saved my organization major headaches and expenses.

In Part Two of this post on using agile Scrum methodology within DevOps ecosystems, we'll examine the Four Values of Agile and learn how to change your organizational mindset to accommodate this new paradigm.
 

The Four Values of Agile

Scrum follows a set of agile values and principals. Let's understand the four values of Agile Manifesto and how we can apply it to a Scrum project.

1. Individuals and Interactions Over Processes and Tools

Traditional projects encourage and depend heavily on processes and the tools. The teams are forced to stick with already established procedures. If team members run into challenges due to the inflexibility of the processes and limitations of the tools, it is hard for the team to move forward.

Agile organizations allow teams to work collaboratively without being confined to tools and processes. The teams working in agile Scrum environments can make decisions by initiating interactions directed towards solving their project goals. The teams are not limiting themselves to boundaries set by the processes and tools.

2. Working Software Over Comprehensive Documentation

We have witnessed many traditional projects that include the creation of extensive documentation as a part of the solution delivery, such as Project Charters, BRDs, System Design documentation, and testing documentation required by the PMOs. This documentation is  considered a must-have checklist artifact of the delivery.

However, in Scrum agile, the focus is more on the solution and the documentation is considered a light-weight output. Traditional PMOs should adjust by to removing documentation requirement barriers and encouraging more and more conversations around bringing value to the solution with amplified feedback loops. PMOs also should allow the Product Owner flexibility to determine the extent of the literature needed for the project.

3. Customer Collaboration Over Contract Negotiation

The end goal is to bring the product to the customer as quickly as possible without compromising the quality. We have all experienced how hard to it can be to get through Statement of Work and Change Requests. Approval processes and negotiations sometimes drag into months in business world contracts. While protecting the organizations from legal aspects, contracts and agreements need to have some flexibility as long as the product is evolving in the right direction.

4. Responding to Change Over Following a Plan

In the modern business world, change is a constant. However, in the traditional software development process, business requirements were necessary to define before any development begins. If we are working in a perfect world, this sounds reasonable.

However, in every project, there is a high chance of missing essential requirements, while unexpected changes in upstream sources could change the whole game setting. In many organizations, the change process to accommodate missed requirements is tedious. Organizations intentionally create resistance to discourage change.
 

Changing Your Mindset to Accommodate Scrum

The following are a few examples to help you to reposition a traditional mindset to accommodate the Scrum approach.

• It is essential to understand that any project status update is only as valid as the information available at the time.
• It is challenging to predict the percentage complete compared to the end-result after every sprint. Scrum uses the estimating technique referred to as the Story Point. Story Point calculation is one of the areas of Scrum where people get confused. In Story Point, instead of looking at a User Story and estimating in a traditional way using a unit of hours, Scrum teams consider only how much effort a User Story will require, relative to other User Stories.
• It is impossible to project the number of changes that a project needs to reach the final product. Therefore it is difficult to provide a cast-iron guarantee on the cost.

Every organization exists within an ecosystem. In this ecosystem, the development and the operations teams must work collaboratively. DevOps strategies help to close the gaps between the development and operation teams to enhance the velocity of delivery.

Agile principles are one of these strategies that would bring a collaborative, high-performance team approach to an organization. Therefore Agile and DevOps work better in combination, complementing each approach within the organization ecosystem.