Published by Curt Conklin, on Tuesday, January 22, 2019

Executives don't want to be told they have to learn something new. Lead your stakeholders to Agile using concepts they already understand.

This is my second post on Selling Agile to Executives. Readers should note that both consultant and executive in these posts are metaphorical. The executive could be a boss, client, matrixed business unit – or if you are remodeling your kitchen, the executive could even be your wife. The consultant is anyone who wishes to lead an organization toward Agile. I hope to help both parties understand how embracing Agile is good for any project's outcome.

Recently in this series, I discussed overcoming opposition to Agile by focusing on how the framework better delivers what executives want. Specifically, these four things:

• A solution to their problem
• Fiscal responsibility
• Progress reports
• Minimized risk

Yet many executives still fear that the transition to Agile will require them to learn something new. They may be under the belief that it is complicated. They may further fear an onerous number of meetings or many documents to read and update. In today’s post I want to discuss placating these concerns by keeping it simple. In other words, bumpering the discussion by using the vernacular and ideas with which successful executives are long familiar.

If a picture is worth a thousand words, how many is a demonstration good for?

Executives like the idea of seeing progress every couple of weeks. Achieving this has been historically difficult in traditional waterfall methodologies, as nothing is really done until the whole thing is done. In the Agile world however, the short periodic demo is part of the program and called the sprint review. This meeting is tailor made for busy executives. There is no advance preparation necessary. The meeting starts with a recap of the problem solved this sprint, is followed by an action demo, and concludes with questions and answers. Executives may still request written reports, but seeing the progress eliminates the necessity of reading them. And given time and increased comfort, the request may be eliminated altogether.

What if requirements are a living list that changes and gets smarter?

Agile promises accurate requirements that change as needed. Executives understand requirement documents. In the Agile world it is called the backlog and it offers a major benefit over the traditional requirements - because it is a living document.

Historically, the executive is included in the process while the document is being written, but once it is signed off as complete then he is asked to step away. In the Agile world, that document keeps getting improved, expanded, and fine-tuned as the project continues and the stakeholders learn more about the problem. This sort of accuracy and flexibility isn’t possible when the document is completed before the challenges of development are factored in.

What if projects got closer to the mark even as the executive sponsor steps away?

Agile promises a process delivers better results while freeing the hands of the executive to focus on other things. In further contrast to the old way of doing things, the executive doesn’t even need to worry that the executive requirements document is correct. Rather, the executive is encouraged to pick a representative from the business unit, and even better, that person doesn't need to know anything about Agile or technology development either! Their two requirements are they know the business and that they have bandwidth to take on an important job. Being able to communicate clearly might be another - so OK, three requirements.

This representative, called the product owner, will be responsible for documenting the required requirements or user stories in the document called the backlog. The product owner doesn't write anything technical - just what kind of user needs to do what kind of thing to achieve what kind of results. They can start with the biggest most obvious things and drill down as they go. They don't have to catch every nuance because those will come out as the progress get demoed for their colleagues. Furthermore, they can set the priorities for the problems which the developers tackle, and even change direction of their initiative. They quickly become one with the project and are truly in control.

It is important to underscore that even though this person is part of the development team, he represents the interests of the executive and business units over that of the developers. It is this intentional conflict that balances out the Agile development process and ensures that productivity and quality are both maximized. With historical methodologies, one of these is invariably emphasized at the expense of the other as an executive's attention to the project ebbs and flows.

As a side note, it sometimes happens that a business unit representative is not available. Perhaps the team is too small, or everyone involved is too busy. In that case, the project can adopt what is called a business owner by proxy. This can be a member of the consulting staff, or an employee from a different part of the company. They may not know the business well, but they are fast learners and good communicators. In this case it is helpful that they also understand the role of the product owner in the Agile framework. Once assigned, the proxy PO's allegiance shifts to the executive and business unit as he or she is responsible for ensuring that their priorities are being followed. The Proxy PO also has great perspective and can issue his own progress reports whenever his constituents need one.

Waterfall promises delivery dates and budget that are reliably incorrect – Agile promises delivery dates and budget that are simply reliable.

Agile enables reliable forecasts for delivery dates and budgets. As will be discussed in later posts, uncertainty is expensive to a company and its executives. Through regular requirement polishing (updating the user stories in the backlog) and a measurement of team productivity (velocity), Agile teams can deliver status reports (burndown charts) that illustrate final budget and delivery date with accuracy that is simply unprecedented relative to other project management methodologies.

In the old way of doing things, executives could be certain of only one thing, that the estimates they were receiving were going to change. In the Agile world, once the gears are moving, executives can be fairly certain that what is being shown and said are exactly what he can expect.

So as you can see, Agile fits well within the conceptual framework of executives regardless of their training on the subject. By focusing on concepts that they understand such as progress reports, involvement, living requirement documents, and reliable estimates, they will be won over without having to convince them that they need to learn something new.

Please read the other posts in my Agile Series:

Story Points, Agile Estimating, and Today’s Puzzle
Better Estimating through Fibonacci
Winning-over Executives with Agile

And visit PSC's blog where you can find more posts by me and my awesome colleagues!

Categories: Agile,Agile Scrum,Scrum,Project Management

Original Post: https://www.linkedin.com/pulse/agile-without-learning-curve-curt-alan-conklin/