Agile Software Development
The ability to produce and respond to change is referred to as agility. It is a method of coping with and eventually succeeding in, an uncertain and turbulent environment.
The Agile Manifesto's creators chose the name "Agile" to represent the adaptability and reactivity to change that was so important to their methodology.
It's all about figuring out how to grasp what's going on in the environment you're in right now, identifying the uncertainty you're facing, and figuring out how to adjust to it as you go.
Agile emphasizes keeping the process lean and producing minimum viable products (MVPs) that go through multiple iterations before being finalized. Feedback is constantly received and applied, resulting in a much more dynamic process in which everyone is working towards a common goal.
Site Reliability Engineering (SRE)
Site reliability engineering (SRE) is an approach to IT operations based on software engineering. Software is used by SRE teams to manage systems, address problems, and automate operations duties.
SRE transfers duties that were formerly performed by operations teams, sometimes manually, to engineers or operations teams who utilize software and automation to address problems and manage production systems.
SRE is an important practice to employ while developing scalable and highly dependable software systems. It enables you to administer huge systems through code, which is more scalable and sustainable for system administrators who handle thousands or hundreds of thousands of machines.
How Has Agile Evolved with the Introduction of SRE?
Now that you understand what each term means on its own. You can see how the former has evolved to fit in with the latter.
Most SRE teams are made up of a combination of people with software engineering skills and operational emphasis, which implies that changing an operations organization into an SRE organization is a journey for the team and each engineer. During the transition from operations to SRE, team members learn about the other side from their counterparts to better cooperate toward a similar goal: running software with as little human contact as feasible. They'll handle events with the professionalism that their clients demand, but because the automation is handled by software, most SRE teams use agile development approaches.
When attempting to implement a specified concept such as Scrum, SRE teams rapidly find that it does not meet their working demands and abandon portions of it or quit practicing it entirely. Unplanned operations tasks make for a major portion of SRE work, therefore unplanned work might occur at any time and must be completed before anything else.
The agile methodologies have been applied, however, they need to be tweaked slightly to meet the SRE operations, does that make sense? No? Listed below are some Agile techniques that have been modified to better suit SREs. That will make things a lot clearer.
Retro Meetings
Retro is one of the most important practices for every agile team because it offers a chance to talk about the working style and to consider changing how the team runs.
It is something that an SRE team would adopt. Often, retro meetings are not deemed important. But for an agile team as said is one of the most important practices. It provides an opportunity to discuss the working style and propose modifying how the team operates. That involves deciding which practices are useful to the team and which aren?t. One prerequisite for this to work is that an agile working style should not be encountered by the higher-level organization. Every small team needs the flexibility to decide which working style works for them best.
Standups
Standup meetings are something the SRE?s don't like. SRE?s don't like unnecessary meetings as they would consume about 2% of the working time. But at the same time, it is important to know what other team members are doing to get a feeling about the overall direction of the team. However, doing this daily is not what an SRE would want.
So this can be practiced asynchronously, which means without a meeting. The retroes could be used to keep everybody updated about what the team is doing.
This is another Agile trait being evolved with the introduction of SRE.
Planning Meetings
The planning meetings (in the scrum, labeled "sprint planning" or just "planning") are critical for communicating which tasks will be focused on in the next iteration. But there is a lot of unplanned work in SRE, you may think it is pointless for SRE?s. It is kind of but at the same time you need to accept that is important to ensure the team knows what the priorities are. Sometimes it may happen that the production may influence the team priorities in short terms. In that case, it's better to run planned meetings more often to be able to adjust to changed priorities quickly. That does not mean committing to a sprint goal but talking about the stories with the highest priorities.
Testing
When teams create software, such software should be tested. There is no space for discussion. Although many individuals assume this, it does not reflect reality in software development or SRE teams. Many of the items that SREs create are for the purpose of automating operations duties.
When I make a change that may touch a large number of customers, I want to be confident that it will not disrupt production and cause an incident. A good test suite is the best way to build that confidence. What kind of tests are required to get this level of confidence is up to the team developing and executing the software, so you must reach an agreement with your team. In many circumstances, this will entail a set of unit tests as well as a set of end-to-end tests that run constantly to guarantee that the combination of all pieces works as planned.
Pair Programming
Onboarding new developers are difficult, and the onboarding process often worsens as a result of the pressures that team members are under a product that must be delivered, an event that needs additional eyes, a support issue that requires a prompt response.
In addition to onboarding, pair programming is beneficial. As previous research has shown, the team will not be considerably slower in the long run and will produce superior results. Pair programming, like testing, greatly boosts confidence in code modifications. The code unquestionably benefits. Collaborative observation and discussion with another engineer boost confidence in manual interactions with production environments and manipulation quality.
This is how Agile approaches have evolved to better suit the needs of SREs. There are other ways it has evolved, based on distinct practices and demands.
Paraphrasing the Agile Manifesto ? ?New, more cooperative and transparent ways of working are more important than following predefined agile frameworks.?