For today’s “Ask Dear Agilist,” we’re going to do something a little different. Earlier this month I had the opportunity to have a panel discussion with Clint Skelton and Shawna Brown, PMP at the PMI Inland Northwest Chapter’s (www.pmiinw.org) Professional Development Day. The 60 people in attendance generated an enormous number of questions most of which we couldn’t get to during the lunchtime panel. Clint and Shawna have graciously agreed to help me answer some of them here. We’ll post more from time to time.

Q: How can one convince an organization (the senior IT execs for instance), who’s done waterfall only so far, that Agile is good for certain things?

Clint: I think you have to find an executive level advocate who will make sure you have what you need to get one scrum project off the  ground.  This will probably be someone who is not satisfied with the current pace of project completion who is also willing to accept some risk to find a new solution. Target someone in your organization that might fit this description. Sell them on the benefits of Scrum, and get them a list of what you need. At the top of the list should be an experienced Scrum trainer.

DA: I’d start by asking them what they wish was different in their current environment or what their major pain points are historically. Like any good lawyer, though, I don’t ask questions I don’t already know the answer to. Most senior managers struggle with the same kinds of issues: Lack of visibility into what’s going on in development, Difficulty staying on time and on budget, rapidly changing stakeholder needs that their organization can’t keep up with and trying to remain within the bounds of time and budget while scope continually grows. For any ( and maybe all) of these problems, a traditional single-pass phased development model turns out to be a source of a lot of the difficulty. It’s difficult for stakeholders to really define what they want up front without having actual software to react to. We spend a lot of time building things it’s later determined are relatively low value. The cost of change (i.e. big changes late in development when we know a lot more, but have less time and money to work with) is very high. Taking an agile approach alleviates a lot of these issues. Stakeholders can react regularly to increments of functioning software, low value features are recognized and replaced with higher value features frequently as the development team and stakeholders learn together what will make the product useful. Committing to delivering a product increment every 2-4 weeks means we can release any time (either a whole product or just the highest value features as they’re developed) Ultimately, though, convincing senior management to try a different requires A) That they see a real need for change and B) They’re willing to trade the “illusion of control” for the “ability to steer” and recognize that they too will have to change their thinking and behavior. After that consistent demonstration of results sells the approach.

Q: Is Agile only for software development projects? How do you implement it in non software development projects?

Clint: There are agile methods like Scrum and XP that were developed specifically to do software development. My experiences with software development and implementation have been much more pleasant and rewarding since I’ve been able to learn, practice and teach Scrum. I can’t imagine going back to waterfall. For non-software development projects, I believe all the principles still apply. I think you do get into some difficulty if there is more than one organization involved, and that organization doesn’t use agile methods.

Shawna: I’ve actually used Scrum for managing some of my non-software development projects.  I kept pretty much to the same agenda that I’ve used with software development projects (pulled from Collaboration Explained: Facilitation Skills for software Project Leaders, by Jean Tabaka), We performed planning meetings at the beginning of an iteration/sprint and retrospectives at the end of an iteration/sprint.  Our sprints were a little longer (more like 4 weeks) and we didn’t’ have a separate demo meeting, but wrapped that into the retrospective if there were things to demo.  We had weekly stand-ups, not daily as the project didn’t require it.  We covered the same things: What did you accomplish last week, what do you plan on working on this next week, what blocks do you have.  I’ve used these same methods when opening a new branch (financial institution).  We didn’t always know what sorts of equipment we would be putting in there, colors for the walls, materials for the floor, cabinetry, break room logistics, etc.  I think you can pretty much take any type of work that needs to get accomplished and wrap it into this process.  I recently gave a talk at a local Geek Girls group meeting where we did a mini-planning meeting where we walked through stories around writing a will, a small landscaping project, wedding planning, book editing and more!  We’ll be perform our retrospective at next month’s meeting, it’ll be interesting to get other’s input on how the process worked for them on their non-software projects.

DA: I don’t have much to add here. Some agile approaches, like eXtreme Programming (XP) are engineering heavy. They probably don’t make much sense for non software projects. The basic principles, however, are useful any time we have a complex problem to solve that requires human creativity. Scrum, in fact, has no engineering practices it prescribes and can be and has been used to manage any kind of work where agreement (about requirements) and certainty (about how to meet those requirements) is variable and likely to change. I’ve used and seen Scrum used for all kinds of non software projects (advertising, media, non-profit work, homeschooling, home remodeling etc.)

Q: What is the biggest pitfall of doing Agile?

