AO Programs

As explained earlier in the book, work in an enterprise can be categorized into three main activities: programs, projects and transactions.

Transactional work is a routine to maintain the current situation. In digital organizational models, it is how you handle platforms.

Programs are a collection of projects and support activities supporting a single significant initiative. In an agile and empirical manner, you never start a program as such. You start with a project that once reached its goal becomes larger. The agile way of working supposes that all projects or programs are “greenfield” by default. It means if we have some knowledge on how to do it, we have to assume being biased by our own beliefs. The risk is then that we manage the program in a transactional manner: variation from the KPIs, from the Milestones, budgeting, compliance and legal, over-engineering, etc. Programs are long term initiatives, having a collection of deliveries and multiple actions. They contain projects, transactions, research and development and sometimes other programs.

While testing AO, I wanted to keep the management logic as simple as possible (simple rules). So, I kept the Scrum X (see the “project” chapter) approach to avoid multiple management layers and additional coordination.

In Scrum, the Sprint is a Safe-to-fail container where Delivery Teams are protected from any scope change. Change requests are added at the start on a new iteration according to the outcome of the previous one.

At a larger scale, when your solution is more prominent, this approach is applicable without over-complicating the methodology by adapting larger size with a slower pace. The challenge is to start parallelising a considerable amount of work. The discipline in agile is to reduce the distance between the decisions makers and operations. Most of the scaling methodologies are just replacing the structured approach with a Product Owner working simultaneously with several feature teams. That is wrong. Reducing the distance means to empower each team to work directly with the customer and the users without any buffer.

In that part, I will explain how my teams and myself have proceeded over the years. The management part will be addressed in the portfolio chapter.

Simple rules

By keeping the same light logic as for the delivery teams, Scrum is adapted for a different pace to support:

Programs through the Complex Adaptive System Lens

• SAFE TO FAIL CONTAINER (flexible evolutive boundaries): containers (organisational), iterations (time)
• INTERACTING DIVERSITY OF EMPOWERED AGENTS: diversity of experiments generates data showing options or solutions trends
• RESILIENT (EMPIRICALLY) COHERENT (ALIGNMENT) STRATEGY PLANNING: constraints drive resilience, time-boxes, fixed team size, Value/R&D/BAU
• CONSTRUCTIVE IRRITANT LEADERSHIP
• LIGHT, SHARP AND NIMBLE: keep the structure nimble, talk about values, not methodologies, empower operations, last responsible moment leadership, a flat and responsive organisation over cascading baronies.

Core principle

• Organisation gives the company true north and shares the expected goals
• The crowd gathers to draw how to transform this goal in a Roadmap for the next three months
• The crowd distribute the purposes into the three workstreams:
• Value: what is feasible in the short term
• R&D: detect opportunities and analysis
• BAU: commodities
• Every month, the crowd meets and inspect and adapt the results of each team
• “value” shows outcomes
• “R&D” shows new ideas, opportunities that “value” can pick up
• “BAU” share news activities or improvements to reduce transactional work

Backlogs as Portfolios

During the last decade, we discover that the “single” product backlog of scrum teams has evolved to team backlog. It becomes a collection of work that the team has to deliver in a specific time. It includes the development of new solutions and the support of the older once. It seems easy, but the reality is that you are increasing the complexity of work (lack of coherence) by accepting all kinds of jobs into team feet (lack of prioritisation).

In that order, a team backlog is composed of 3 main workflows:

• Value: composed of development activities and support of the last version delivered
• BAU: are all the activities which are neither R&D nor Value. Usually, the BAU are “acceptable impediments” like information meetings, or time-sheet management, recruiting, etc…
• R&D: contains all the activities not related to the sprint goal or post sprint activities (for the next sprints) like technical spikes, business analysis, or testing (technical, functional, UAT).

This approach allows the team to allocated themselves what capacity on what stream and that daily (daily scrum).

When Sprint is over, at the review, the team highlight their achievements, discoveries according to their portfolio.

The Organisation Portfolio is just the consolidation of all team portfolios. Its mission is:

• to align all portfolio according to organisation true north or goals
• drive the banking stream to allocate budget

Banking Track

The budget should be able to support business agility and funding is a quite uncomfortable yearly political fight.

