Oct-22-2008

Embracing Change with Agile Practices

Post written by Chris Spagnuolo. Follow Chris on Twitter 15 comments

Building software is complex. Every time you think have something nailed down, the requirements change. In fact, it reminds me of a quote from Al Gore’s “An Inconvenient Truth“:

“It’s like beach combing. Every time the tide comes in and out, you find some more shells.”

In software development, every time you show your progress to your end users or talk with your stakeholders, you get feedback…more shells. How can you respond to that feedback, that change? It’s a question I hear often and in my opinion, agile practices are the answer. But how do you describe agile and it’s ability to embrace change and complexity to someone who has never heard of agile? I spent many years in the geographic information systems industry so my thoughts logically went back to mapping systems for an example of how agile embraces change. Let’s use the simple example of trying to drive to a meeting destination that you’ve never been to before. You need some directions.

Let’s start with MapQuest. In MapQuest, you start by entering a starting point and a destination. MapQuest assumes you know where you are starting from and where you are going. MapQuest returns a complete set of step-by-step directions from your origin to your destination. So, you print out your directions, get in your car and start driving, following the stepwise directions. Then, you encounter a problem. The highway is closed due to an unexpected accident. You exit the highway, look at your step-by-step directions from MapQuest and sigh. Now what? You don’t know where to go because you only have the original step-by-step directions. You’re in an unfamiliar place. There are no detour signs to guide you. You’re stuck. You try going one way, but that doesn’t work. You try another way and that doesn’t work either. Before you know it, you’re lost. You’re late. Your printed directions are no longer useful. You might never get to your destination now. MapQuest is waterfall. MapQuest is how we traditionally developed software. Have an origin, an end point and a set of step-by-step directions to guide us from origin to destination. It doesn’t allow feedback into the system. It doesn’t allow for deviation from the plan.

Next, we try out Google Maps. In Google Maps, you do the same thing you did in MapQuest. Enter a starting point and a destination. But Google Maps is a little different. If we know ahead of time that there is a construction project or an accident on the highway, you can dynamically drag the route Google Maps provided and “draw” a route that avoids these problem areas. Google Maps reroutes you on the fly and provides you with a revised set of directions. So we print out our “smarter” directions, get in our car and start driving. But if we hit any unexpected obstacle, we’re in the same situation as we were in with our MapQuest directions. Google Maps is a little more agile, but it requires prior knowledge of the problems you might face to avoid getting slowed down or lost on your way to your destination.

Finally, we get a GPS unit in our car. We get into our car without any printed directions. We turn on the GPS and all it asks is “Where to?“. It already knows where we are; it just needs to know where we’re going. The GPS unit maps out the shortest path from our current location to our destination. It presents us with a general overview map of the route, but provides us with detailed directions only as we need them. It only gives us enough information to make the next turn. It doesn’t present us with complete step-by-step directions. And, the GPS constantly inspects our current position in relation to our destination. If we encounter obstacles on our way and need to deviate from the route, it adapts the route on the fly and provides us with new directions to reach our destination. And maybe while we’re on the highway, our client calls and tells us they changed the location of our meeting entirely. Our destination has changed. So, in mid-course, we can tell the GPS unit our new destination. Without hesitation, it provides a new set of directions to our new destination. GPS allows feedback into the system and it adjusts course based on this feedback. GPS is dynamic. GPS doesn’t mind if you find some new shells. GPS is agile.

