Start With Why

It’s very typical for Construx to get an inquiry from a prospective customer on whether we can help them with their Agile adoptions, whether in the planning stage or in-progress. Well, of course we can because that’s a key part of our business, but it still helps to have a further conversation to ensure that we understand the client’s goals for their adoption.

We often discover quickly that the client struggles to clearly state goals without engaging in a form of circular reasoning, e.g., “We want to adopt Agile because we want to use Agile on our projects,” or “We believe that an Agile adoption will help us do Agile.”

Agile Adoption Phases

One of the key findings we tell our clients is that an Agile adoption is a program; a combined effort that we can break into phases (or projects), with each phase having a defined starting time, defined scope, and a defined output with success criteria.

For instance, the first phase of an Agile adoption may have the goal of establishing successful utilization of Scrum along with Agile planning and estimating practices for a small project with a couple of Scrum teams. The success criteria being an increased understanding of how Scrum works along with development of organizational knowledge sufficient to support transitioning additional small project teams to Scrum.

I have a saying I will use repeatedly with clients to remind them to apply a standard approach to work: treat projects as projects. Projects need to have a clear, measurable goal, be planned at a high level, and we need to establish a baseline scope, schedule, and budget we can track against and adjust based upon reality.

State the Goal

The first step is to understand and be able to clearly state the goal, to start with why.

‘Wanting to do Agile’ is not enough; to do something merely for the sake of doing it has no business value that will justify the expense in time and money. To eliminate the limitations of circular reasoning, I will ask questions such as, “Why do you want to undergo an Agile transformation?” and “Why do you want to become Agile?”

Eventually, after employing some root-cause analysis techniques we’ll often get to the core problem: a variation of the statement that the client’s organization cannot effectively satisfy the demands being placed upon it by the larger business. Oh, sure, they may be hitting dates, but at the expense of dropping needed functionality. Or perhaps worse: by letting significant known issues go into the users’ hands.

These compromises result in the business falling further behind in the market. However, discovering the problem is key to devising an effective solution. Our goal has now changed to “Having the ability to meet or exceed the level of demand the business places upon us, in terms of scope, quality, and timeliness.” Now we have a quantitative target we can use to devise an effective, practical solution and measure our efforts against.

Do all of your projects have goals? If not, can you see the association with lack of explicit goals and floundering projects? Begin with the end in mind by starting with why. A clear, concise, quantitative goal is the key to successful projects: successful scoping, planning, decision-making, and tracking. How can you succeed without it?

If establishing clear goals is something your organization is struggling with, whether it’s on projects in general or on your Agile adoptions, contact us and we can help.