The Banking Track is working like a Bank where you can ask budget and resource at the end of each monthly cycle. Banking Track is part of the monthly release update meeting or Cycle review.

The Banking Track is managed in a BAU stream and takes these basic rules into account:

AO Values

1. Value: deliver what customer needs early and often
2. Transparency: make “performance” visible
3. Balance: match demand with capacity
4. Listen to the system: doers take decisions, ask the team
5. Accept possibilities: be flexible by standardising
6. Innovate: embrace problems
7. Transparency: communicate results, be open and learn
8. Mastery: strengthen your people’s skills
9. Communicate: give an take constructive feedback
10. Coherence: Share and align the vision

Agile work breakdown structure

The program contains several preconditions to be considered as a program:

• Have a purpose: what is the objective of the program?
• Have a direction: high level “themes” or milestones
• Have a sponsor, customers: who are the chicken?
• Have a Product Owner: the person having the vision for the program and not from its subparts. The Product Owner is not an authority, and it is the person aligning the bird view with the field view from the other Product Owners continuously. Sometimes we use the term “Chief Product Owner”, but “Chief” can lead to an overacted misunderstanding.
• Have a Coach as the voice of the “program” system. The Coach is usually called Agile coach or Enterprise Agile Coach, making the difference with Team coaches or ScrumMasters. The only difference is that the coach isn’t part of the subsystems but only part of the more extensive program system. The job is to align the top-down strategy with bottom-up tactic and improve the organization as part of the coaches crowd.
• Have a system composed of
• The Release Goal is set up collectively based on reachable goals.
• Team Goal is how each team can develop their piece of the Release in a bottom-up manner.
• The feature is a top-down decomposition aka theme in the Scrum jargon. Despite to Feature, Epics are a bottom-up organization of essential stories. Elements should be developed at least during a release.

The story is a small backlog item ideally shaped as a micro-narrative. A Story should be developed during a sprint.

• The team goal is the user vision aligned to the release vision.
• The Capability is the Team knowledge to transform the team goal into potentially shippable increments.
• Feature, Team goal is to deconstruct into achievable elements or “epics”.
• Stories are small workpieces like User Stories, Technical Stories, Backlog Items. In my teams, we are using two types of stories. The User stories are only valid when you know the customer, and Tech Stories are for all non-functional or technical developments.

Program cadence

The program cadence is set on three months or a quarter. Three months are sharp enough to have a compelling outcome and small enough to avoid impromptus of strategical changes. Over three months, you increase the risk of stop-and-go from the management. Under three months, the change is too significant to ensure both value creation and business agility (response to business, customer or user-oriented requests).

Levels of change

The quarterly release is a management scope freeze of the strategy. Any strategical changes are taken into account for the next release planning. If an unplanned event forces the management to stop, all the release planning and its sprints have to be cancelled. It happened to me once. After the planning session, the management run in severe budget issues and they asked all external consultants to stay home for two weeks. These externals consultants represented 70% of the workforce. I informed the business and the customer of the situation and cancelled all the sprints for over twelve teams. Once the issue recovered, we gathered again to replan the quarter together. A retrospective with management, the product owners and the scrum masters and other agile coaches took place as a post-incident review momentum.

Organization convention

• The Team also known as Scrum team is a group of 7 +/- 2 people including Product Owner, Scrum Master and at least one developer and one tester. A team is stable; this means that a team member is fully dedicated to its Team.
• The Floaters are people working for several teams; they are floating.
• The Crowd is the ensemble of all the teams working in a program organisation. Like for birds, the CrowdCrowd is swarming in the same direction.

Setting up the program vision and Plan the roadmap.

Vision always comes first. It is the “point to the destination” action. The program vision is the first part of the quarterly roadmap session. During this session, ideally, all the stakeholders are present to ensure alignment.

