Propagating Agile habits and a state of mind

Agile is a state of mind. Developing agile habits is crucial. The agile lines between the business and IT are blurry. Business and IT conduit talent knows this well. I know I have to speak with multiple audiences and and agile thinking starts from the business and eventually ends there. Here are some thoughts on the agile state of mind

1. Put some skin in the game.

In an agile environment, some business-unit leaders will be tapped as product owners—that is, the business-unit stakeholders most accountable for shaping the products. These leaders must make the development and success of a product their highest priority—and they must be given the leeway to do so. That might mean shifting schedules and commitments so product owners can attend key agile meetings: scrums, sprint reviews, and sprint planning sessions (see the sidebar “Speaking agile”). Additionally, senior management may need to redeploy resources so that business units can assign product owners to individual agile-development initiatives.

Product owners not only set the aspirations and vision for the product but also colead decision making about features and development goals with colleagues in IT. They should be able to live in two worlds. They must have some understanding of technology and the ways it is transforming their industries. They must also have a strong sense of market needs and the product features that would be most valuable to end users. (Typically, that’s not an issue for most product owners who come from the business, because they interact more frequently with end users than IT managers do.) Product owners can pair this market knowledge with the engineers’ feedback on the technical feasibility of specific product features to create a clear development plan.

2. Shape the product together.

Under traditional approaches to product development, IT leaders interview business-unit leaders once to collect business requirements—for instance, what novel features are required in the new software or applications being created, and on which platforms will the new applications need to run? IT managers capture these requirements in jargon-filled documents, and the next time they reach out to the business unit, it’s with a mostly completed prototype in tow.

By contrast, agile product development is less about taking orders and more about sharing information. The business and the IT organization must codevelop products every day, side by side, in an ongoing process. Senior business leaders can establish this level of collaboration by investing in tools to improve interactions—for example, visual aids instead of lists of requirements.

At one company, a product owner from a business unit and a technology leader used sketches to trade feedback on software under development. IT professionals sketched a prototype that the product owner could page through. The product owner could circle what he liked or draw alternative versions of the elements he didn’t. The team refined the design together in a way that everyone could understand and contribute to.

 

3. Cheer for your own team.

Leaders in the C-suite and the heads of business units have a critical role to play as evangelists for the software products they codevelop: they must hold product owners from the business units accountable for the successful rollout of any new release and its effect on the business. They should encourage product owners and IT engineers to educate their business colleagues about the benefits of new software and reasons to adopt it. Agile teams can share introductory videos at the launch of a product, demonstrate it at town-hall meetings for employees, and listen to their colleagues’ frustrations with and ideas about it. All the while, they should explain that this input is valued—and demonstrate that it is by incorporating feedback into product revisions. Such transparency, encouraged and modeled from the top down, can produce a culture in which joint efforts at problem solving, rather than complaints about IT, are the norm.

4. Think like a user.

Sometimes, senior business leaders may very well be the users of the product they are shaping—if it’s an executive dashboard, for instance. But usually they are not. To help build software and products that transform the way a company operates or appeal to customers, product owners from the business must be unwaveringly committed to users’ needs. Senior executives can encourage this kind of outlook by asking targeted questions during product reviews. Who are the users? How are they using the product? Do they primarily work in an office or remotely? What are their biggest frustrations? Software-development teams should also think through these questions as they design tools and experiences to ensure that they are addressing the idiosyncrasies of end users.

5. Learn to live with ‘good enough.’ Senior executives are typically a risk-averse group. Traditional product-development models emphasize multiple check-ins at various stages of development—a time-intensive but comprehensive way to ensure that products include all the desired features and don’t contain bugs and other flaws. By contrast, agile development emphasizes a test-and-learn approach—for instance, releasing a minimally viable product that delivers value to end users in the short term but is expected to change on the fly.

In this case, chief information officers may need to help senior business executives come to terms with the release of a good-enough product by redefining their expectations and thresholds for risk. A CIO could, for example, highlight agile success stories—instances where a company released a good-enough product, shifted strategy midstream in response to feedback, and ultimately delivered a winning solution. In addition, the CIO can be open about accepting minimally viable releases refined by IT line managers—prompting similar behavior across the company. And at least initially, technology leaders could press for time-to-market schedules that give the business units no option but to pursue good-enough products.

The CIO should also help senior business leaders understand that even under a good-enough approach, agile teams will not deliver everything immediately. The process is actually more rigorous than most executives can see. Agile teams must work exhaustively to collect feedback to determine what’s working, what’s not, and how to make incremental improvements that will enhance the product or the customer’s experiences with it. And they must repeat this process over and over again.

Making the case for agile

6. Broaden the mandate.

As scrum teams ramp up their performance and experience, they will inevitably bump up against slower teams and processes elsewhere in the organization. These slower teams, such as high-volume sales organizations, use more traditional, rigid work processes. To maximize the impact of agile methods, senior leadership must consider ways to transfer lessons from agile teams to different areas of the company. Working with the CIO and other technology professionals, senior business executives can identify the processes and products that are most critical for delivering business value to customers and consider which agile principles would help to speed things up (see the sidebar “Making the case for agile”).

Source: McKinsey; Shutterstock