Get Agile Certified & Learn About The Key And Most Important Concepts And Tools Of Agile Project Management

By Piyush Kumar Jain

Large firms have a hard time employing agile and lean modes of working to their full potential because of their deeply embedded organisational processes and structures. With the help of this book, Agile Crash Book, you will be able to apply agile at scale. Agile delivery and project management.

• Language: English
• Publisher: Piyush Kumar Jain
• Release date: Nov 20, 2023
• ISBN: 9798869017437

Book preview

Introduction

Hello, and welcome to this book on Agile Project Management and Agile Delivery. As a project manager and coach for Agile implementation, I assist businesses to provide their clients with better solutions. The IT sector prefers to operate as agilely as possible, but as businesses expand, the characteristics that make Agile so successful and appealing tend to become more complex.

In this book, we'll propose a paradigm for using Agile at scale that takes advantage of both the economies of scale that come with big businesses and the advantages of small, autonomous Agile concepts. We will examine the benefits of implementing Agile at scale in businesses, the fundamental values and principles of an Agile scaling framework, as well as all the procedures, roles, and duties required to implement Agile at scale in your company.

After reading this book, you will be familiar with the advantages of an Agile scaling framework and all the essential ideas required for Agile to function at scale. This book is now a component of a wider learning path. The learning path will take you from a beginner to an expert over all the Books and provide a thorough explanation of the full framework for expanding Agile at scale. Let's get started on this book from Amazon called Agile Crash Book Agile Project Management; Agile Delivery.

The Benefits of Agile Scaling

Hello everyone, and welcome to the first chapter of the book Scaling Agile. An agile implementation coach and project manager for IT. Are you part of an agile team that finds it difficult to produce products because your organisation has so many dependencies and it seems like half of your time is spent waiting, or are you a scale-up organisation that is expanding and feels that your team's lack the agility and dynamism they once possessed?

If so, this book and learning path may be of interest to you since we will demonstrate a solution that gives you the quick decision-making and efficiency of agile teams while still utilising the economies of scale of larger enterprises. Therefore, if you successfully use this paradigm for scaling agile at scale, you get the best of both worlds. Agile at scale, as you can see, is a new organisational model that does away with the traditional organisational hierarchies and shifts to a decentralised model, giving nearly all the autonomy and decision-making power back to the teams in your business that are really creating the goods.

The framework offers the procedures, responsibilities, and roles required to coordinate all the teams and enable you to develop sizable, intricate, and integrated items. You might be wondering why go through such a metamorphosis, which obviously takes a lot of work and calls for employees to alter their perspectives and methods of operation. Agile at scale, however, has been around for a long time, and the advantages of an organisation undergoing the change are starting to become evident. First off, the architecture eliminates many of the dependencies that teams in large businesses have, resulting in a quicker time to market.

One of the guiding ideas is that teams should remain together for as long as possible in order to boost productivity and effectiveness over time, which results in an increase in production. The products' quality also improves as a result of the framework's built-in quality processes, and research has repeatedly shown that agile businesses have higher levels of engagement overall. People become more engaged when team-level autonomy is present, which has a positive impact on your organisation's turnover rate. One of the basic concerns we will address in this learning path is how agile at scale does this. The learning path actually looks as follows.

First, we have the book Scaling Agile Getting Started, which is beneficial to everyone who will be working in an organisation that implements agile at scale. In this book, we introduce the added value of an agile scaling framework and do an introduction of all the processes, roles, and responsibilities present in the framework. The book Executing a Team Iteration, which is written at a more intermediate level, will focus on all the ideas that occur at the team level when working in an organisation that uses agile at scale. Another resource for everyone working in an organisation that implements agile at scale is the book Executing a Programme Increment.

Additionally, we will focus on all of the programmatic team alignment that takes place in this book. When we move on to a more advanced level, we have the book Running a Large Solution at Scale, which focuses on all the alignment that must take place when you have a company working on some of the largest and most complex products available. This book is targeted at managers and coaches within an agile company. The next book, Managing the Delivery Portfolio, is geared towards coaches and executives and focuses on all the best practices for managing a portfolio of several agile solutions.

The book Advanced Topics in Scaling Agile, which is equally geared towards executives and coaches but focuses on the most intricate components of an agile scaling framework, is our last option. Let me now close in on this specific Book. The chapter on the benefits of scaling agile comes first. Then there is the framework required to build an agile company. Therefore, a company needs to have items like these, as well as lean, agile principles. The team layer of an organisation, the programme layer, the solution layer, the complete portfolio layer, and finally, the roadmap you will use to change your organisation from a traditional organisation to an organisation that employs agile at scale, will all be covered in the following sections.

Focusing on this specific chapter, we will first examine why you should utilise an agile methodology before examining why you require a specific framework to apply agile at scale. The foundational components of a framework for applying agile at scale will next be covered. The scenario that we will use throughout this learning path will then be introduced. Okay, then, let's begin working on these scores.

Issues of the Present for Delivery Organisations