Clint: Thinking that it is a silver bullet. Scrum is easy to understand but hard to implement. It takes a lot of hard work as it will immediately highlight the dysfunction within your organization. Fighting thru the dysfunction is hard and requires patience and perseverance, but it is worth the pain!

Shawna: The biggest struggle for us has been getting folks (especially developers) onboard with the idea that you don’t need completed requirements up front.  It’s asking some to get out of their comfort zone and solicit just enough requirements so that they can make an informed decision on what feature to develop next (the most benefit).  Some of our developers love this process and some struggle with it.  In our environment, we’re often working on developing new applications or significant feature enhancements to applications we previously developed for other staff within our company.  The end users, don’t typically know what they want or even how they want it.  We have to “develop” something and show it to them.  Then they can say, yes ~ I like that, or no ~ that wouldn’t work and here’s why.  This is how it’s supposed to work, then for the next iteration you have a sense of what to deliver.  This forces the development team to have to make some decisions/guesses up front and not everyone is comfortable with that.

DA: Failing to understand that to “do” agile you have to “be” agile. In other words one has to recognize that agility is not just another prescriptive process (or set of processes) but a different way of looking at an managing work. It requires a huge change in mindset, attitude and behavior and big change is always difficult. Failure to recognize how difficult and how much we have to change is, in my opinion, the number one contributing factor to not achieving the benefits agile approaches have to offer.

Q: Management wants results by a specific date. How do you figure out the date

Clint: By helping them understand the iron triangle of scope, cost and time and how only two can be fixed.  Fortunately, with agile methods we always focus on iterative development, which means we are always evaluating scope. We build the features with the most value and inevitably we decide certain features are just not needed. We combine this with short sprints where we learn how much work the team can accomplish, then we carefully extrapolate a range of completion dates and we refine that date with the completion of each sprint.

Shawna: We typically have 3 month releases, we commit to delivering their highest priority items by the end of a specific release.  We’ve been very good about communicating to them, that in the Agile world, we don’t think in terms of scope creep, but we will be leaning on them to constantly be prioritizing their feature requests and as now features get introduced, reprioritization of the existing work that they would like to see happen.  We commit to delivering a working product at the end of the release, not to what is going to be in it.  Focusing on delivering the right things ensures they’re happy with what is delivered.

DA: That’s the wrong question. Dates are driven by business needs (“we need a new release by the end of Q3”, “We have to have compelling new features in time for the trade show that’s coming up”, “The new system needs to be in place in time for our busiest time of year”) The business already knows these things so I’d rather start with what’s known (“how much time have we got?” “how much money can we spend?”) and, using an empirical approach, tune the scope of our efforts to the time and money available. Of course, this isn’t possible with a big up front planning/big up front design approach like the waterfall. It’s only possible if we define the work in terms of “slices” of deliverable value and regularly examine (with heavy stakeholder involvement and feedback about) what’s valuable and what isn’t (usually by reacting to a functioning partial product) and eliminating the low value stuff to pay for the high value stuff.

Q: How do you recommend implementing a software package [with] Scrum for a government agency that is hell bent on the waterfall method with all it’s gates?

Clint: I’m not sure there is much that can be done if the agency is actually requiring a certain project management method. However, if it’s not a method that’s driving the gates, you may be able to redefine those gates in more agile-like terms. Sometimes it’s just a matter of doing the “translation” for stakeholders.

DA: Again, I start by asking questions. Why do they want to do it that way? What do they think they get? How has that worked in the past? If they have good answers to all those questions I probably wouldn’t recommend trying a different way. On the other hand if the reasons are “that’s how we’ve always done it”, fear of not having control, risk of uncertainty etc. and especially if they have not been getting good results, I’d lay out for them why another approach might be warranted. It really comes down to determining their real motivations (which they may not even be aware of) and showing them alternatives.

Clint Skelton has been in systems and software development his entire career. Clint’s most recent experience has been in promoting agile development frameworks and leading new Scrum teams. Clint says, “I’ve stayed in the field because I have a strong desire to deliver valuable software tools to users. In my current position we’ve thrilled our internal customer by quickly delivering innovative solutions for their highest priority issues.”

Shawna Brown is a Project Management Professional (PMP®) and Certified Scrum Master (CSM) with over twelve years experience in software development and project leadership in the financial solutions industry. For the last 6 years she has focused on IT Project Management using Agile methods successfully in software development and implementation projects. Shawna tells us, “Action-oriented and take-charge attitude gets results. While a passion for people with the ability to adapt to change enables success.”

Jimi Fosdick
CST