Adoption of the agile methodology is essential to the success of a DevOps culture. This is not revolutionary, but is an important foundation.
We view agile as the tool for developers to achieve DevOps. Our team, which is developer-centric, is focusing on the agile piece of the equation moving forward.
But what happens when you think you have a grasp on the agile methodology but it turns out you were completely wrong?
A change is needed.
Getting back to the Agile Manifesto is a great starting point. This is our story of DevOps failure to success by implementing the correct agile methodology.
Our Perception Was Wrong
When thinking about the agile methodology, and, to a greater extent, DevOps, open communication is at the core. However, it is not the only thing agile and DevOps is.
At the beginning, we thought as long as there was open communication we were agile. Seeing as we sat in the same room, this was pretty simple. But we quickly learned that this was not agile, and the revelation was painful.
As we experienced development bottlenecks and difficulty in defining responsibilities, we knew there needed to be an adjustment in how we viewed the agile process. Also, we had begun adopting projects in areas where we did not have a high level of expertise.
This is what brought us back to the drawing board.
Getting back to the basics meant looking at the reason for implementing agile in the first place. For us, it was releasing better software, more often, with fewer updates. In detail, it was looking at how long it took the team to identify and define the need. Then, it was looking at how long it took from problem definition to software release. We consider this one software cycle.
The reason for implementing agile is to decrease the time it takes to move through one of these cycles, as well as to decrease the number of cycles on any one project. Defining this process to the team is how we brought our software development back to the basics.
Renewed Focus
Once there was a renewed focus, it was time to implement a set of tools and processes. The concepts we focused on incorporating are the following:
- Adoption of sprints
- Open communication
- Version tracking
- Environment of continuous testing
- Responsibility definition
None of these are particularly revolutionary, but when implemented effectively, it made a world of difference. Once we defined these five areas of focus, we adopted the daily sprint meeting. This implementation was the core of our transformation into a truly agile environment.
The Daily Sprint Meeting
In the developer environment, meetings can be against the team culture, especially in a startup. This is why a meeting needs to be strategic. The daily sprint meeting should have both a question constraint and a time constraint. The result is no dragging meetings.
The two metrics for the daily sprint meeting are: 1) each team member gets two minutes to speak, and 2) four questions need to be answered. Those are:
- What did I accomplish yesterday?
- What will I achieve today?
- What obstacles do I face to accomplish my projects?
- How am I feeling today?
With a team of five people, this meeting should take 10 minutes at the beginning of each day. The adoption of the daily sprint has helped us achieve a level of focus not possible without it. This focus has produced increased productivity, as well as adopting an effective agile environment.
The daily sprint meeting is how we successfully implemented a DevOps culture. This has made all the difference within our team.
About the Author/Logan Rivenes
Logan Rivenes is a Marketing Manager with Datapath.io, specializing in decreasing latency through network traffic optimization for DevOps.
Twitter: @loganrivenes
LinkedIn: https://www.linkedin.com/in/logan-rivenes-01a8964a