• Management starts with the strategical vision
• They show up the full roadmap on one or several years and explain why.
• We proceed to retro-planning on one year to define highest priorities
• We rollback the vision until the quarter to plan
• All together identify risks and corporate issues
• Then the Teams are presenting their counterproposal
• The Product Owners are showing up their roadmaps and explain why.
• All the stakeholders are challenging each team roadmap.
• The Crowd consolidates all the visions into one joint.
• The Team challenges the management vision from a feasibility perspective.
• The Team´s vision challenged by management according to their initial roadmap.
• Once the challenges are over, all stakeholders are making the deal on the next roadmap.
• All together we explicit dependencies and maybe remove high dependencies from the roadmap.
• All together are estimating the effort as the sum of all velocities (story points are usually used).
• I ask in what environment the roadmap can be achievable
• I ask which team members want to work where
• All stakeholders validate the roadmap proposal, and the work starts for the whole quarter.

Points of attention.

During that workshop, you have to take care that everyone has a voice. For coherence, it is crucial that all opinions are taken into account and you are building the deal on all pieces. Because the workshop is a collective effort, the risk of losing engagement has been reduced. That situation is almost very insecure, and close attention has to be taken that the teams are standing on their commitment. A couple of years ago, I ran my first big planning event for a whole week with more than 150 people. The outcome was impressive, and the customer was delighted and understood the value of that process. Unfortunately, I discover that politics (structure) has started on the next day, and some managers pushed back from ego reasons. While keeping my relationship with that company, I discovered that the program that we planned has definitively delivered three years later and the costs increased by 400%. At SAP, the roadmap planning was a game-changer, and all the teams are still running it in 2019.

Summary for the Roadmap

The Chief Product Owner shares the strategical roadmap with the crowd.

The release Vision is the answer to “what means done in 3 months?”

The strategical roadmap is shared with the teams, and they design their “goal” or “team vision” on what part of the Program they can develop.

During the Release Planning workshop, the team’s goals are put together for alignment and dependencies are made visible, and countermeasures are taken.

How to manage it?

Once a week the POs are gathering into a Scrum-of-scrums and ask to 4 questions:

• What have you set on done since last time we met?
• Does something impede your progress?
• What do you plan next?
• Are you putting something in someone’s shoes?

The objective of the meeting is replanning due to emerging changes and alignment of the efforts that are not a status meeting. Usually, the POs are giving feedback in front of the Release Plan.

That meeting is an open meeting, and anyone necessary is invited to join and contribute if appropriate.

Monthly Release Update

• Facilitated by Chief Product Owner
• It is a Program Review in front of the crowd and program stakeholders
• It’s the Inspect-and-Adapt of the Release Roadmap
• New changes can be added into the Program Backlog, and items from the same size or value are removed.
• Removed items are taken into account for the next release or deleted if no longer necessary.

Challenges for the leaders

• Leaders refrain from imposing specific practices
• Leaders invite everyone to an all-hands (open space) meeting of at least once a month
• Leaders set the vision and discuss the outcomes
• Document and implement the best ideas

Synchronisation and alignment

I suggest here that all the teams are synchronised while starting and ending their sprints the same day on a cadence of two weeks sprints. That approach avoids hiring specific people like PMOs to coordinate all meetings.

Another challenge is for the teams waiting for the end of the sprint to release their work — the new dynamic lead the developers to deliver every day. The review meetings become then a functional retrospective of the provided work and can be improved as user acceptance testing event.

The genuine approach to inspect and adapt meeting has been improved by:

• Swarming meetings: meetings helping to align all teams or crowds together. Swarming events are Release Planning, Release Update.
• Pollination meetings are in place to share knowledge and inspect and adapt collectively like Release Retrospectives.

Roles

In this kind of organization, we should not focus on the job but either on the role. The role that you play within that system. Organization over the structure is vital.

To enable that system, we need:

• Purpose keepers are focusing on the “WHAT”. These are typically Product Owners.
• Organization keepers are managing the “Safe-to-fail” containers. These are typically the Scrum Masters of the Agile Coaches.
• And agents focusing on the “HOW”. These are typically the “developers” having all the necessary skills available to get the job done.

In this model, organization keepers or coaches are keeping the balance between the “WHAT” and the “HOW”.

Unlike traditional Scrum, Product Owners are part of the team and are not an authority. Their activities are mainly to translate customer’s or user’s expectation and not decomposing requirements from a tier.

Unlike in traditional Agile, coaches are now linked to the Human Resources “BAU” to act as “operational HR” helping Human Resources to move out of commodities to Human Relations as keepers of the safe-to-fail containers.

Originally published at https://myao.blog on October 10, 2019.