Three Agile Management Practices for Driving Digital Transformation

When I joined Businessweek ten years ago to lead their digital technology team, I was very surprised that they wanted to develop their own proprietary web applications. Could a magazine owned by a publisher mature a software development practice and deliver new customer experiences?

The answer was yes - and as it turns out - many other companies are investing in their software development practices as part of their digital transformation programs. In many cases, the investment is driven by businesses needing to improve customer experiences with mobile and other capabilities. In other situations, businesses are looking to automate processes, become more data driven, or enable a strategic advantage with new capabilities in IoT, blockchain or artificial intelligence.

Whatever the driver, these IT departments are trying to operate like software companies and are highly likely to be establishing agile practices central to their transformation.

Teams, standups, demos, retrospectives, story writing, backlog grooming, sprint planning and other practices and tools follow. But are agile rituals sufficient to enable an agile culture or help drive transformation?

To enable transformation and enable an agile culture, organizations should consider the addition of the following  practices -



Aligning Product Management to Agile Delivery


A very common issue facing organizations looking to invest in application development occurs when agile is only applied to the delivery team (technologists) while product management participates only in tactical ways. They'll show up to to sprint planning to make sure their priorities are aligned and then to demos to review the deliverables. That may be the extent of the interaction. Now I've posted on the 20 bad behaviors of product owners and how to handle difficult product owners from many experiences working with product owners that don't fully align with agile practices. I've also suggested the 10 practices of strong product owners which center around market needs, collaborative behaviors, and being data driven.

The most common source of misalignment falls into two categories.

Some product owners propose solutions instead of defining the problem, aligning with personas, and articulating acceptance criteria. Their stories read, "Build me X that does Y" instead of "Enable user persona A to achieve B because it helps them address C if the solution can D, E, and F". No development teams prefer being told what to do instead of being engaged on what problem they are being asked to solve, for whom, for what benefit, and with what constraints.

The second misalignment occurs when product owners, often feeling the pressure from stakeholders, commit to specific deliverables and a delivery schedule without consulting the development team. The result boxes in the team (including the product manager) into a fixed timeline and fixed scope release cycle that may be difficult or impossible to achieve. Forecasting release schedules and scope must be solved collaboratively with an agile planning process which I will review in the next section.

But before we get there, the most troubling misalignment is when a product owner (or owners) have both issues. They commit to business schedules and then send marching orders to their delivery teams. Organizations that find these behaviors acceptable will never achieve an agile culture and will struggle to transform. In my experience, these divisions are not a "business IT alignment" issue, but speak to a larger leadership and cultural issue with how business leaders and business teams work with technologists.

What does alignment entail? Here are some suggestions

  • Developing roadmaps together (next section) 
  • Establishing brainstorming sessions so that business and tech leaders can collaborate on solutions
  • Documenting responsibilities by role
  • Enabling tech leaders to visit customers 
  • Aligning on usage metrics, other business value measures, and delivery metrics
  • Celebrating the wins


Estimating and Developing Delivery Roadmaps


Business doesn't operate on a sprint to sprint schedule or as a continuous delivery stream of product improvements. To enable Sales and Marketing to reach customers with new or enhanced products, or to enable business teams to plan process changes with the delivery of new internal technology capabilities, some semblance of a roadmap is required to enable business planning. Business leads are simply asking, "Roughly what are you developing and approximately when will you deliver it", a question that product owners struggle answering and development teams difficulty resolving.

Developing roadmaps and agile planning is a large subject of my book, Driving Digital: The Leader's Guide to Business Transformation Through Technology. In the book, I provide guidelines on establishing an agile planning process, defining roles and responsibilities in planning, developing estimates that can aid in defining MVPs, and establishing release roadmaps.

Want some background? See my previous posts on the 1-week agile planning sprint and on developing a release management strategy.

Leveraging DevOps and Enabling Developers to Continue to Innovate


Let's say you are successful with agile delivery and your teams have put out their initial products or applications. Maybe they've even released major and minor enhancements to these applications over a period of time. So here's my question
Are your development teams innovating and improving the product, or are they buried in technical debt, spend significant time supporting their cloud environments, or are largely performing support functions like defect fixing or implementing upgrades?
You can certainly measure this in your agile tool by tagging stories and tasks appropriately. If you haven't done this diligently, I highly recommend it as the results might surprise you. In my experience, the longer a development team works together on an application, the more likely they are taking on support related tasks and executing less innovation.

There are a couple of things leadership can do at this point, but the most important one is related to how much the team spends on supporting the application in the cloud and automating the CI/CD pipeline. If the team is spending a lot of time on these activities, then it may be time to make sure that there is the right separation of duties and handoffs with a DevOps team. IMHO, one reason developers should now own DevOps is that it is a significant responsibility and diverts their attentions from improving applications and innovating.

Why These Agile Practices Drive Digital Transformation


  • Aligning product management drives productivity around the most important customer opportunities
  • Developing delivery roadmaps builds confidence of business leaders that need to support investing in transformation programs
  • Leveraging DevOps is a step to break off support related activities so that top developers can continue innovating

No comments:

Post a Comment

Share