There are many ways to lead multiple Agile Teams, with some approaches being more effective than others. The Agile police may caution me after reading this (which I’ve preemptively created solidarity hashtags for), so to be clear: this article describes one tailored approach to leading multiple teams to deliver a technically complex product using Agile and Lean methods in a historically plan-driven organisation. Names have been changed to protect the innocent. Let’s call this Product X.
1. Seek First to Understand
My first step was and always is to understand the ambitions, goals, culture, capabilities, challenges and quirky dysfunctions of the organisation I am working in. For me this means being curious, asking questions and listening to individuals one-on-one (with what I call ‘real listening’ or technically ‘empathic listening’). With this understanding, the real conversations about how to deliver and ways of working can start by looking at individual capabilities and motivations as well as current delivery methods and tools.
2. Why Agile?
Agile or Value-Driven approaches prefer to plan and develop in iterations to demonstrate and review the product, reorder requirements (if necessary) and improve delivery practices to deliver business value early and frequently. Plan-Driven approaches, in contrast, prefer to complete all planning upfront before work commences, hence predicting when all work will be completed. Predictive planning works well for simple projects or when requirements are clear, do not change significantly and there are few unknowns. With predictive planning, the entire development process is dependent on a clear and stable set of requirements.
Product X is and was the opposite: it is technically complex, many requirements were unclear, expected to change and there were many significant unknowns. Requirements were defined at the theme and epic level in insufficient detail for accurate estimates and planning. New requirements were expected and very much welcomed as part of ongoing user testing and market feedback.
2.1 Adaptive Planning
With this in mind, rather than attempting to stabilise requirements with formal sign-offs and various governance boards, my view was to tolerate changes and view late changes to requirements as a competitive advantage. This adaption to change was achieved through the programme-wide adoption of an adaptive planning approach, where the cycle of planning and execution is repeated multiple times across the Agile teams. In practice, at regular intervals, the Agile teams re-plan and re-adjust based on the latest requirements from Product and Experience Design user testing in the markets. The teams also release at regular intervals, which required the wider organisation to agree to a regular release cycle. Underpinning this, the technical design and experience design approach was more evolutionary than big design upfront i.e. the product was designed for change.
2.2 People First
A general people over process approach was taken. Plan-driven approaches tend to view people as components or resources, where a process is designed by one group of people who attempt to fit a different group of people into that process. I successfully campaigned against this. We agreed that people are unpredictable in nature, are the primary actors in software development, who need to work effectively together and, hence, each Agile team needed to choose the process they believed would enable them to deliver most effectively.
2.3 Empirical Process
Tying into the people first approach was the empowerment of the Agile teams (power to the people!) to refine their process as they saw fit to continuously improve effective delivery. Defined processes work well when the inputs and controls are well known, understood and proven, for example the same team delivering the same requirements with the same tools under the same conditions. Product X, however, had unproven Agile teams (new starters) with new conditions, new interdependencies, new requirements and new tools, so feedback loops were needed for the outputs to be inspected and the inputs adjusted accordingly to continuously improve team outputs, i.e. an empirical process.
Feedback loops included:
- Task boards – JIRA board on a TV screen during daily stand-ups enabling feedback on the position of user stories and tasks in the workflow;
- Build reviews – enabling continuous assessment of Product X (Do the features work? Does it build well? Does it integrate? What further tests does it need before it is production ready?)
- Iteration / sprint testing – enabling the teams to regularly identify and resolve defects within a development iteration, starting off with shorter tests and then longer tests as the project progresses;
- Retrospectives – enabling each team to review and improve the process at the end of every iteration.
3. Agreeing Delivery Principles
A Sprint 0 was initiated to agree ways of working with our new development partner (Agile Team 1), other Agile teams and the wider organisation.
I am always keen to discuss, understand and agree key delivery principles before adopting delivery practices blindly. In my experience, the most appropriate and innovative practices stem from passionately discussed and agreed principles. The definitions of values, principles and practices helps to explain this:
Values – one’s beliefs and opinion of what is important in life and the degree of importance, which forms the basis of behaviour and action;
Principles – propositions that serves as the foundation for a system of belief or behaviour, which helps translate values into action;
Practices – the actual application of a belief in the form of repeatable actions.
The following delivery principles were proposed and agreed with the Agile teams and Workstream Leads in the final Sprint 0 workshop.
- Collaboration and transparency – regular and inclusive communications, including meetings, summary notes and repositories, will be used to help facilitate support, collaboration and transparency across all cross-functional Agile Teams and workstreams.
- Roles and responsibilities – all roles and responsibilities will be defined, agreed and reassessed throughout the project against current capacities, allocation and speciality.
- Early business value – to deliver business value early and frequently, development will be completed in iterations to demonstrate and review the product, re-prioritise requirements if necessary and improve delivery practices.
- Roadmap / planning – requirements will be categorised, prioritised and split into defined releases, to enable estimations, planning and iterative delivery by both internal and external Agile Teams.
- Progress Reporting – progress will be reported against the agreed target milestones. Detail will be provided in JIRA.
- Demos – In addition to fortnightly demos for each Agile Team, specific stakeholder demos will be organised at agreed intervals.
- Requirements – As further detail and clarifications are provided or discovered, along with any required changes, estimations and release scopes will be revised accordingly.
- Single source of truth – to enable all requirements to be easily communicated, prioritised, agreed, delivered and subsequently validated by QA and stakeholders, a single source of truth at the appropriate level of detail has been agreed: JIRA.
- Requirements readiness – requirements will conform to an agreed definition of ready for development.
- Release readiness – completed development will conform to an agreed definition of done for business acceptance.
- Quality product – to ensure issues are identified as soon as possible and the product can be confidently demonstrated, testing and quality assurance will be utilised throughout the iteration cycle, rather than at the end of the project (which may impact launch schedules and final product quality).
- Risks and issues – risks, issues and dependencies will be managed in a visible and repeatable way to support decision making and escalations.
- Effective meetings – all meetings will have an agenda defining the purpose, outcome and outputs.
- Lessons learned – lessons will be reviewed from previous and ongoing projects.
These principles and other Sprint 0 outputs (Agile approach, roles, responsibilities, deployment and distribution, development guidelines, epics, technical and functional integration points, non-functional requirements, dependencies and key milestones) fed into the Agile Team 1 contract.
4. Agile Teams Set-up
The technical implementation of Product X required five teams, including DevOps who follow Lean Kanban.
The other teams mainly follow variations of Agile Scrum.
- Teams 2, 4 and 5 (not shown) are based in London
- Teams 1 and 3 are based offshore with QA and UAT respectively in London
4.1 Coordinating Teams
As Agile Delivery Lead (DL), I negotiated the following cross-functional Agile Team delivery structure with the Product Owner Lead (PL), Team Product Owners (PO), Agile Project Managers (PM) and wider organisation. This visual representation helped sell the idea and inform the discussion (team names and outputs altered).
4.2 Coordinating Agile Ceremonies
With all team iterations (sprints) being two weeks (10 working days), it was critical for me to lead a sensible discussion on the value of perfectly syncing all Agile team ceremonies. The decision was to stagger the sprints and generally avoid having ceremony clashes for two reasons:
- Attendance – some of us needed to attend multiple ceremonies, mostly to listen and some to provide input;
- Technical – the continuous integration (CI) server, shared by three teams, would struggle with simultaneous builds on demo day.
The team ceremonies illustration below was also used to communicate the purpose of each ceremony to stakeholders (team names changed).
4.3 Agile Team Delivery Approach
Agile Teams 1 to 4 adhere to the Scrum process framework to varying extents. The Agile Team servant-leader role was officially titled ‘Agile Project Manager’, but in other organisations may be called Agile Delivery Manager or Scrum Master. This role and the team Product Owner are fundamental to the success of iterative and incremental delivery.
All four teams have a continuous integration (CI) server with Bamboo or Jenkins. A combination of in-sprint manual testing and automation testing (Selenium) is used when applicable to meet the agreed Definition of Done.
Agile Team 1 follows both Agile Scrum and Lean Kanban. The larger technical workstream follows Scrum, with two week iterations, and the smaller creative workstream follows Kanban. Both workstreams have aligned milestones and formal acceptance dates. Why did we do this? It was not possible for the Digital Artists to plan and commit to full two week iteration, so pulling work from a regularly prioritised queue while limiting work in progress (WIP) to reduce lead time and achieve maximum throughput is the prefered method under these conditions. A Scrum board and Kanban board was set up with the same JIRA Project, but using different board filters.
Due to distributed teams and remote working, when face-to-face conversations were not possible, the teams agreed to utilise Slack as their main communication channels, with JIRA being the single source of truth and face-to-face conversations summarised in Slack for visibility. Product X tools include
- JIRA – Team Scrum boards, Kanban boards and Dashboards
- Trello – Agile Team 1 Sprint Retrospective Board
- G Suite (Google Apps) – Product X Team Drive for uploaded files, shared Google Docs, Google Sheets and Google Slides
- Slack – various Product X channels for discussion and video calls, with screen sharing
- GoToMeeting – recorded video calls for demos and other stakeholder meetings
- Skype – non-Product X communications, discussion and video calls
- GitHub – code repository
- Hockey App – internal distribution of Alpha and Beta builds (iOS, Android, Mac, Windows and Linux)
- Bamboo – continuous integration and continuous deployment server
- Jenkins – continuous integration and continuous deployment server
5. Roadmaps & Release Names (Abandoning ‘MVP’)
Everyone loves a roadmap and to see the product vision mapped out, otherwise what are we doing and why?
Assumptions and caveats are critical to the validity of any roadmap that will be shared widely. After carefully creating a roadmap with swimlanes and target dates for four Agile Teams, four high-level assumptions were included with the roadmap (months and team names changed).
The only thing that possibly trumps the love of a roadmap is the obsession with a ‘MVP’ or the minimum viable product. There is inherent confusion in using this term, as ‘minimum’ and ‘viable’ means different things to different people, so I successfully made the case for more explicit descriptions to be used. These were:
- Earliest Testable Product (ETP)
- Earliest Usable Product (EUP)
- Earliest Marketable Product (EMP)
Although much clearer, these more descriptive terms are not immune to exploitation and confusion. To help embed these terms, the Release Milestones were also added to all reports and the Team Sprints Google sheet created for planning and stakeholder management (months and team names changed).
6.1 Distribution of Effort
Leadership is action, not a position or job title, and actions require effort. Very much tailored to the cultural demands of a historically plan-driven and highly political organisation, the quadrants below illustrate how I prioritised my daily efforts to lead Product X delivery.
Most of the effort in leading multiple teams is clear and repeated communications to sell the why, champion the product vision and control the narrative, taking many forms, which I believe needs to be achieved by any means necessary. I’m a visual person and like to encapsulate my ideas with custom visual representations and even cartoons. Communication is also a two way street, so much of this is seeking to understand individual needs, motivations and challenges before tailoring communications accordingly, i.e. the level of detail, tone, format and frequency. Providing clarity enables me to easily provide direction, lead and coach individuals at all levels, often senior to my role.
Central to my leadership style for Product X is my character. This is essentially my habits and behaviours that are driven by my values and principles, which include honesty (talking my walk), integrity (walking my talk), excellence, fairness, authenticity, humility, compassion, courage and increasing my emotional intelligence. For those new to emotional intelligence, from a high level, this is:
- Personal Competence – Self Awareness and Self Management
- Social Competence – Social Awareness and Relationship Management
Fortunately, unlike intelligence quotient (IQ), your emotional quotient (EQ) can be increased, so there is hope for everyone willing to put in the effort. Over the years, my principles haven’t changed, but placing more importance on my compassion, courage and emotional intelligence has helped me develop a number of personal tools to be a better person, leader and coach (although apparently not the Machiavellian egocentricity and other psychopathic traits needed to rise to CEO).
6.4 Being a Servant
My default style is to ensure that everyone has what they need to deliver and at a sustainable pace. Being the Agile Delivery Lead and outwardly the Technology Workstream Lead, interfacing with seven Workstream Leads, I was in the best position to provide clarity, remove genuine and perceived blockers, resolve interpersonal conflicts, shield key people from ‘noise’ and generally fight for truth, justice and the Agile way. This style may not suit everyone, but is highly effective and can be consciously adapted to a more command and control style when the situation dictates, e.g. my meetings finish on time, if not early!
Through understanding the main actors and stakeholders, the servant-leadership challenges were very much foreseen. These challenges were somewhat headed off with the Delivery Principles, knowing that most of my effort would be in reinforcing these principles day-to-day as part of an integrated campaign and communication strategy. Roles and responsibilities, while defined in Sprint 0, needed to be supported with regular communications of who should be doing what and when to help mitigate the duplication of effort and ball dropping. People need to be reminded more often than they need to be instructed.
Initiating a paradigm shift and cultural change from fixed dates and fixed scope to fixed dates and flexible scope proved to be the most challenging. The initial position was very little flexibility. However, after an extended period of management swarming to identify how the teams could create time and fix bugs faster, it was finally accepted that the Earliest Usable Product should be released and followed up with another release, with further releases available every two weeks. This enlightened pragmatism followed a very successful Product X demo where it was deemed that the reduced scope very much delivered early business value and could be used for its intended purpose. It was another win for Agile and a slap in the face for Plan-Driven. Nobody stood to benefit from maintaining the status quo.
Bringing it all together
My tailored approach to leading multiple teams to deliver a technically complex product using Agile and Lean methods in a historically plan-driven organisation can be summarised as:
- Seek first to understand – understand the ambitions, goals, culture, capabilities, challenges and dysfunctions of the organisation by asking questions and empathic listening before discussing individual capabilities and motivations, delivery methods and tools;
- Use Agile for unstable requirements – utilise adaptive planning, let the teams define their own processes and ensure they create feedback loops to inspect, improve and deliver business value early and frequently;
- Agree Delivery Principles – discuss, understand and agree key delivery principles with the Agile teams and Workstream Leads and ensure this is communicated to the wider organisation. Top-down buy-in is critical;
- Set-up Agile Teams for success – set-up a Scrum of Scrums and Interdependencies / Blockers Board, coordinate ceremonies with strict agendas, define key team roles and responsibilities and agree tools;
- Roadmaps, assumptions and descriptive release names – maintain a Roadmap with assumptions and use more descriptive terms for milestones, such as Earliest Testable Product (ETP), Earliest Usable Product (EUP) and Earliest Marketable Product (EMP);
- Leadership – lead with carefully distributed effort, tailored communications, a ethical character and service.
I hope you enjoyed reading. This was definitely not a warts and all Agile war story, which is probably best delivered in a talk behind a screen, but was very cathartic nonetheless. Do you lead multiple teams? What’s your approach?