Everyone, or at least almost everyone is doing some form of agile practices today. In fact, some leaders drive their digital transformation programs with leading agile to deliver customer facing applications. In a year of speaking at conferences, I did not meet anyone selling their waterfall, top-down project management practices as keys to their transformation programs.
But ask a few more questions and you’ll find that for many leaders, going from basic agile practices, to a scaled agile organization, and evolving to an agile culture remains a work in progress. By the facial expressions and tone of their response, my sense is that many leaders are frustrated by some of the barriers and speed bumps they face to get a normalized set of practices running across teams and to show how a cross-disciplinary agile culture drives innovation and results.
From Agile Practices to Agile Culture
If you’re one of these people, I have some news for you. It takes time leading, nurturing and mentoring teams and people to grow beyond the basic practices. Most teams can adopt the basic scrum practices first and demonstrate significant improvements in their ability to deliver applications faster, with higher quality, and closer to schedule. But going beyond this to a point where agile is an organizational strength requires leaders to go outside of their comfort zone.
What I mean by this is very specific.
If agile is only being done by your tech teams with limited interaction with the business, then it’s very hard for this practice to translate to ongoing success in a transformation program.
Some struggle getting product owners to participate properly in their agile programs and must work through organizational barriers to get the time and commitment required to deliver on this role. But even those that do bridge this gap and have participating product owners, the leader will fall short of enabling an agile culture if people from business organizations are not directly participating as members of the agile team.
When Agile is only an IT Practice
We have all seen the end results when agile is an IT process with little involvement from business leaders. The agile team delivers a technical result but fails to deliver on the business objectives.
When there isn’t
- Organizational support to participate in the program from its inception,
- Working hands to guide the program during its development stages
- A plan on how a technological change will be introduced and nurtured with end users
then there is a strong likelihood that the initiative will fail, stumble along, or underdeliver.
Why does this happen?
It’s convenient for business leaders to wrap an agile development practice with a traditional project management process.
The initiative starts with a waterfall business planning process to define the objectives and vision, an agile practice for the implementation, and then falls back to traditional project management practices when the program is ready to be instrumented with end users.
In the end, the team is doing agile, but the organization isn’t agile. Business planning doesn’t continue into the development process establishing a fixed scope of what is to be delivered and failing to leverage feedback to readjust priorities. End users are only engaged toward the end or even worse, after the delivery. This creates an uphill battle getting them enthusiastic to support changes when they’ve had limited time to input and provide feedback.
Solving the Agile Cultural Issues that Limit Transformation
Show this to your CEO, GM, or most senior business leaders participating in your transformation programs.
- I want product owners spending at least 35% of their time with the team
- I require that we begin implementing way before planning is complete
- I only support initiatives where business people take active responsibilities on agile teams
- Everything that we need to do to make the initiative successful should be in our agile backlog
If you want an agile, nimble organization then this is what it takes. If I’m implementing a data integration with the marketing team to see aggregate metrics from all lead generation activities, then marketing needs to participate on the team to provide feedback, review metrics, and steer priorities. If we’re integrating a new commerce channel into the ERP, then I want finance participating to understand the automation being developed, define business rules, and review reports that drive accurate results and scalable workflows. If I am looking to enhance the CRM with mobile optimized workflows, then I want salespeople testing the changes at the end of every sprint.
But most importantly, let’s reset expectations up front.
Agile empowers business leaders to leverage customer feedback and to adjust priorities with every release and sprint. It’s an amazing tool when used well because it means you don’t need everything planned up front before an initiative gets started, and it means that customers and end users can provide feedback as they see the product demoed and kick the tires after each sprint.
But this flexibility requires a change in mindset about vision and scope. Teams can’t deliver precisely on vision and a prescriptive scope when you’re given the freedom and empowerment to adjust priorities. You’re not just fitting a square peg in a round hole, you’re trying to fit multiple square pegs through simultaneously.
Until business awaken to this new way of thinking and working, your teams will be practicing agile without becoming an agile organization.
This is the second article of a multi-part series on What I Learned about Digital Transformation from Speaking to Hundreds of Leaders. You can read the previous article on Developing a Strategy for Putting People First in Transformation Programs and the next article on Financial Practices are outdated for the Transformation Era. Signup for my newsletter if you would like to be notified when new articles in this series are published.
No comments:
Post a Comment
Comments on this blog are moderated and we do not accept comments that have links to other websites.