We must first examine the problems that contemporary organisations are having with their corporate structures before we can discuss why an agile environment is great for your company and amazing to work in. Please don't think of this as a dry history lecture as I go on to illustrate why we need agility in our daily lives.

First off, back in the day, military personnel quickly realised that having one person, like the king, lead a sizable army alone was not a very practical strategy. There is this idea of span of control, and it seems that eight people is the magic amount that can be actively handled without losing too much cohesiveness. Therefore, if your squad or army has more members than, say, nine, you will need to divide them into several groups. And the first people to realise this were the Greeks and the Romans, who fully incorporated it into their army and enjoyed all the military victories that followed.

Now, this system is obviously quite top-down. You obey the person above you when they give you instructions. It scales beautifully, particularly if every soldier in the army is carrying out the identical action. Therefore, throughout history, this organisational form has been most prevalent. Then, in the early 1900s, a man by the name of Henry Ford realised that when creating considerably more complex things, like vehicles, this technique did not operate very successfully. You need professionals to make cars, but training specialists doesn't scale all that well. He therefore devised the production line. As a result, you let the car move through all the specialists in your company until it is eventually finished and tested as a whole.

Now, this works brilliantly for a well-defined product that demands specialised knowledge for each component. However, it is clearly specified beforehand, and by picking up new information quickly, they were able to master this system's efficiency. Everyone in the factory was giving 100% of their effort. People remained loyal to the system despite the work being rather monotonous because it was well paid. So when working on complex items that are described up front yet require specialised knowledge to produce, this worked fantastically. Okay, that concludes the history lecture. Let's now examine contemporary major organisations. They are designed to be a cross between the first two types. There is a CEO, and there are other departments. Consider three departments: IT, human resources, and legal. Typically, these departments are also divided.

In this instance, payrolling, hiring, contracts, and GDPR are among the chapters on development and operations. As a result, it is the responsibility of the managers in this company to ensure that everyone operates at maximum efficiency. This is referred to as a functional structure that is top-down directed. Now, the technique works just fine while producing intricate things. This is a great and extremely efficient approach to generate intricate products, as long as each department develops its own, which are fairly standard and clearly defined. This is where things go wrong now. Products are becoming more and more simple in today's world. Instead, we are heading towards complicated products, where complexity means that we are unsure of the exact appearance of the product from the beginning, particularly from the beginning.

We truly don't know how to go about creating such a product, and frequently, it calls for the knowledge of many organisational departments. As an example, consider software. Software is a complex product by all quantifiable metrics. It's quite difficult to know how to go about constructing such a programme up front, and it requires participation from all departments. Now, naturally, the managers of these departments, whose responsibility it is to keep everyone completely occupied with their work, call for a project manager to create a plan outlining when the project will require the expertise of their departments.

As a result, she creates a strategy and allocates resources to each step of the project. As a result, there can first be an initiating stage that calls for specialised knowledge. The next stage can involve design, which calls for additional knowledge. The project may go through a development stage as well as a legal review, which calls for the presence of both the developers and legal experts. We also have a testing phase that calls for diverse expertise. Finally, there comes the implementation phase, in which the product is actually delivered to the customer organisation. This phase calls for personnel from the operational side as well as contracts and GDPR. When these individuals are not working on the project, they are either busy working on other projects, working in their respective departments, or performing tasks for the line operation.

Now, in principle, this seems ideal, but in actuality, no project plan survives initial contact. The project you're working on will be delayed. So let's imagine, for example, that a problem arises during the project's development phase and that phase now requires additional time. The entire chronology then moves to the right. Since they were scheduled to work on other projects during that time period and were instead allocated to the legal check phase of the project, which has now shifted to the right, it goes without saying that everyone is upset. The project team members are furious because their work is being delayed. The employees of the GDPR department are irate because they are unable to complete their regular everyday tasks. We all know that projects are often delayed, yet the manager of the legal department is still upset with the project manager for poor preparation.

Therefore, the planning issue and the issue that everyone in a company is given 100% of their time are the first issues we encounter with modern firms working on complex projects. A second issue with current projects is that, let's say something goes wrong during testing and the customer doesn't like the product we are developing. In that instance, we would need to start our project over entirely from the planning stage because we would need to plan all of the expertise required from scratch at the outset. The system is therefore designed for a proper upfront design and then carrying out that plan, rather than for adjustments during the project. Let's take an example where we have a development team working on several projects as the third issue we confront. First off, there is our project, but they are also working part-time on three other projects that require different dependencies from other departments in order to develop the software for each one.

You can see how this would result in a lot of switching time, which is a problem in contemporary organisations, if the development team is working on four distinct projects and also needs to collaborate with other development teams within the organisation. Now, if you work as a developer in a contemporary company, you might recognise some of these terms. In conclusion, modern organisations certainly have challenges while producing complicated products. For the manufacture of products, traditional organisational structures are excellent as long as the items are complex but standard and explicitly defined up front. But there are some difficulties. First of all, managing the interdependence of specialists is challenging.