Agile Project Management And Requirements Gathering: Learn the Scrum agile Framework Including Agile Release Management, Scaling And Psychology Of Scrum Teams

By BHARAT NISHAD

While working on diverse project components, the various Agile teams must be coherent and in line with one another. This book, Executing a Programme Increment, teaches you how to set up various Agile teams inside an Agile Release Train.

First, you'll learn the steps and techniques needed to create many Agile teams. You will then be made aw

• Language: English
• Publisher: BHARAT NISHAD
• Release date: Oct 8, 2023
• ISBN: 9798868908750

Book preview

The Agile Release Train is boarded

Hello everyone, and welcome to our book on agile release management that reveals the value of Kanban and Scrum. The programme level of an agile at scale organisation, which organises agile teams of, say, 50 to 125 individuals working on the same complicated goods, will be examined in this book.

As the third book in this learning path, this book is also a component of the scaled agile learning path. Scaling Agile: Getting Started and Executing a Team Iteration was where we started. Following this book, we will continue with Managing the Delivery Portfolio, Running a Large Solution at Scale, and Advanced Topics in Scaling Agile. Since we will presume that you have followed this learning route throughout this Book, some of the concepts you may run into may have already been covered in the first two Books.

Now, in the team-level introduction to this learning route, we discovered that while organisations built on traditional hierarchies frequently result from historical events, they struggle to produce complex goods like software. You see, this traditional paradigm does not scale effectively as the goods become more sophisticated and require more people to work on them. It creates delays and conflict between the project teams and the line organisation. It necessitates a lot of overhead for resource management and encourages large upfront designs that make it difficult to make adjustments later on in the process. Therefore, we discovered that working with small, agile, independent, autonomous, and reliable teams is preferable.

As it turns out, however, simply setting up your teams in an agile manner and announcing team-level positions like a product owner and a Scrum master is not sufficient, as each of these positions will also have their own style of operation. If they are to collaborate, we will need to be in agreement on whether they are working with the Scrum/XP method or the Kanban method. Second, we must plan which team will work on which component of the final product. For example, each component of the intricate product we are trying to develop might need specialised technical as well as specialised subject knowledge. Finally, there is the product's vision. Five different teams would have different ideas on what this autonomous electric car should look like, and their answers might be very different from one another. Therefore, having some product vision can be highly beneficial when developing huge, complex products. But in this book, we'll talk about the ideas at the programme level that are required to simplify precisely these problems. We'll discuss programme level iterations known as programme increments as they relate to alignment.

We'll discuss the agile release train, which is the method used to deliver these substantial, complicated solutions and encompasses the procedures and practises required to achieve the required alignment. We will discuss work distribution, where we employ a single programme backlog that is broken down into user stories on team backlogs. We'll discuss Kanban at the programme level. The supporting roles that are present at the programme level will then be covered. We're going to take the following strategy in order to organise this book. We'll start by discussing the idea of an agile release train. The work distribution system will then be discussed. We shall discuss the many rites that will be performed during the programme increment.

We'll discuss DevOps and how it's incorporated into an agile at scale implementation at the programme level. We'll discuss the continuous delivery pipeline, another key idea in providing value to your customers. We will also discuss the idea of architecture and how large delivery organisations might improve the technical alignment between teams. The ART organisation and the many coordinating responsibilities that are present on the programme level will be the final topic we discuss. Okay, then, let's begin reading this book.

Welcome

The book as a whole will therefore cover the programme level, but this chapter will concentrate on the idea of an Agile Release Train. Looking at the big picture, we can see that the programme level Agile Release Train assumes a major position.

This is so that several agile teams may coordinate, organise, and assist one another while they collaborate on huge, complicated projects. This is known as the container concept. The Agile Release Train is what we refer to as. We will now focus on the following subjects as we examine this Agile Release Train and see how it may be used in large enterprises. The role of the Agile Release Train inside an agile organisation comes first. We will therefore examine how the ART connects to the various agile teams as well as how it relates to the larger value streams that are concentrated on developing even larger products. Any team that includes more than 150 individuals working on the same project. The cadence and iterations follow.

At some point, we'll need to figure out how to get each of these teams to incorporate their contribution to the final product. We'll look at how to set that up since it's simplest to utilise the same cadence for each team. Then there is the final iteration that happens at the conclusion of each programme increment, which is frequently overlooked but is quite significant. That is the iteration of innovation and planning. We will focus more closely on this unique iteration.

