Is it Agile, Scrum, DevOps or is it SAFe?

What is the difference between Scrum and Agile? Can I combine Agile with PRINCE2? But isn’t that Lean you’re talking about now? What about the Spotify way of working and DevOps? And what is Kanban or eXtreme Programming? As a large organization, do you have to implement SAFe? Is Agile only applicable in IT?

These are all questions we hear a lot at the start of our training courses or from organizations that are looking for the right training and Agile certification for their employees.

It is time for the next step in maturity of the Agile way of working. Scaling up, with the right energy we will get there, although that will not happen by itself.

Agile is used as a term for the way of working and can be seen as an umbrella term including Scrum, but also Kanban, eXtreme Programming, Nexus, Scrum@Scale, Scaled Agile Framework (SAFe), Spotify Way of Working (WoW), DevOps, Large Scaled Scrum (LeSS), DSDM Agile Project management, PRINCE2 Agile and Lean Startup are covered.

Whether you choose Agile as a project approach or work Agile in the line organization, the basis is formed by the self-organizing teams that create value by working with Scrum or Kanban. Or perhaps a combination of both. The Agility / Flexibility is mainly found in the delivered results, where progressive insight, learning from mistakes and experimentation lead to. Start with a Minimum Viable Product (MVP) and use feedback to build valuable products and services.

When scaling up Agile in larger organizations, teams must coordinate their activities and they must also join the existing, operational organization. Agile is also used outside the IT organization these days. The methods used differ per organization and it strongly depends on the culture and management of the organization. Terms such as Leadership, Alignment and Governance are increasingly emphasized in the Agile implementation or transformation to the next step in Agile maturity.

The basics, self-organizing Agile teams.

In small (starting) organizations you can work fine with the Scrum framework or Kanban without having a method or extended framework defined around it. Either as part of a project organization or within the Agile line organization, these basics with self-organizing teams will work as described below.

Scrum is an Agile framework aimed at a team that develops (software) products based on a defined and prioritized list of functionalities, the Product Backlog. The functionality and priority is determined by the Product Owner in consultation with the business and other key stakeholders. The Scrum Master guides and monitors the team and the process.

Scrum’s rules mainly focus on teamwork and the division of roles between Development Team, Scrum Master and Product Owner. Iterations called Sprints have a fixed time frame. Sprints are used jointly, in which the planning, execution, review and retrospective (Plan-Do-Check-Act) ensure a potential product increment to be delivered. Download the Scrum Guide at Scrumguides.org.

Kanban is simpler in terms of agreements than the Scrum framework. With Kanban it is especially important that we have a clear understanding on the status of the work in progress. This work, planned or unplanned, is visualized on planning boards, just like with Scrum. There are no roles and there is no iterative process. Ideal for performing line activities where not too many different things should be performed at the same time. Keep Focus and limit the work in progress (Work in Process — WIP Limit). The only thing that needs to be monitored in addition to visualization and focus to comply with the Kanban rules is the lead time. If activities take too long, we probably have a bottleneck or a blocking factor. We can experience waste in the value stream. The use of Kanban provides insight in the value stream flow. Add a biweekly feedback session, a Retrospective, to improve the process and the output, and Kanban will be a successful method for teamwork.

eXtreme Programming (XP) consists of a number of techniques that are applied in system development in an Agile environment. Pair Programming, Test Driven Development, Automated Testing and Continuous Integration are examples. Scrum and XP often go hand in hand, especially in software development.

Henrik Kniberg made a very nice animation in 2012 in which Scrum, Kanban and XP are briefly explained from the perspective of the Product Owner. This animation can be viewed on Youtube: Agile Productownership in a Nutshell.

Scaled Agile, which approach do we choose?

If several teams in the organization have to work together or have interdependencies, the Scrum-of-Scrums is used for coordination. A representative from each Scrum team attends the Scrum-of-Scrums stand-up. This can be a weekly stand-up with your own Scrum planboard, but other arrangements are of course also possible. At Scrum.org, a more extensive collaboration of Scrum teams is described as Nexus, but you can also opt for Large-Scaled Scrum known as LeSS, or Scrum@Scale which is developed by the Scrum Alliance.

Line organization

If your organization changes, improves and renews products and services mainly from the line organization, and the maintenance is carried out on existing products by the same teams, then SAFe is a very common choice. DevOps is used for Agile Delivery within the SAFe framework but can be used perfectly as a stand-alone way of working as well. DevOps automates Continuous Integration and Deployment CI/CD in the delivery pipeline. Besides automation DevOps addressess organization, culture, processes (Lean and Agile) and Continuous improvement by measuring.

As part of this choice for SAFe we work with Scrum or Kanban at team level. The methods mainly concern scalability, coordination across multiple autonomous teams and connection with the operational organization. Management determines the direction the organization is going, focusing on the best Customer Value. Management should be particularly facilitative towards the self-organizing teams and make sure to set the right priorities.

The Scaled Agile Framework (SAFe) describes the (IT) organization surrounding the Agile delivery in releases (Release Trains) with multiple Scrum or Kanban teams. The releases must be well integrated from different teams and also connect well with the existing operational organization. This continuous process of integration and delivery is called the cooperation between Development and Operations, or DevOps for short. The highest level in the organization, the Portfolio level, focuses with Lean Leadership on the value streams and facilitates the underlying levels in the Agile way of working. SAFe has many different roles and to properly implement this, the IT organization must at least consist of 150 persons. See http://www.scaledagileframework.com

