Agile at Scale

Editor's Notes

• #2: The seeds of this book started in Canberra, Australia, when, as a software engineer, I first discovered this ‘new-fangled’ idea called Agile, and loved the focus on rapid, iterative delivery. Later, as a team leader and project manager, I came to appreciate the close engagement with the Customer and related workflow management processes. It wasn’t until I started managing companies, and later as a director in the Australian Public Service, that I realised that Agile could go further. Existing processes were inefficient, decisions were made at the wrong level, and nobody seemed to get what they needed, when they needed it. Agile had already solved those problems and could do it again.
• #3: Add ABM/GDAC logo
• #7: Role of ManagerAt all levels, whether you are a team leader or CEO, as an Agile Manager you are responsible for facilitating day-to-day operation, managing risk, providing governance oversight, and directing the strategic outcomes of the organisation.You will notice that I did not say you were responsible for the day-to-day operation, but rather you were responsible for facilitating the day-to-day operation.
• #8: Agile Business Management focuses on engaging staff at the level of ‘self-actualisation’, by emphasising creativity, problem solving and personal empowerment.
• #9: An Agile mindset accepts that change can, and will, occur and that change can be caused by both internal and external factors. Where possible, you leverage this change directly for your Customers’ benefit. You understand that change may be outside your control, but quickly adapt to take advantage of it.
• #10: An Agile mindset accepts that change can, and will, occur and that change can be caused by both internal and external factors. Where possible, you leverage this change directly for your Customers’ benefit. You understand that change may be outside your control, but quickly adapt to take advantage of it.
• #13: 1 Team: The highest level of trust where the Customer and organisation share the same goals and outcomes.2 Identification: Where the Customer has a personal relationship with specific Teams or individuals.3 Knowledge: Where the Customer bases their trust on personal knowledge and experience with the organisation.4 Contract: Where the Customer uses legally binding contracts as the mechanism to trust the organisation.Reference: Where third party references form the basis of trust.
• #14: The business case defines the rationalle for and expected benefits from the programme and it’s constituent projects. These should be developed prior to the programme or projects commencing, but in minimal detail. As the programme progresses and the outputs of each project are refined, the benefits and rationalle will also be refined. However it is very important to have enough information up-front to be able to decide to abandon a programme if it does not seem to be delivering on the benefits. A benefit can be thought of as an Epic User Story;As the organisation, I need a 10% reduction in costs; so that we can deliver on our shareholder targets.As the organisation, I need a 25% improvement in help desk response times, so that we can reduce the number of customer complaints.
• #16: The third domain of Agile Business Management is an organisational structure that promotes increased communication, trust and empowerment of your Teams. The ideal Agile Business Management structure has the minimum layers of management between the CEO, or equivalent, and junior Team Members, whilst still remaining efficient and functional. By creating self-organising and cross-functional Teams made up of individuals empowered with personal authority and accountability, a single, mid-level manager should be capable of supporting between 10-20 Teams. Each cross-functional Agile Team is typically between 5-9 full-time staff, where the whole Team works towards a single, specific outcome.
• #18: Agile already knows how to manage change; accepting change is one of the core concepts values of Agile. The programme needs visibility of each projects backlog/card wall with summary information of the stories/requirements that have an will be delivered. There is no need to keep separate change or configuration management information; it’s already all there. However it may be useful to create a high-level synthesis view of the major stories to define the change to date without going into too much detail.
• #19: Agile already knows how to manage change; accepting change is one of the core concepts values of Agile. The programme needs visibility of each projects backlog/card wall with summary information of the stories/requirements that have an will be delivered. There is no need to keep separate change or configuration management information; it’s already all there. However it may be useful to create a high-level synthesis view of the major stories to define the change to date without going into too much detail.
• #21: Agile programmes need to have processes to govern iterative and incremental projects. There are four suggestions that immediately spring to mind;The start and end of the iterations for each project should be aligned.The user stories and priorities for each project will constantly change, so the programme needs full access to all project documentation (such as the backlog) and included in all communication with the Customer.Apart from the retrospective, the programme office should be invited to all project meetings such as the daily stand-up and planning sessions.For IT projects, releases into production and the subsequent end-user communication should be managed by the programme.
• #23: 1 Monthly or quarterly budgets: By reducing the duration of each budget, organisations can tailor funding to meet the current needs of a Team, or Department. As most budget proposals will be identical, or nearly identical, to previous months, there is negligible overhead in managing multiple, short, budgets. Teams and Departments are encouraged (and in some cases incentivised) to be innovative with their existing budgets, and, where possible, reduce outgoing expenditure.2 Team level contingency: As part of their monthly budget, allocate each Team a contingency budget (usually ~20%) to spend at their discretion, either in the delivery of Customer Requirements, or as a mechanism to innovate change within the organisation. Unused contingency should carry over, to encourage sensible spending, rather than the traditional ‘use it or lose it’ approach.3 Staff welfare: Departmental and Team budgets are planned around ensuring delivery of the Customer Requirements, while maintaining a sustainable workload for each Team. From a budget planning perspective, it can help to visualise your Agile Team as a pipeline, as shown in Figure 48. The width of the pipe is your Team size, and the length is the time available to deliver. If a new, high priority, Requirement comes into the pipe, and as an Agile Team this is encouraged, the lowest priority Requirement will fall out the end. In Agile terms, the Velocity of each Team doesn’t change just because you give them more work. New research actually suggests that sustained overtime can lead to a significant reduction in productivity , , , . If your Customer wants you to deliver the new Requirement, as well as all the older Requirements, then the pipe will need to be widened (new staff added), or lengthened (additional time given), both of which will have an impact on the quote and/or budget for the Customer.
• #24: Elephant - NZPG
• #25: Elephant - NZPG
• #26: Language & Semantics – Pair Work, TDW, Quality Control Test, Requirements Backlog, Daily Stand-up, Summary Stand-up, Cust Rep, Team Faciliator, Iteration, Requirement,
• #27: Risk management is an area where Agile doesn’t do so well. Like non-agile programme, an agile programme should be keeping a risk and issue (realised risks) log which is regularly reviewed. A good place for this review would be a scrum of scrums (or equivalent) where impediments for each team is raised. In other methodologies, issues also include requests for change, but these are already handled appropriately by the agile project management (assuming transparent reporting).
• #29: Incremental Delivery: Planning and delivering related Requirements in short, fixed-time blocks.Continuous Delivery: Planning and delivering related, or unrelated, Requirements as they are identified and prioritised.Continuous vs Incremental work Continuous vs. IncrementalEffort Hours to days Weeks to yearsNotice On-demand (no notice) PlannedDeliver Single requirements Multiple Requirements with multiple tasksBacklog Requirements Backlog Requirements Backlog and Iteration Backlog
• #32: Let’s finish off by looking at our original definition of business growth; Business growth comes from applying profitability to customer growth. Profitability comes from delivering services to your customers, accurately and efficiently. Over the last 15 minutes we have looked at some of the mechanisms from the lean and agile traditions that we can apply for adaptable businesses and sustainable business growth. And I’ll leave you on that note. Any questions.