BrazilThree areas that need to be addressed for implementing agile working
Becoming agile has in recent years grown to become an indispensable transition for companies across Europe. Rik Pennartz, an Agile coach at Capgemini, says that the question is no longer “does agile need to be embraced”, but instead “how can agile be adopted”? According to the expert, successfully implementing agile working requires focussing on three main areas: organisational change; cultural change; and technical change. Pennartz shares his vision here.
Organisational change
Start an agile transition with the formation of multidisciplinary, full-time, dedicated agile teams and have teams practice with Scrum and Kanban. Gain experience in agile ways of working. In certain areas it will be fairly easy to form successful Scrum teams, such as those working on front-end applications, without many dependencies on other departments. In other departments it will be harder to form autonomous teams, because of the interdependence with other teams. The goal of agile teams is to deliver customer and business value by building a shippable product increment at the end of each sprint. This is a journey that they will make with many improvements along the way.
During the sprints, there should be increased cooperation with the system operations teams and at a certain point it should be possible to form DevOps teams, where all development as well as operational tasks are performed. These teams will have end-to-end responsibility for a service or product. They build, test, and deploy new features into production and also maintain them.
Create various flavours of teams: some will be responsible for services and features that will be used directly by end-users (called feature teams), while others build the underlying infrastructure, tools and routines that can be used by the feature teams. The latter are often called platform teams.
Teams usually have several dependencies with other teams, either because they work on the same product or because they use the same resources. This makes changes to systems much harder, as it requires a lot of up-front coordination. Try to make teams as autonomous as possible. To prevent endless coordination efforts ending up once more in waterfall staged projects, it is essential to ensure that agile teams can work autonomously but still coordinate sufficiently with each other to manage dependencies and perform frequent integration of their deliverables.
In the past new projects and change initiatives were commonly established by defining business cases and project plans, then projects could start after formal approval by a project board. Today, innovators instead visualise many small changes in a product or service. These could be considered as mini projects. The primary process for delivery of a product or service is called a value stream. Take a “mortgage” value stream as an example – all the steps that are required for a bank to deliver its mortgage product to a customer.
In the agile way of working the first step is to define the products or services which need a certain amount of innovation and then view the total available innovation budget. How much budget is available for the “mortgage” value stream must then be established before dedicated agile development teams are set up. Teams can be organised around products or services, but also around systems that handle transactions for several value streams. In this way the budget is “fixed” and the teams must strive to deliver as much value as possible in the shortest amounts of time. At this point value streams instead of projects have now been budgeted. Also consider the role of management in decision making during development. Define moments when official approvals are required. Redefine the way auditors and change advisory boards work, so as to avoid inhibiting the agile teams while still retaining a certain level of control. Define how to make the systems auditable.
Spread the news
Once a team has gained experience and celebrated their first successes it is time to spread the word to other teams and have them also set up agile units. For some teams Scrum will be a great method, whereas for others Kanban will be more suitable. For some changes traditional project management will be perfectly fine. If the team feels it is important to receive frequent feedback from users and other stakeholders during demos, Scrum is probably the best method, but if the nature of work is more characterised by short, rapid fire, ticketed tasks, then Kanban might be the way to go.
Many people will not be convinced that all this reorganisation is necessary or that this new way of working is better. Many people need “proof” that all the fuss is worth it and need to understand why action is being taken.
Training
As the news spreads, people need to be trained in agile methods and role fulfilment. There will be new roles such as Scrum master, release train engineer and product owner and people need to have a thorough understanding of what these roles encompass. They benefit from workplace coaching. Agile team members need to be able to fulfil various roles, or at least have a deep understanding of other roles. This will enable them to assist others in their tasks and to solve problems together, which will lead to more team autonomy.
Top management should lead the way
A crucial role is laid out for top management. Commitment from higher management is critical for the success of the agile transition. Strategic, difficult decisions need to be taken, and top management needs to initiate the cultural transition that is required. Cultural change is empowered from the top and not from the bottom of the organisation. It is important that C-level roles thoroughly understand the consequences of the agile way of working. This might be hard: management will have to delegate more responsibilities to product owners and agile teams. They will have to stop demanding projects with fixed time lines, fixed budgets and fixed scopes. They will have to start thinking in terms of product based budgets instead of project-based budgets.
Top management should lead the way by setting the right example. One concern for management is losing control with agile ways of working. However, because of the cyclical nature of development, with reviews and demos at the end of each sprint, management is able to give feedback, control and adjust what the development teams will work on in the next sprints. Instead of losing control, management can check progress and adjust development much more frequently.
The role of management in an agile organisation should be:
- Vision development and setting strategic goals
- High-level, strategic decisions
- Enabling autonomous teams
- Enabling shared consciousness through:
- Extreme participatory transparency (e.g. open physical spaces; holistic awareness)
- Strong internal connectivity across teams (create connections between teams by embedding and liaisons)
Cultural change
For an organisation to become agile it must have small, high-quality, autonomous teams who can take decisions swiftly and accurately. Organisations become flatter and management should facilitate and enable these autonomous teams. Teams do not work in isolation, but communicate and plan together, so they can keep a holistic view of the organisation. An open culture is required where teams can experiment, self-organise and learn quickly from each other. Teams should take joint responsibilities and there should be a culture of sharing knowledge.
Failure
There is a lot to do in the agile world around failure and making mistakes. An important aspect of an agile culture is the way mistakes are dealt with. To be clear, making mistakes is not acceptable if the consequences are “lethal” to the company or if lessons are not learned from from them. It is easy to say to employees that they must experiment and become more autonomous, but that is going to be very hard if the effect of a mistake is detrimental to the company. In a fast-paced, complex world, it is important that teams are allowed to experiment and test their ideas. It should be possible to make mistakes, even if sometimes the consequences are bigger. Many small mistakes probably create a bigger learning experience than one huge mistake. Importantly, mistakes should never be a “one-person” fault. Teams working closely together should share responsibility for mistakes made by one member. It is essential to find ways to make systems and organisation more resilient, so that one mistake will not topple the whole company.
Technical change
Teams who work on IT systems also will need to improve their delivery pipeline: the process with which they create and deliver new software. Teams will need to start working on practices such as automated testing, peer reviews and pair programming. This enhances their speed of delivery as well as quality. Test as early as possible and invest time and money in automated testing. Create central repositories, where developers check in their code and have automated tests carried out. Develop tools for automated builds, automated testing, automated provisioning, and automated deployment into production. Ideally, software engineers should have the possibility of creating a production-like environment on their own laptop. Automate as much as possible and create continuous delivery pipelines.
In these pipelines developers do not need to wait for the end of a sprint before deploying into production, but can deploy much more frequently. Set up high-quality source control and configuration management. Software and systems will change versions all the time, and this should be managed automatically. In this way, it eventually becomes possible to create any environment at the click of a button.
One important task is to create metrics. By measuring performance and behaviour it is possible to create feedback loops, not just to business people but also and especially to the agile teams. The only way to really become agile is to experiment often, receive feedback from real live systems and customers, test hypotheses, learn and improve. This implies that metrics must be created at all levels in the stack: customer behaviour, application, middleware, databases, servers, platforms, networks, security and other items that are considered important.
Architecture enables autonomous teams
One of the factors that can seriously hold back teams from becoming autonomous is the architecture of IT systems. In many companies these systems have grown steadily not just in size but also in the variety of systems with many interfaces with other systems. If teams still need to coordinate with several other teams before they are allowed or able to make a change to one system, it is important to start working on refactoring the systems architecture. As the organisation becomes more agile, the system landscape needs to become agile as well. In fact, architecture is one of the best predictors of agile team performance. The more agile the architecture, the more autonomously the teams can work and the faster they can deploy new features into production. Architects need to start designing a strategy to move step by step (or by means of a big bang) to a new agile architecture. Part of this architecture will probably be based on SOA (Service Oriented Architecture) or micro-services. The sooner work is started on this the better.
In general, teams will automate an increasing proportion of their primary processes, and work continuously on making these processes more effective and efficient. They will use multidisciplinary teams to create new solutions and solve complex problems. Some specialist “swat” teams will swarm from problem to problem and deal with them quickly. Others will be formed as needed for short periods of time. The ability to act quickly is vital.
Finally, an overview of the knowledge areas and competencies that are required for successfully implementing an agile transformation: Cultural change, Lean theory, Kanban, Scrum, SAFe (or a similar scaling method, for large, complex systems), DevOps, Coaching and facilitation skills and last but not least, Agile leadership.