In contrast to SAFe, the Agile Way of Working of the well-known internet music service Spotify is more accessible to small (er) organizations. The teams are called Squads and they are organized in Tribes. A Tribe is focused on a Customer Value Stream. People with the same kind of functional role from different Squads form Chapters. These Chapters provide knowledge sharing, cross pollination accross teams and are led by a Chapter Lead with HR responsibility. This can lead to a Chapter for software testers in which testers from different Squads within a Tribe work together.
Another way of organizing within Spotify are Guilds. These Guilds are groups with a certain interest and are formed from different Squads and Chapters, accross Tribes. For example, a Guild can be started to find new tooling around automated testing. You can actually see the Spotify model as a matrix organization with an emphasis on autonomous teams, the Squads. The role of Product Owner has been defined, just like with Scrum, but there are no Scrum Masters at Spotify. The guidance of the Agile process is taken care of by Agile coaches. Henrik Kniberg has put the Spotify way of working in a beautiful animation on Youtube, a must-see : Spotify Engineering Culture

DevOps is rapidly emerging and becoming increasingly popular. DevOps is described as part of SAFe but can also be implemented independently, just like the Spotify WoW described above. Both are especially applicable in smaller IT organizations and organizations that don’t need a lot of governance. The organizational aspect where autonomous teams have to work together according to the motto; “You build it, you run it” ensures that there is as little transfer as possible. The teams therefore not only develops (Dev) the products in an Agile way, but also provide operational services (Ops) on the same product.
In addition to the collaboration in autonomous teams, other principles have also been described in DevOps. These principles focus on culture, customer value, Lean product development, continuous learning and improvement, and rigurous automation. The latter principle applies to the automation of the various Tests (feedback of quality), the automatic continuous integration and delivery (Deployment) and the ability to automatically provide the right environment (Provisioning) for the Agile change. Provisioning is linked to the provision of Cloud services.

Projects

With a small-scale complex change, you can pick Scrum or Kanban as your framework, that works fine. If it is a larger complicated project, possibly with multiple teams, a more complete approach with (PRINCE2) Agile Project Management makes it more controllable. The coordination (overall planning) and the risks are monitored by the Project Manager and he / she ensures that the project comes to a successful conclusion. Projects are finite in contrast to what has been described above in the Agile line organization. The reason for working in Agile projects is mainly because activities have to be coordinated across the value stream or if there is temporary cooperation with other / multiple organizations or organizational units. A Steering Committee or Project Board is formed to make decisions and guide the Project Manager.

Agile Project Management (Agile Business Consortium — DSDM) is a complete method for managing Agile projects. In advance we outline what the Scope of the Project is, and which risks and Business Case (reasons, objectives, benefits and investment assessment) we have. The important decisions are made at project level by a steering committee that includes the Business Sponsor (client), Business Visionary (senior user), Technical Coordinator (senior supplier) and the project manager (this is different compared to PRINCE2!). The project manager plans which parts of the final product are made by which teams and in which time units (increments) results are delivered and released. A self-managing team with a Business Analyst, Business Ambassador (s), Solution Developer (s) and Tester (s) could work according to Scrum iterations (Sprints). Within the AgilePM method, the iterative way of working is also included in “Structured Timeboxes”. More information can be found on the website of the Agile Business Consortium.

If you want to combine AgilePM with Scrum, a good white paper is available with the Scrum terminology and the Scrum roles integrated in the AgilePM method: The DSDM Agile Project Framework for Scrum — Whitepaper (UK — Google Drive download 1.17Mb)

If your organization has invested heavily in PRINCE2 as a project management method and in the education of project managers who work with PRINCE2, it is possible to make the combination. PRINCE2 with Agile. For example, to deliver a work package as a team in a Scrum way.
The pitfall with this combination is that too much detail is specified in advance, you will then loose the flexibility of the Agile Scrum approach. The PRINCE2 Agile manual (read PRINCE2 with Agile), is a very comprehensive and complete description of the tailor-made combination. The manual describes the pitfalls and possibilities of Agile working with PRINCE2. PRINCE2 Agile is the combination of PRINCE2 project management with Agile Scrum, Kanban and Lean Start-up. The Scrum Guide is included as an appendix in the manual. The explanation of the Minum Viable Product (MVP) in iterative product development is derrived from Lean Start-up. In addition to external framework references, the “Agilometer” assessment tool is part of the manual. With this tool, the risks and benefits can be measured from an Agile perspective. The crucial question “what to fix and what to flex?”, referring to the project variables time, money, quality, scope, benefits and risks is explained in an excellent way. The explanation is represented by the PRINCE2 Agile Hexagon.
Where DSDM Agile PM uses its own vocabulary, PRINCE2 Agile uses the well-known terminology from PRINCE2, Scrum, Kanban and Lean, making it a complete project management method that you can rapidly implement. More information about PRINCE2 Agile can be found at AXELOS.

Practical experiences

In organizations where we actively coach the transformation or next Agile maturity steps, we often experience the struggle between Agile projects and Agile in the line organization. Projects take people out of the organization to do the project work. The Agile message is that you have to bring the work to the people. That is a different approach. A different way of managing and an other way of funding.
The trend is to start fewer projects and execute more changes in permanent available Agile line teams. From project thinking to product thinking!

So, choosing a method or framework is not easy. With our experiences we can help you as a consultant, trainer and Agile transformation coach. To receive more informatio or to book a training, consultancy or coaching, please contact info@ctrl-improve.nl