29 October 2010

Is Agile All That and a Bag of Potato Chips?

Pardon the title to this post, a reference to the Austin Powers movie series, but its a question that has been on my mind a lot recently. Unlike Craig, our resident agile master, my career has been fairly sequestered in waterfall land. Its not that I haven't liked what I've read about agile; its just that no company I've ever worked for has ever done a real agile project.

Sure, some of those companies have claimed to run an agile project or two, but when the daily scrum consists of only managers through VPs and last over an hour, I can't help but laugh at the absurdity of calling that agile. That's simply a waterfall meeting with a new name so it sounds like you're doing something new and important.

When I read an article on requirementsnetwork.com about the impacts on business analysis when moving to agile, it really struck a chord with me, especially given the project I started last week. Our VP came to a group of us: a director, a manager, a supervisor (me), an architect and a contract developer, asking us if we could set up an entire new platform and have it in use by the end of the year. It was a bit daunting at first, especially if you had seen the features list, but our response was agile, even if we didn't think about it at the time.

Putting a Plan Together

First up, we took the functionality list and broke it down by user groups. Then we determined which features would provide the most benefit to our user group. We decided to focus on two specific requirements, plus the underlying architecture, as these features would stop a decent number of calls from landing in our call center.

At this point, I, as the representative for the product owner, sat down with a few of my stakeholders to figure out exactly how these features should work. I put together a small simulation, using Serena Prototype Composer, on day two and then brought my stakeholders down on day three to review. One stakeholder really liked it and the second thought I only got it half right. Back to work on day four, making modifications to the simulation to meet everyone's needs. At the end of day four, the simulation went over to the architect and developer for creation.

Day five is where it really got interesting... they finished the UI. In one day. Now, there were no business rules behind the UI and no service had been created to do the data updates in the back end system, but all of the necessary user elements were in place. Usually after I finish a requirements document, its months if not more than a year before I ever see the first actual working application.

This left me in a weird place... the developers had finished the UI layout, yet I had no business rules or requirements finalized. I didn't even have much in the way of analysis done. The next couple of days saw me spending every moment of time not already allocated to other projects in search of rule, requirements and a UI theme.

Now, its all been turned over to the developers. If the progress thus far is any indication, we'll meet the end of the year deadline. No, we're not doing a formal daily scrum, but we are keeping in touch on a daily basis as questions arise. Its been fun. Hopefully soon I'll be able to update everyone on how the project went and if our stealth agile experience was a success or not.


  1. "The next couple of days saw me spending every moment of time not already allocated to other projects in search of rule, requirements and a UI theme."

    How did you do that? That sounds like the hard part, not the UI.

  2. Let me add a bit more detail... the developers created the functional user interface in a day. There was no business logic backing it up because no one had yet done any of the analysis for how the app would interact with the planned business services.

    To find out the additional detail, which I spent more time on today, I've been iterating using Serena. I create a prototype, run the simulation, see what I can break in the process I've outlined. I then rework until I have what I think will work, then bring in my stakeholders. If they approve, I document and ship the requirements, mockups and process diagrams to the developers.

    Make sense?

  3. On what basis do the stakeholders approve or disapprove?

    Better yet, how are you outlining a process? and how are you determining what process to outline?

  4. The stakeholders are approving or requesting changes as we sit side by side and review the prototypes. No formal approvals or sign-offs needed.

    For the process, normally I do a process flow diagram. This project is a little different as the steps in the process are fairly short. For this reason, we're documenting the process more in a use case style along side the screen prototypes.

  5. Still, how you decide which process to outline? Where does it come from? Who says it is a relevant process?

    Also, really want to know, how do you validate logic and/or rules using a prototype?

  6. There was a two-pronged approach to deciding which processes to map out. First, the business area brought a list of processes they felt could be improved. I then helped them figure out which processes had a good RoI and we agreed to tackle those first. All of the selected processes ended up having a system automation potential and could eliminate call time in one of our call centers. Cost savings was the primary motivator.

    As this project consists of a couple of very short processes (5 or fewer steps each with minimal decision points for the user), the logic is mostly behind the scenes in the application. We discover that logic in two ways. First, we look at the manual process that currently exists and determine what rules need to be retained. Next, we overlay that process onto the prototype and see if any rules don't make sense for the new tool or if there are any missing rules that do need to be added.

    I operate under the following rules: if it adds a substantial burden to the user or the system hardware needs, the process needs to be rethought. I consider a burden to be a complex process with lots of manual checks or a set of processing logic that would keep the system from scaling.

    Did I get the answer this time? Sorry for the confusion; I obviously wasn't getting your point previously.

  7. Pretty much... but good answers often generate new questions.

    How do you deal with process (functional) dependence? If one process with a good ROI is dependent on another without a good ROI, do you consider them together for overall ROI and development?

    How are you defining Rules? When you say rules may not make sense for the new tool, my thought is that "rules are rules", as they are defined by the Business Rules Group at www.businessrulesgroup.org ...Rules do change, of course, but I am not sure if that is what you meant.

  8. One of the great things about this particular project is that because all of the processes under consideration are so small, there are not a lot of dependencies. There is one example relating to hours of operation where two processes (changing permanent store hours and temporarily changing store hours) are related. The former doesn't have a good RoI but the later does, namely because the former doesn't happen often but the later happens routinely. In this situation, it made sense to only do the one with the good RoI even though the two were closely related. There was enough difference, namely only one system was impacted with the temporary change where multiple would be impacted with the permanent change, that sponsors and the project team decided to limit the project to the temporary hours change. We did initially consider them together, but realized doing so would not significantly improve the business, so we split them and found the temporary process alone would be of benefit.

    Rules... yes, a rule is a rule. Its more about who is performing the action. In the old process we're looking at, the rules are built into business processes call center agents must abide by. The new process we've defined has no call center agent, but has field personnel performing actions in a portal to achieve the same results. We've taken those manual business rules and are putting them into an application where the rules are enforced consistently and without the need for a manual approval.

  9. Sounds good, thanks for the conversation!

  10. Agreed, David. Good conversation indeed.