Guest post by Arlen Bankston of Lithespeed
What keeps most organizations from true agility? The most common cause is a lack of holism; agility exists as a development aid alone. It is practiced to the degree possible by IT groups, while ignored, avoided or actively opposed by other organizational entities. Does this story sound familiar?
- Several teams have done well using agile
- There is a feeling agile could be applied more broadly
- But resource management, metrics, audit and compliance, team structures, customer engagement model, HR practices and more are all aligned for waterfall delivery…
While even in this scenario, benefits can ensue at a local level. The organization itself will never realize the full ability to learn, adapt and execute which end-to-end agility can bring. Cultural change management is challenging in general, but especially when so many groups are impacted at once.
Here are 5 steps that can help you create a more agile organization:
- Build your people
- Make your adoption agile
- Focus at all levels
- Make space for innovation
- Refer to frameworks; don’t rely on them
Build your people
Many will remember that the first principle of the Agile Manifesto is “individuals and interactions over processes and tools.” An outsider looking at many agile adoptions might see the opposite emphasis, as the methods and tools that support them take center stage. True agility relies heavily on local knowledge, willingness to learn, mental engagement and empowerment, all of which require people with a belief that these methods will make their lives and careers better.
The first step is properly leveraging management. Functional managers, often given short shrift in agile adoptions, can play a key role in helping to build and support their people through these changes. Their responsibilities include providing local descriptions of expected skill sets and competencies for hiring and progression; implementing and supporting role-specific tool sets; setting up communities of practice (CoPs) to support collaboration across teams; and managing performance through frequent feedback loops and reviews.
The second step is creating clear career progressions. New roles like ScrumMaster and Product Owner need to be defined, supported and provided with growth paths, while existing positions like Development and Quality Assurance may need to be modified to better fit their agile incarnations. One popular model is the “Teaching Hospital,” where employees progress through 3 broad stages of mastery:
- Learning – Acquire knowledge by being a student and mentee. Example: A developer takes Agile Engineering 101 training and a few platform-specific classes to fulfill the objectives of this level.
- Practicing – Acquire real-world experience. Example: A developer works on a Scrum or Kanban project for a minimum of 6 months.
- Teaching – Prove and advance expertise by teaching others. Example: A developer teaches at least 3 Agile Engineering 101 sessions and coaches an apprentice to a Practicing Level of expertise.
Making your adoption agile
While we need to think holistically, changing everything may take years – and you won’t get it perfect the first time. The trick is to start with a wide path and get everyone aligned on goals, principles and a basic approach, deepening adoption over time. There are several core facets to this iterative approach.
Educate, align and assess
Take a week or two to educate a wide band of the organization on the principles and practices of agile, and align on the goals of the adoption. Executive and organizational overview sessions can create a common baseline of understanding about both the benefits and challenges of lean and agile methods.
Following this introductory training, you can use assessment workshops with senior and middle management, engineering teams, operations, PMOs, HR and so on. This can help to draw out objectives, key concerns and potential near-term solutions for each impacted group. These will also yield a list of perceived risks and issues; a short-term set of pilot initiatives in which to test changes in a controlled environment; and a measurement system to gauge progress of the overall adoption.
Establish accountable adoption teams
Big changes require dedicated attention, so set up teams to manage the adoption like a project itself. These typically consist of an Executive Agile Steering Group which sets broad organizational goals and defines measures of success, and an Agile Working Group which helps drive and monitor the adoption.
The Executive Agile Steering Group might meet on a monthly or quarterly basis to review progress, communicate changes in organizational focus, and address high-level impediments noted by the Agile Working Group.
The Agile Working Group is a cross-functional problem-solving group generally consisting of representatives from development, QA, production ops, analysis groups, PMOs, and middle management. Their job is to anticipate, uncover and address tactical issues within and between active agile teams, making recommendations to executive teams as appropriate. They also gather metrics and manage communication about the adoption at both team and executive levels.
Focus at all levels
Doing more than one thing at a time results in multitasking and context switching, which can dramatically lower both efficiency and quality. Most organizations are severely overburdened at all levels, encouraging teams and individuals to juggle multiple projects at once and causing a dilution of focus.
Toning your organization’s project portfolio can bring immediate and substantial benefits to time to market, quality and satisfaction. Some good places to start:
- Terminate sick projects – There are always projects that seem to be going nowhere, but the political capital behind them won’t let them die. Be ruthless in killing these boondoggles.
- Limit development timeframe to months – The ability to release more frequently is a key component of business agility; avoid the temptation to keep releases long due to overhead. Instead, focus on making the release process more efficient.
Letting your teams focus on one thing at a time is especially important when you’re also asking them to learn and implement a new method. Additionally, this yields a much clearer sense of true team capacity over time, as project delivery metrics aren’t confounded by multiple intersecting workstreams. Align teams by platforms or lines of business, then let them deliver one project at a time while PMOs line up the next by business priority. Limit work in process at the portfolio level to improve both the cycle time of individual initiatives, and the total volume of initiatives delivered each year. Stop starting projects, and start finishing them.
Make space for innovation
Agile methods focus on making change cheap, so that organizations can experiment without fear. However, true innovation tends to fail often before it succeeds. So the portfolio management process must take account of this reality and create space for exploration.
The “Lean Startup” method offers a number of tools and principles for managing product development in an iterative and incremental manner. Key among these is to regard projects as sets of small experiments, where for instance each Sprint would have expected results that can be compared against observed reality through metrics. Another idea is to have teams more directly engage with real users and customers by “getting out of the building,” which creates a richer, faster feedback loop and avoids organizational navel-gazing.
One other key consideration is how financial management processes such as project budgeting, reporting and contracting are affected by agile methods. One theme here is that adaptive organizations need to allow for incremental funding and iterative scope changes. This means that typical fixed annual budgeting cycles are too lengthy and restrictive for agile environments. Quarterly budgeting can help here, informed by clear guidance on when to increase or reduce funding that is reviewed and applied regularly across the project portfolio. Public organizations also must develop accounting rules that explicitly determine whether and when software projects are capitalized — a process that can be unnecessarily restrictive to change if not appropriately tuned to the rapidly changing nature of innovative projects.
Refer to frameworks; don’t rely on them
The human predilection for easy answers leads many to turn to reference frameworks for adopting and scaling agile methods, such as Scrum and the Scaled Agile Framework® (SAFe™). These patterns are of course quite useful, offering us guidance on what has worked for others, but attaching an organization too tightly to any specific methodology is a mistake.
True agility is by definition the ability to adapt; thereby, the concept of “one best way” is absolute anathema to this objective. The right way to approach these frameworks is to pick the simplest one that seems to fit your situation, then adopt complementary methods over time, emphasizing the realization of desired outcomes over process adherence.
For instance, Scrum is a good starting template for team formation. Kanban is great for operations and maintenance. And SAFe offers guidance for organizations running large initiatives with many dependent teams. However, none of these is truly universally applicable, nor are they mutually exclusive. For instance, Scrum might be too restrictive, Kanban too open-ended to drive real change, and SAFe overly complex for many environments. However, a nice cocktail of SAFe for agile program and portfolio management, a Scrum/Kanban/XP hybrid for team delivery and Lean Startup techniques applied to product management might work very nicely.
There is no single best practice in agile methods, and those who have been paying attention will have noted that the methods themselves have evolved substantially over time. Don’t be a zealot; these approaches are simply a means to the end of being more flexible, fast and effective. So focus on those goals and adjust your practices over time to meet them.