I have repeatedly stated that for agile transformations to succeed, they must have top-down support; this doesn’t involve just funding the effort. Executives must understand what it means to be agile. Unfortunately, leaders who spearhead your agile agenda usually don’t “get it.”
Moving toward agility involves significant changes in several areas, but most importantly, it’s a shift in mindset. Here are some of the critical areas that your executives will need to re-think:
Scope is Flexible
One of the top items that executives must understand is that they won’t get to specify everything up front. In traditional projects, the scope drives the budget and timeline. In agile, it’s the opposite – your cost and schedule are fixed, and the scope is flexible; this flips the iron triangle upside down. If your leaders can understand this, you’re ahead of the game.
Products (not Projects)
Another significant change in mindset has to do with the move from projects to products. Projects, by definition, have a very distinct beginning and end. When a project is “done,” the team breaks up and gets reassigned. Products have a complete life cycle that the team must support, from initial concept to maturity to sunsetting; the team stays together until it is no longer needed.
Planning
There’s a common misconception that there’s no planning in agile – nothing could be further from the truth. If anything, you do planning on a more recurring basis. Planning happens at a high level, and re-planning happens every iteration. The Product Roadmap is updated to reflect any changes necessary due to new information or market changes.
Ambiguity
Again – executives won’t get to know what they’re buying upfront. They must accept the high-level product vision and goal and get comfortable with not knowing everything before starting. I know from experience that ambiguity can be very uncomfortable initially, but once your leaders realize that they’re getting a bigger bang for the buck, they’ll loosen up.
Value
In agile, continuous, regular value delivery is vital. What does value mean, exactly? Well, that’s a tricky question. As a consultant, I would say that every organization and every Product Owner has their definition. Some of it is subjective, and some objective. The point is that the right person decides what to focus on, and ideally, it should be what is most valuable (while considering risk and complexity).
Trust
I can’t tell you how often I have seen a chasm between business leaders and their delivery teams. It’s the classic “us versus them” (business vs. IT) fight. Agile breaks down the silos and barriers that cause mistrust. How does it do this, you ask? Simple – delivery. For every iteration, there is a working product to inspect, and you earn trust by simply keeping your commitments.
Transparency
Knowing what is going on seems simple, but sadly, in a traditional environment, it’s not. Requirements are “gathered” upfront, tossed over the wall to developers, and the business rarely has any visibility into what’s happening. In agile, transparency is one of the empirical pillars, allowing anyone to see what is going on at any time.
Teams
If you have ever been part of a high-performing team, you’ll remember it – it’s magical. But many people never get to this point because the team is disbanded and reassigned to other projects after they finish a project. In agile, your goal is to keep the group together. The longer they work together, the more efficient they’ll be, and you’ll keep them performing the best work for your company.
Skills
In the past, companies favored specialists – become an expert at something, and you prove your value. Everyone needs you on their project because only you have that particular skill. In agile, you can have team members with a primary strength, but they should be more generalists (T-shaped) with other skills they can offer. Also, all the cross-functional skills required should exist within the team.
Quality
Another common frustration of waterfall is quality since you don’t test anything until near the end of the project. By then, it’s much more expensive and time-consuming to fix problems. When time is most important, quality aspects get cut. In agile, you bake quality into every iteration. You also reduce your risk by testing as you go versus saving it until the end.
Delivery
When should you go to market with your product? Do you have to spend years working on something only to deliver something that is now irrelevant or obsolete? No! In agile, your Product Owner can choose to release whenever she thinks it makes sense. Perhaps it’s every quarter, every month, after every iteration, or even every day. When something is ready to release, why wait? Deliver the value!
Decisions
In agile, another critical mindset shift is in who makes decisions about the product. It may have been an executive committee or the CEO in the past. With agile, you push down decisions to the lowest level possible. The Product Owner decides what goes in the backlog and what gets released. The Developers get to determine what they will build for each iteration and how they will do it.
Final Thoughts
Obviously, “getting” agile is much more complicated than it seems at first blush. As stated in the Scrum Guide, Scrum is a simple framework, but it’s difficult to master. If your executives can unlearn what they have learned and shift their mindset on the items in this blog, you’ll have a much better chance of success using agile.
Now, it’s your turn – have I missed anything? What else might be vital for executives to understand before embarking on an agile journey? I’d love to hear your thoughts!