Thusi Hettigama is a Manager in the Project Management Office at Green House Data and a DevOps enthusiast. Follow him on LinkedIn.
Last week 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.
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.
The following are a few examples to help you to reposition a traditional mindset to accommodate the Scrum approach.
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.