In 2001, seventeen self-described “organizational anarchists” met for three days to discuss more adaptive ways of developing software. They released what they called the Manifesto for Agile Software Development, describing the practices they had learned to value most:
individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan
As we serve clients transitioning to agile enterprises, we often facilitate similar discussions with their agile leadership teams, helping them to customize and commit to their own version of an agile manifesto. By the end of the discussion, the leadership team develops a simple statement of their agile values, and members of the team commit to changing their personal behaviors to reinforce those values. They also agree to help each other monitor behaviors and correct inappropriate actions. You can see a representative example of a manifesto in figure A-1.
Behind each bullet are specific values and practices that provide greater detail on each behavior. Over the years, we have helped to develop many manifestos. Each is unique to a specific organization, but below are some common discussion topics and commitments:
INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND TOOLS
We set out a clear ambition (what and why) and metrics for success, but delegate the how to the team.
– We build strong leadership alignment around our company strategy and priorities—the what.
– We create and communicate a compelling, clear purpose—the why.
– We use regular business reviews (e.g., quarterly) to maintain our alignment and focus.
– We establish a few critical metrics for success as opposed to a long list of interesting data points.
– We track progress through active, personal engagement with teams and in demonstrations, rather than by detailed tracking of milestones.
We empower our teams and believe that the right answer lies not with us but within the team.
– We stop talking and listen deeply to our teams; we state our own ignorance to solutions.
– We articulate our strategies and milestones as problems to be solved, not solutions.
– We push decisions down to the people who are closest to our customers, operations, and processes.
– We encourage everyone to contribute to conversations.
– We hold the team accountable for results.
– We treat teams and each other as partners and ask instead of answer—for example, “What do you recommend?” and “How could we test that?”
– We regularly observe Scrum team ceremonies to show we believe the answers lie with them.
– We actively seek diverse and divergent opinions instead of looking for others who will affirm our current ideas.
FIGURE A-1
An agile leadership team’s manifesto
WORKING SOLUTIONS OVER EXCESSIVE DOCUMENTATION
We engage on good enough working solutions instead of demanding perfect.
– We ask our teams to share ideas and prototypes at an early state and give feedback that can be incorporated.
– We don’t pick apart early prototypes but allow customers to use prototypes to shape innovation.
We protect the team so that the member can focus and rapidly unblock key impediments.
– We maintain a prioritized list of impediments and make eliminating them our top priority.
– We ruthlessly cancel meetings or compress them and instead attend team coordination meetings (daily or weekly) to see how we can help.
– We reduce demands for reporting on progress and instead use transparency, returning to teams to see demonstrations of working products and results, and to provide feedback.
– We eliminate traditional steering committees with arduous management approval processes.
We support teams in breaking down complex problems and delivering working solutions in every sprint.
– We help our teams crack open big problems to find ways to solve increments.
– We say no to slides describing solutions and ask to see real working prototypes.
– We attend team demonstrations to provide feedback, and see how customers react.
CUSTOMER ENGAGEMENT OVER RIGID CONTRACTS
We encourage teams to seek out feedback from a diverse set of customers and promote a culture of rapid adaptation to customer feedback.
– We clearly define who our customer is, and we listen to customers before building something.
– We prohibit pitches that don’t have real experimental results from real customers.
– We encourage everyone to spend more time outside the office—Go see ’em.
– We avoid customer surrogates—go directly to customers for feedback.
– We regularly ask for assumptions and explanations of how they are being tested with customers.
– We put more weight on customer-related KPIs than on purely internal ones.
– We bring customers into project teams and meetings.
– We equip teams to solicit customer feedback as opposed to having that capability live outside teams.
– We create movement makers who ask customer feedback questions in all meetings.
– We structure meetings so team engagement with customers gets most of the airtime.
We believe that things can always be improved.
– We never allow a priority product to be done, but continuously ask: How could we make it even better?
– We look forward to what our customers will need and how our market is evolving to push innovation.
RESPONDING TO CHANGE OVER FOLLOWING A PLAN
We celebrate learning and create a safe environment for teams to take prudent risks and test unconventional hypotheses.
– We askwhy notas opposed towhy and establish opportunities for pilots, prototypes, and experimentation.
– We provide the space to experiment; we minimize the need for multiple layers of sign-off, especially when experimenting.
– We advertise successes; we tell stories at company events and recognize people who are looking ahead and identifying opportunities.
– We seek out the bad news; we make people feel psychologically safe sharing failures.
– We engage in uncomfortable conversations with customers, clients, and associates.
– We reward people from all functions and levels for bringing new or unconventional ideas.
– We reward learning from failures.
– We as leaders admit failure publicly.
We embrace ruthless and constant prioritization and stop activities that are not yielding sufficient learning and results within the defined time frame.
– We ruthlessly focus on our top priorities, and get them done before tackling the next.
– We make all prioritization, work items, and problems visible to everyone.
– We establish a leadership team that continuously reprioritizes the company backlog based on internal and external feedback.
– We stop investment once we see we are not generating sufficient results.
We role model agile ways of working every day.
– We reduce our time in meetings by half to allow for time to spend with customers and front-line employees, and to consider the priorities and direction of the organization.
– We change the format of our top leadership meetings; no more sitting at a table listening to readouts from slides on progress but instead walking the room to talk about priorities, reacting to real working prototypes, creating our own prioritized list of actions, solving our greatest impediments.
– We act as catalysts in the transformation process.
– We embrace symbolic changes: abandoning corner offices for a shared table in the middle of the building where we are accessible to everyone, giving up assigned parking places and turning them over to client visitors, conducting weekly get-togethers in the company café to provide business updates and answer questions, openly admitting what is going well and what needs more attention.
– We publicize our commitment to changing our own behaviors and will share our personal development agenda.
– We seek help in terms of coaching and feedback to change.
As this long list of commitments suggests, leading an agile transition is a lot of work. The agile transition process is not a costly distraction; it is the way the business will run. The agile leadership team learns to operate as an agile team in service of its external and internal customers.