Agile and The Need For Change

October 9, 2013

This post contains draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran

Before we talk about what agile development is, why are you considering it? Is it because agile development is the new, cool thing to do? If the cool kids are all doing it, we won’t look good (cool) because we aren’t doing ourselves, right?

As agile development has gained momentum in recent years there seems to be more comments about internal pressure “from above” to adopt agile in organizations, despite limited knowledge about just what being agile is all about. If this is where you are, this guide will help you understand what agile can do for you.

Perhaps you already have some very specific reasons for adopting agile development. In other words, you are dissatisfied with the status quo in one or more ways. In that case, this guide can confirm that your own dissatisfaction has merit and that agile can indeed help your situation.

This chapter opens the discussion by talking about the typical challenges that we have with software development. This will set the stage for how agile development differs and we can apply an agile approach to address the problems covered in this chapter. And if you feel that I’ve missed something important, let me know!

I’m following the ADKAR model, where this chapter is designed to create or sharpen your awareness of the need for change and (hopefully) instill a desire to make change happen:
Figure 1-1 The ADKAR model for change in business

Let’s explore a hypothetical scenario and see if it matches your own experience in some way.

A Common Scenario
Assume that you are a business person who has a GREAT IDEA for a software development project, and that it is your vision to build a new software application to automate the processing of complex, inbound orders from external sales agents and business partners. Today, this work is being performed by a couple of dozen people who must take orders received in various ways and key this information into your systems while they review and assess the information.

You have determined that an automated system using predefined business rules could process 80 percent of the business process without requiring human intervention. The remaining 20 percent would be the exceptions that require an actual person to review and assess the information and work with the customers to resolve any issues. Your recommendation includes upgrading a portion of your existing system where internal staff needs to retrieve and update customer data and orders as well.

Your elevator pitch includes how it is possible to cut costs while streamlining operations, enabling your company the ability to service customers faster and more reliably than ever before, a necessity in today’s hyper-competitive world. The executive steering committee agreed with your assessment and pledged to fund your project provided the development organization can deliver with an agreed-upon investment cap.

You are green-lighted to flesh out the requirements and create a plan with the projected development costs. A full development team isn’t available yet, but they don’t need to be. Your next step involves expressing the requirements to a business analyst and project manager who pull in key resources as needed, such as a software architect and senior developers from time to time along with a development manager.

You work long and hard and you are asked a lot of detailed questions as they review the requirements and create a high-level design. Finally, after weeks of grueling work, the requirements are captured! You sign off and agree to keep the requirements “frozen” so the development team can create the PLAN. The project manager pulls the full team together and develops the PLAN with all of its tasks, resource allocations, estimates, and dependencies identified.

After some back-and-forth discussions about the tasks and the projected delivery date with executive stakeholders, everyone agrees that the PLAN is reasonable. It even has some buffer time built in. While you don’t understand all of the ins and outs of software development and some of the details included in the PLAN, you trust the professionals. Everyone is happy because everything looks solid and predictable. The project is approved for implementation.

The project commences and stays on track in the early phases. There are weekly updates with a solid focus on delivering to the PLAN. The development team begins by creating a detailed design, during which you are asked to clarify some of your requirements even further. Later, as the team begins to build out the architectural layers of the code – the foundation that the business features will be implemented against – you are asked even more questions.

At this early stage there is little for you to actually see, other than tasks being checked off on the project plan. But you feel confident because of the questions you are being asked. Your confidence is bolstered by the fact that weekly updates and reports indicate that indicate that everything is on schedule. You can sense that even the development team is optimistic that this time, they’ve done the right planning.

Eventually, the development team begins to add the actual business features. And they have even more questions. You discover that you can’t answer all of these questions yourself – at least not timely enough for the development team – because you have become an intermediary, quizzing those on the front line about specifics that you haven’t had to deal with in many years, before you were promoted.

So you bring in a couple of those on the front line to directly respond to the development team’s questions. Despite the fact that they know that many of them are being automated out of job, they engage with the development team, trusting you and your assurances that the company will find them new positions elsewhere in the organization when the time comes, with hopes that a few will remain to handle those customer exceptions you identified.

You get the sense that there are differing opinions about how things should look and feel, but those are – as the development team has pointed out to you in previous conversations –“implementation details.” You figure that they will be able to work out the minutiae without you. As a result, the PLAN begins to show that some tasks are behind schedule, but everything appears minor and no one is overly concerned.

As time progresses, the problems don’t disappear, they get worse. The PLAN continues to slip, aggravated by change requests that are made after each milestone review. Users complain that the development team doesn’t get it, citing that the software as written won’t work for them. The development team complains that they’ve delivered according to spec and that changes will impact the schedule.

The project manager negotiates new dates as changes are requested, which are generally modest. There are times when pressure is exerted by management to keep the date and “make up the ground” because the perception is that the development team missed an obvious need.

At some point late in the project, there is an eruption. The realization begins to dawn on everyone that the PLAN is in serious trouble. The development team is now telling you that the date won’t be met, at least not with all of the features that were originally planned. And the miss isn’t projected to be a small one, either. The team is saying that they literally need months of additional time to complete the project.

Despite the fact that you’ve been very disciplined about not adding any new features – including compromising here and there on the specifics of other features in order to keep the application less complex along with deferring on some change requests – the development team is stating that some things are simply much more complicated than they anticipated. This complexity coupled with the approved change requests that were approved are now taking their toll. “Either the date must move out or features must be cut,” they say, looking at straight at you.

Everyone is clearly frustrated and after some difficult meetings where your original vision is “cut down to size,” the VP of Development “meets you in the middle” and makes the call to add a few more people to the project while insisting on heavy doses of overtime to complete the project, holding those who provided the estimates at fault for not meeting their commitments. You also “agree” to rigorously scrutinize future change requests with the VP of Development, which you know translates to: “We won’t be approving many additional change requests so that we can complete this project on schedule.”

Next post: What Happened?

Hiatt, J. (2006). ADKAR: A Model for Change in Business, Government and our Community. In J. Hiatt, ADKAR: A Model for Change in Business, Government and our Community. Loveland, Colorado: Prosci Learning Center Publications.



gile Expectations: What to Expect from Agile Development, and Why

June 21, 2016 at 11:48 PM

Post a Comment