Share on Facebook
Post to Google Buzz
Bookmark this on Yahoo Bookmark
Share on FriendFeed
Bookmark this on Digg
Share on reddit
Share on LinkedIn
Share on StumbleUpon
Bookmark this on Delicious

  1. Jeremy said,

    When you use this analogy on your customers, be ready for the follow up question. “So how do we do GPS development?” The customer will need to see your confidence and understanding of Agile development before they buy into it.

    Great Analogy.

  2. Lee Correll said,

    As with almost any analogy, it breaks down if one pushes it too far. However, in this case, there’s an opportunity to push that analogy a little further to reinforce another Agile point that I think you might use.

    Cost.

    MapQuest’s cost is upfront – you spend the time/$ and get an end result. No further expenditure is possible – it’s like putting out an RFP and getting back an end product with a fixed (and known) cost. You have to spend the time/$ to do the whole thing over again if it doesn’t work.

    GPS has both an upfront cost (unit purchase) and a regular (but possibly variable) recurring cost – updates to the map / software. Also, there is the time involved in computing the reroute, which has a cost to you…versus no options to even do that in the other scenarios. The more you play with it, the more options you have, the more time it takes, the more money it costs…just like Agile.

    I’m overseeing a (mostly) Agile product in-house at the moment. I selected the methodology for the customer because I saw the typical methodology results as a failure-in-waiting. By pushing the positives straight out of the XP (for example) textbook, I got near-instant buy-in. Regular feedback, the ability to watch progress happen, the customer’s ability to document and prepare for training and acceptance testing, and the extremely rapid ability to adapt overcame the budget obstacles, especially when I had them factor in the cost of preparing documentation for a proposal in the first place.

    I could call it “Agile” or I could call it “Oreo cookies and mud” – the customer doesn’t care. Appropriate expectation setting should address any concerns along the way, regardless of any analogy I use.

    Good analogy on your part, Chris.

  3. Kiet Luong said,

    Let’s take the discussion of Agile methodology into a regulated environment e.g. pharma industry where software / application development, testing, and implementation follows the tradtitional waterfall methodology, and requires validation where documented deliverables are produced depending on system or business criticallity.

    Since Agile methodology as you described as being ‘dynamic, adaptive, and flexible’ to changes. How do you see Agile methodology be applied to the regulated environment to ensure successful development, testing, and implementation of software/application while producing adequate documented deliverables for audit purposes?

  4. Hubert said,

    My approach with regulated environments is to look at the regulations as requirements, not as process steps. If your regulations demand certain tests or documents, then these become a deliverable in the agile process. Some can become part of the definition of ‘done’ others will appear on the backlog, with a priority and acceptance criteria attached to it.

    Does this help?

  5. Chris said,

    Thanks Hubert for providing an answer on agile in a regulated environment.

  6. Ben Carey said,

    I think that the flexibility of Agile is equally applicable to regulated environments as well. Like Hubert mentioned – these just become deliverables and tracked like everything else.

    In a regulated environment – you might also want to take a look at your assumptions around documentation and question the best way to deliver these. There is usually a high-degree of flexibility in how the regulation are met. Many times it’s not documentation that is required, it’s validation. In those scenarios, wouldn’t executable specifications allow you to meet the criteria? Documentation and acceptance tests can be the same thing – why not cover both with the same activities?

    There are also many times that it’s possible to generate documentation that conforms to the appropriate regulations. You just need the rigor in your engineering practices to enable that type of capability. This isn’t necessarily an “agile” thing – but I certainly see these type of solutions more in agile environments.

    There is a lot of creativity that can be applied to regulated environments, it’s just not done very often. I’ve seen CCHIT documentation done in Fitnesse (it was documentation as well as tests) and I’ve seen regulations as part of the Definition of Done with automated validation done as part of a Continuous Integration process.

    These example may or may not be applicable – but you can certainly get much closer to the answer by rethinking your assumptions around the regulations. It’s often much easier, rewarding, and even more ethical to meet regulations in a manner that can be validated at the click of a button or on the event of committing code.

    As an auditor, would you rather see a word document (which can easily be out of date or written from a slanted view) or have proof (like automated tests) that serves the same purpose and can be demonstrated repetitively? In my dealings with regulatory boards, the latter usually wins :)

  7. Matthew McKnight said,

    I think this is a little late in the process to show the advantages of an agile approach. Most organizations have a change control process by which requested changes are estimated, evaluated as to whether they are worth the cost, and then prioritized. The difference with an agile method being that you didn’t spend as much time up front trying to get the customer to commit to an abstract representation of the solution, preferring to use an iterative approach to get early feedback on the real thing. Agile expects and plans for the first version to be require more work, instead of pretending that is correct because it conforms to the specification. Agile methods focus on getting the product right, while higher ceremony methods seem to be more focused on getting the specification right. Focus on the correctness of the spec causes problems, because it is much easier for the stakeholders to determine that the product is correct than it is to determine if the spec is correct.

  8. Jason Little said,

    The simplest way I explain it is that change is inevitable and no one can see the future. That’s just a fact of life. There are many techniques I’ve read about and used for handling change and the biggest mis-conception I’ve come across about Agile is that people say “we don’t plan, we’re agile” or “we don’t how much it’ll cost or how long it’ll take, we’re Agile”.

    Handling change in Agile is simple, there are techniques for forecasting releases and it’s much easier to show a client the impact of the change. In some certain situations the change can be accepted by the team and ‘done’ in the context of the release, in other cases the change will increase cost or extend the schedule or something else gets dropped. What’s most important is to make sure the stakeholders are part of this process so they can choose the right path for the business.

    To address the question about describing this to someone who has never heard of Agile, it’s simple. Common sense says that if you ask for more stuff you have to pay more and take longer to get it or you have to take something out of the requirements.

  9. Venu Tadepalli said,

    After reading your article it seems like following agile is like wandering around in search of God! There is a need to promote feedback with focus on end goal. In simple terms we need not solve every problem ‘today’ but we do not want to loose sight of our problems either. So, the best way to embrace change is to make it part of product backlog and prioritize it with respect to release goal.

  10. Jason Hoffman said,

    I’m not sure you need to describe it. If you keep your customer engaged as a part of the project team, and ask them to prioritize every change in relation to everything else on the table, they’ll find out the benefit all by themselves. Building trust is important. If you ask for their feedback but don’t listen, you’ll quickly lose their trust.

  11. Keith Sterling said,

    I don’t think GPS is agile, unless you use it an agile manner. If GPS was Agile, we’d start with a general idea of where we want to go. I’m from the UK so have to use that as an analogy.

    As a customer I want to travel from Edinburgh to London, so that I can visit by Aunt.

    London is a big place made up of many districts, but at this stage I’m not that concerned about which one. I want to navigate out of Edinburgh, Iteration 1.

    When I get out, I want to stop and evaluate my journey todate, was it efficient, was it the quickest. After that I program my GPS for the next stage, Iteration 2, to get across the border into England. and so on and so on.

    As I travel the 400+ miles I begin to decide where in London I want to be, and firm up which district I was to end up in.

    Half way there, my Aunt phones me and tells me she has moved to the outskirts of London. At my next stop ( end of iteration N ), I reprogram in the new location and head off in that direction.

    Now the GPS is truly Agile

  12. João Gomes said,

    First project is the key. You need to make sure your business users are familiar with the concepts of Agile but you can’t expect an immediate comprehension of the full span of the methodology. Challenges come after the first demo and the first backlog settlement that should include feedback. This is when business users actually grasp the concept that to include changes they need to postpone less value features (and that they aren’t getting the best of the two worlds: fixed scope ensuring all defined features are implemented plus changes) . This phase is the most demanding for the agile team. Managing expectations from start and keeping users involved is a must, but sometimes you need to show them on the fly that you can implement the changes they want but that might not be the wisest choice. Of course you need technology that supports this agility.

    At OutSystems it is not uncommon to have a team member sitting next to the business users and implementing some minor changes in front of them, or coming back to users the following day with a new version. The platform allows this and business users get the comfort they need that they can get what they want, if not now, on a following iteration or release. From here it’s easier to engage the business users in prioritization.

    Following projects become easier, even if the stakeholders change, as you already have the organization aligned with the success of the methodology.

  13. Russell Pannone said,

    How do you describe agile and it’s ability to embrace change and complexity to someone who has never heard of agile?

    Focus on helping the audience/team come to their common understanding of what it means to be agile individually and as a team.

    Start with describing being agile as made up of 6 elements. 1) leading change, 2) internalizing and externalizing the 4 agile values and 12 principles, 3) iterative and incremental product (system/software) development, 4) Scrum, 5) people, and 6) peoples tried and true practices (common approach to their work), like Two Level Planning (Release & Sprint), Mastering an Iteration/Sprint, Continuous Integration, etc.

    Available evidence shows that most organizations can be agile but make terrible mistakes because they do not effectively deali with helping folks and the organization at large move out of their comfort zones. The key is to have a strategy and an action plan to effectively deal with this organizational cultural transformation.

  14. Huet Landry said,

    Similar to Joao, I’ve found it to be helpful to have the stakeholders view the Agile project as a fixed cost increment in a series of efforts focused on certain business goals. We agree to expend a certain amount of effort (fixed team size) over a certain amount of time (fixed number of sprints). At regular intervals (daily, and at the end of each Sprint) we will evaluate the progress with respect to the business goals, and adjust future tasks accordingly. This translates quite well, and often leads to an “aha!” experience for the stakeholders.

  15. Huet Landry said,

    Similar to Joao, I’ve found it to be helpful to have the stakeholders view the Agile project as a fixed cost increment in a series of efforts focused on certain business goals. We agree to expend a certain amount of effort (fixed team size) over a certain amount of time (fixed number of sprints). At regular intervals (daily, and at the end of each Sprint) we will evaluate the progress with respect to the business goals, and adjust future tasks accordingly. This translates quite well, and often leads to an “aha!” experience for the stakeholders.

Add A Comment

 


Creative Commons License
©2011 Edgehopper.com. Please don't copy me, it's bad karma.
Edgehopper by Chris Spagnuolo is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.