Developing agile practices is the most important investment you can make in digital transformation. Agile methodologies enable multi-disciplinary teams to focus on short-term execution goals and leverage feedback from customers, end users, stakeholders, and systems to guide changes in priorities and requirements. Agile should be every CIO’s digital operating model.
But just saying your teams are agile, hiring scrum coaches, and deploying agile collaboration tools will not get you the business benefits and outcomes CIOs and IT leaders require from agile methodologies. Agile is both a bottom-up and top-down process that must mature and evolve as strategic priorities and organizational needs change. Successful agile programs require CIO leadership and involvement – not by micro-managing the process, but by setting principles and influencing where practice standards are required.
I’ve deployed agile practices in many forms as a CTO in startups, a CIO in enterprises, and now as a guide to organizations driving digital transformation. Top CIOs who lead smarter and faster IT organizations adopt agile methodologies as part of their operating models. Here are some realities CIOs should know when maturing agile methodologies.
[ Is your team just going through the motions? Read How to spot an agile faker. ]
Reality 1: Standardizing and scaling agile should not be the goal
When adopting agile methodologies – regardless of which method you choose – the goal should be business outcomes, and the vehicle to get there includes flexible agile practices. Too often, IT organizations get hung up on which methodology they should adopt and then spend way too much time trying to adopt a methodology that may or may not be best for them.
The reality is, scaling and standardizing any methodology is a change management program and has a cost. It’s particularly challenging with agile because many people have practiced some form of scrum or Kanban in their careers, so they have different understandings of agile methodologies and agile practice expectations. Scaling agile can too easily become the goal and shadow the actual business objectives.
Furthermore, a one-size-fits-all approach isn’t optimal. Innovation teams with highly-skilled developers require different agile practices than support teams performing regular enhancements on mission-critical and regulated enterprise systems. I have found scrum most important when product owners and business relationship managers understand the role of prioritizing backlogs, while Kanban may be more effective in operational teams responding to small requests and incidents.
Here are some questions CIOs and IT leaders should be asking instead:
- Should the organization support scrum, Kanban, or both, and with how many process variations?
- If digital transformation requires many teams coordinating on application development, data science, and cloud migrations, where should IT leaders create process standards, and when should teams self-organize?
CIOs and IT leaders should be heavily involved in setting agile principles and standards and then get out of the way to allow teams to get their work done.
Reality 2: Scrum requires agile planning disciplines
Even after selecting agile methodologies, IT organizations need to determine agile planning practices and principles.
When it comes to agile delivery, you’ll find a significant body of knowledge about the practices of writing agile user stories, committing to work, and delivering it by sprint’s end. But planning the backlog, prioritizing it, and forecasting releases? That’s a pain point for many agile teams because leaders frequently shift priorities, the impact of technical dependencies are hard to anticipate, and teams have inconsistent estimating practices.
Agile teams that don’t plan a few sprints ahead can leave CIOs and their project management offices in a bind when they are asked to deliver strategic plans, propose roadmaps, or forecast timelines.
The reality is scrum requires agile planning disciplines. For digital transformation, innovation, data science, and application modernization work, I advocate agile continuous planning practices where teams commit to developing their backlogs along with their commitments to deliver completed work. Other forms of agile planning include SAFE’s program increments, where teams gather for a planning sprint to discuss priorities, plan backlogs, and resolve dependencies.
It’s hard to deliver on a vision or transformation if teams report only on their Kanban board’s status or progress against an upcoming scrum release.
Reality 3: Agility requires product management, software development lifecycle, DevOps, and data science
Agile provides a vehicle to enable multi-disciplinary teams to experiment and get things done, but it’s not a transformational silver bullet. Agile requires a symphony of other disciplines and practices, especially when the target is digital transformation.
Here are some specifics:
Product management
Whose responsibility is it to define the vision, customer segments, value propositions, and priorities based on customer, employee, and stakeholder feedback? Many organizations are adding product management functions to address these questions and ensure that agile teams focus on delivering business and customer value.
Software development lifecycle
When teams deliver applications, software, and code, scrum’s effectiveness depends on an accompanying software development lifecycle (SDLC). At a minimum, the SDLC should include application architectures, coding standards, and development tools that work within the boundaries of agile sprints, releases, or Kanban’s boards.
DevOps practices
IT leaders want agile to help teams deliver results faster and deploy changes more frequently. However, a team’s release velocity is bound by any manual steps to test, integrate, package, and deploy applications. When agile teams also invest in DevOPs practices such as CI/CD, continuous testing, and infrastructure-as-code, the automation enables them to deploy application changes more frequently and reliably.
Data science
Agile is not just for application delivery teams, and it can be less optimal if IT operations or data science teams follow waterfall or other methodologies. Even if these teams follow different agile methodologies, it’s particularly important to have common tools and principles because digital transformation, machine learning, and cloud migrations often require allocating work across these disciplines.
While agile, scrum, and Kanban require practice depth and implementing dependencies, they don’t need to be overwhelming. Leaders should focus on business goals and ask teams, “What agile process or other improvements are needed to achieve these goals? And how do you prioritize them?” The leader’s questions should guide teams to where process improvements are tied to business goals, and teams should identify appropriate process areas to mature.
More importantly, leaders must recognize if teams step out of their responsibilities and bring in people with the right expertise. For example, a team charged with developing applications should bring on IT Ops when working on cloud infrastructure rather than signing up for DevOps-related tasks.
Getting teams to think in sprint-sized process development and improvement is what drives agile cultures. CIOs need these cultures to win the short sprint-to-sprint game as well as longer transformations.
[ Want agile and DevOps best practices? Watch the on-demand webinar: Lessons from The Phoenix project you can use today. ]
