Which 2 quality practices apply to Agile teams?

The leaders, managers and team members must be mindful of the 10 SAFe Lean-Agile Principles and apply them to the work being done. These are:

1 – Take an economic view
2 – Apply systems thinking
3 – Assume variability; preserve options
4 – Build incrementally with fast, integrated learning cycles
5 – Base milestones on objective evaluation of working systems
6 – Visualise and limit WIP, reduce batch sizes, and manage queue lengths
7 – Apply cadence, synchronise with cross-domain planning
8 – Unlock the intrinsic motivation of knowledge workers
9 – Decentralise decision-making
10 – Organise around value

For more on these principles visit
www.scaledagileframework.com/safe-lean-agile-principles/

2) Real Agile Teams and Trains

Agile teams need to be cross functional and work in  a short time-box period (typically 2 weeks long) called iterations to deliver valuable increments in each iteration. They apply built-in quality practices and should be self-organising, both at team level, and as a team of teams.

The product manager, system architect and release train engineer provide context, technical authority and an effective development process to allow the teams to frequently integrate with each other, and to deliver value to the organisation and its customers.

Product owners and scrum masters help the agile teams meet their team objectives for the PI. Agile teams are teams that engage with their customer throughout the process rather than just at the end.

3) Cadence and Synchronisation

Cadence is about things happening with a steady, predictable rhythm so that events, such as PI Planning and system demos, can be planned into the schedule in advance. This means that there is not much overhead or time spent looking in diaries or rescheduling these events.

Synchronisation means that the events across a whole agile release train (ART) or even solution train occur at the same time so that planning can be done across the whole ART and regular integrations and reviews can take place with the teams at the same point in the programme increment (PI). It also help the ART assess how well it is progressing towards the PI objectives that were agreed at PI planning (see element 4).

4) Programme Increment (PI) Planning

This is a two-day planning event where all of the people working in an agile release train (ART) get together to plan the work for the next programme increment (PI). The duration of the PI is typically 8-12 weeks and is agreed in advance and applies to all teams in the ART.

The teams forecast the features that they will be able to deliver during the PI and work with other teams to identify, understand and resolve dependencies between teams, and risks to feature delivery. Objectives are agreed for each team and for the PI so that it is clear what each time is expecting to achieve by the end of the PI and also what the ART expects to achieve as a team of teams.

5) Customer Centricity, DevOps and Release on Demand

The customer is, ultimately, the person who decides the value of any work completed. These are the people who consume the output of the ART and may be external or internal. Creating a positive experience for the customer includes understanding the customer’s needs, thinking like them and understanding the lifetime value of the customer.

Customer centricity uses design thinking to fully understand the problem and design the right solution.

A DevOps approach means looking to reduce or eliminate the gap between development and operations by thinking about the culture, automation, lean-flow, measurement and recovery capabilities. This is often referred to as the CALMR approach to DevOps.

Release on Demand means the capability to frequently deliver value to customers, in line with the demands of the market.

6) System Demo

One of the principles of the agile manifesto is that working software is the only measure of progress. To review progress towards the programme increment objectives, the work from all of the teams is integrated, and the working software is demonstrated after every iteration.

7) Inspect & Adapt

At the end of every programme increment, an inspect and adapt workshop is run to review the solution, collect and assess data, and then decide on improvements that could be made for the next programme Increment. This is done in addition to team level retrospectives.

8) IP Iteration

The ‘innovation and planning’ (IP) iteration is the final iteration (or sprint) within every programme increment. It has a variety of purposes:

• a chance to finish off the work required to meet the PI objectives
• work on some innovation that may be useful in the next programme increment
• team members can do some professional development or training
• the inspect and adapt workshop takes place during the IP iteration (see element 7)
• PI planning for the next PI also takes place during the IP iteration (see element 4)

By being both an opportunity to clear the work from the current PI and plan the next one it gives the product manager the ability to set the new priorities. The opportunity to inspect & adapt, train and innovate can lead to a rejuvenated agile release train.

9) Architectural Runway

This is the technical infrastructure, components and code that is necessary to support the implementation of the high priority features that teams are soon to work on. The architectural needs to be prepared far enough ahead of the teams so that their work is not slowed by it not being in place.

10) Lean-Agile Leadership

Organisational leaders must take responsibility for the implementation of an agile transformation or it will likely fail. To be effective in this, organisational leaders must be trained in lean-agile ways of thinking so that they can support and guide others to a successful agile transformation.

What two quality practices apply to agile?

Which two technical practices focus on built in quality?

What are the three agile practices?

What are two characteristics of agile team members?