Understanding Scaled Agile Framework

As companies aim for digital disruption, implementing change as fast as possible is integral. Agile Development allows for timely feedback and quick iterations. While this is easy for small companies to achieve, it may be more difficult for larger organizations. This is where Scaled Agile Framework can help. Below is a transcription of a Business over Breakfast meeting discussing the importance of Scaled Agile Framework (SAFe). Dan Williams presented to the whole team at CIL – so we transcribed it to share it with you. This is part one of a two-part series.

Agile Development vs. Scaled Agile Framework vs. Waterfall

What is Agile Development? It’s a rapid prototype development where you’re building things while constantly seeking customer feedback. This helps ensure that you’re building the right product and that it will meet the needs of the customer you’re building it for. Scaled Agile Framework (SAFe) is doing that on a massive scale when you have large businesses that have 20 developers and 100 people on their software development team.

In contrast, there is the waterfall model, where you specify everything upfront and then you build it out.  Over the course of time, companies have found that this model doesn’t work well because customers aren’t confident of all the features they want upfront. Waterfall doesn’t allow for the constant cycle of feedback that can be necessary for development projects.

The main thing that you try to solve when you’re doing scaled agile, specifically DevOps, is the business wants to validate quickly what the customers need. You need to be able to build it quickly and release that value to the business when the customer needs it. In traditional processes, this is very difficult to do quickly and release into production. Quickly, without error and without bugs is difficult if you don’t have some of these DevOps protocols in place.

What is DevOps?

When we talk about DevOps, we mean a culture and a practice between software and software operations, where you’re consistently delivering business value to the customer. A software developer will tell you it is automating the software development process. For example, we might push our code to the Git repository which will automatically deploy our build to a staging server on certain pushes or pull requests. That’s a really small snippet of a DevOps protocol that we’re automating because traditionally the Git repository is only for saving.

Releasing that code is a completely different matter, I deployed to staging but you may do it manually. Well, now that we’ve automated it if I pull it into a specific branch of staging it will deploy automatically for me. This means we don’t have any manual intervention and it will just do it for us. That saves a lot of time and effort. Anytime you’re doing something manually, you have the possibility of making mistakes.

Differences Between Small & Large Organizations

There are quite a few differences between small and large organizations in employee roles, how the company is structured and what the development team is responsible for.

In a startup or small company, as a developer, you’re doing everything:  you might develop the product, release it, AND maintain it. You’re also responsible for any bugs.

This process is split up in large scale enterprises. You have a business team and a software development team that will build the product. They hand off to the operations team and the operations team deploys, maintains and makes sure that it’s running. If there’s a problem, operations will handle it. As a developer, you really know the software. You understand what should happen and how it should function. When you’re handing it off to an operations team to deploy and manage, they don’t really know very much about it because they didn’t build it. This can create a feeling of misalignment where teams aren’t moving towards the same goal.

CALMR Approach to Agile Development

We’ve discussed how teams can be misaligned above if not everyone works together. When you’re using a Scaled Agile approach – it is a more holistic process. They use the acronym CALMR which is explained below.

Culture: The culture shift is huge when you’re talking about Scaled Agile. Feedback has to be provided on a consistent basis, confirming the features being built match needs. It creates a shared responsibility for the development throughout the team. Culture stays positive because the entire team is invested in the end product.

Automation: Difficult to deliver products quickly with high quality if you don’t have automation in place for running tests and moving code.

Lean Flow: Small batch size to push to production faster and create more visibility into the process.

Measure: Measure each step in the process to make sure what is getting built is achieving the set goals and benchmarks

Recovery: Easier to recover because you assume a lower risk when releasing in small batches and implementing automated testing.

Roles in Agile Development

The diagram above shows the workflow for Scaled Agile Framework. Each person has a role including Development, the Scrum Master and the Product Owner. This framework also shows the backlog and planned sprints for the project. If your business is software, everyone on the team needs to be aware of these roles.

What is a Product Owner?: someone that bridges the gap between the customer and the development team. Validating and deciding what will be built.

What is a Scrum Master?: They run the daily stand up and their primary goal is to make sure there are no impediments to the project. They are the communication agent and coordinator between projects and teams.

What is a Stand-Up?: A meeting for developers to identify what is done and what still needs to be completed.

What is a PIP?: Program Implementation Planning. It is essential for Scaled Agile Framework. A PIP is planning out your sprints for three months. You decide on the work you’ll do for this period of time. You’ll split that three months up further into two-week sprints, divvying up the work. You’ll then plan a retrospective at the end of the two-weeks and plan for the next sprint.
The PIP is the biggest meeting a team will have and will include everyone from the business side and on the development side. The goal is to decide on priorities and internal planning so that everyone is on the same page.

The Importance of Continuous Testing

One thing crucial to delivering software rapidly is automated testing. Any bugs or issues with software are discovered when you have automated testing and you run into fewer last-minute problems.

Automated testing is crucial if you’re rapidly deploying software because you cannot manually test fast enough. Especially in an enterprise system for a large company.

Stay Tuned

Part 2 of this series is coming and will dig into even more of the Scaled Agile Framework.

[This blog was transcribed from a presentation and edited for clarity by Erin Srebinski]

Keep Reading

Share on social
Email
Facebook
Twitter
LinkedIn
Pinterest