Finally, we will examine various Agile Release Trains in this chapter. Others may be more technically oriented to ensure that alternative solutions are developed more quickly, while some may be more interested in developing features for the clients. These are referred to as facilitators. Okay, let's get this chapter on the Agile Release Train going.

In an Agile Organisation, an ART

Okay, let's now discuss the Agile Release Train. This is the most popular term for a container that includes all the procedures, customs, and roles and describes how they all fit together to allow several agile teams to collaborate on a substantial, complicated project. However, you might be wondering how this differs from a typical organisation.

First of all, it's evident that the traditional organisation works on huge, complex items as well, typically in a project forum. After that, workers from several departments join the project to begin developing the finished product. So there might be individuals from the hardware and software industries. The project also has a security component. The product may be worked on by individuals from the business control side, and it's possible that many more departments may be required to produce a truly sophisticated final product. However, as we discovered, this strategy has certain shortcomings in terms of team communication, resource allocation, but also integration. You are undoubtedly already aware of the fact that the integration of the product's many components is what consistently causes delays. So let's look at how an ART differs.

An ART is, first and foremost, a team of teams. We therefore have numerous teams working on a single product. Keep the span of control principle in mind. People can only effectively communicate with eight people around them, but the ART tries to take advantage of this by assembling small teams and coordinating among them, which is why we established all the procedures and rituals that make up an Agile Release Train. Therefore, an Agile Release Train often has between 50 to 125 individuals when we talk about a team of agile teams. If you have a larger value stream and more employees, you may want to explore breaking them up into numerous Agile Release Trains. If you have fewer employees, an Agile Release Train may not be necessary, and you might be better served expanding your agile practice at the team level. For instance, you can coordinate between the various teams using the scrum of scrums. All of these things can, of course, also be accomplished in a typical line organisation. The teams in an Agile Release Train are cross-functional, which is the primary distinction. Determining the product, creating the product, testing the product, and deploying the product are all tasks that fall under the purview of the teams. And they keep doing this in successive versions until the final product is ready.

The fact that the teams last a long time, though, is another significant contrast. That implies that the teams do not get together for a specific project and then break apart after it is finished. No, we keep the teams together and assign them work from a backlog, which is then assigned to the teams. As a result, they might work on one product for a significant number of iterations before sticking with the same teams to begin developing the following product. This is what we mean when we talk about long-lasting teams and an agile release train. Getting synchronisation across the various teams is the second benefit of the Agile Release Train. Since each of these teams is cross-functional and autonomous, they can all make decisions, but we must ensure that everyone shares the same understanding of the product and is working towards the same end result.

First off, the cadence is the same for every Agile Release Train. In order to maintain a rhythm across the various teams, an Agile Release Train has two-week sprints that begin and conclude at the same time. But we also have iterations at the programme level. These are referred to as programme increments, and a programme increment is an interval of 8 to 12 weeks during which various teams' plans are carried out. When it comes to team integration and communication, having the same cadence and making sure that every sprint and programme increment start and end times are consistent for all teams offers a lot of value. Take the supporting procedures that occur on the Agile Release Train, for example. There is a PI Planning event that occurs prior to the commencement of each programme increment. The programme backlog items are distributed among the several teams at this time, and each team also determines the dependencies that will exist in the future programme increment. Then there is the integrate and demo routine, when the teams meet to integrate the final product and ensure that all the components each team is developing work well together as a whole after each iteration inside the programme increment.

Last but not least, we have the inspect and adapt session, which takes place at the conclusion of each programme increment. During this session, all the teams review the previous programme increment to see if there are any changes that could be made to improve the process as well as to identify any successful elements that can be carried over into the upcoming programme increment. Last but not least, the architecture that is developed within an Agile Release Train is one of its crucial components. The teams should focus on this since it gives them a solid basis from which to build products for the organisation's clients. In order to ensure that synchronisation and coordination between the teams are achieved, a team must engage in a number of processes that make up an agile release train.

On the programme level, we do have a few supporting roles that assist the agile teams with all of these routines, though, in order to achieve this. First, there is product management, which functions somewhat similarly to the product owner at the level of the Agile Release Train. He or she handles the backlog of programmes. The system architect is a member of the agile team who assists in building an effective architectural runway. The Release Train Engineer is a kind of super scrum master who manages the teams at the level of the Agile Release Train. Then there are the business owners, who are genuinely stakeholders on the business side and ensure that the goals of the organisation