Agile, Customers, and Getting Things Right…
By Mike Levine
How ‘bout a story? It’s about bears…
Once upon a time there was a modest software development project focused on modernizing the FBI's suite of investigative software applications (“modest” is loosely interpreted here). All the applications that Goldilocks’ had happily played with in Papa Bear’s house prior to year 2000 were given the sign to go for the porridge: enhance the bureau’s legacy software that manages all of Baby Bear’s documents related to cases, thereby enabling them to search and analyze their Bear Necessities more easily. Sounds pretty cool. Like an episode of Cold Case Files or CSI, but with bears and little action or guns. This doesn’t mean there wasn’t excitement. In fact there was probably enough to turn the Robert Southey story, The Three Bears, into a George Clooney movie. Estimated by some at over $200 million (remember “modest”), the drama included five years of good old fashioned finger pointing, “You’re fired,” Congressional hearings, arbitration, and of course the perennial battle over the Swingline stapler. I should mention the project was eventually scrapped. Ultimately, the “New” Virtual Case File (VCF) product met its demise through a variety of reasons, including scope creep, the wrong people being involved, changes in critical resources, changes in specifications, and primarily a lack of a strong blueprint for what was to be developed.
Bears aren’t alone. According to a 2002 study by the National Institute of Standards and Technology, two out of three software projects either come in significantly late or over budget, or simply cancelled, costing about 59.5 billion to the US economy annually. Some of this might sound familiar to you. Maybe not the billions, but I think it’s fair to say that many of us have experienced software that missed the mark on what we needed. As such, we can probably relate to the cost impact to our daily lives when it happens.
Wikipedia describes software as, “A collection of computer programs, procedures, and documentation that perform productive tasks for users.” What it doesn’t say is that the collection will be inherently useful. Software might be “productive” in that it performs certain functions, but at the end of the day, software is not by its mere presence a guarantee for meeting targeted business needs, increasing efficiency with tasks, and thereby increasing performance for our customers. In other words, sometimes the product does what the box says it should but not in a way that makes the majority happy, or more specifically satisfied with the money they spent. And even if it did, it might not be on the shelves in time to truly benefit them. But it could, right?
At AMS Services, our challenge as software producers is to build high quality product fast enough to keep up with our customers evolving needs - while ensuring that what we deliver actually meets or exceeds expectations. If we don’t tightly focus on what problems are to be solved, or where specific workflow is to be improved – for our customers and ourselves - we create opportunities to simply get it wrong, making “users” well, less than useful and less than satisfied. Especially if it takes years to get the right product in their hands.
So how do we mitigate that? The business needs identification part makes sense. But what else? We probably need to have the right people involved. And they should have the time, the environment, and the way they communicate structured in such a way that they can nail it on the first pass, right?
How ‘bout another story? This time about bubbles…
Long, long ago, it used to be that software was developed by having business experts put together requirements in a bubble (possibly from a Statement of Work formed from a customer bubble after management bubbled it up the action list). The needs then got passed along to the design folks who resided in their feng shui bubble, which then floated them over to the Developer double-bubble (the biggest bubble on the block), who then pushed things to the QA bubble where the bubble immediately popped under it’s own perceived weight, spraying requirement soap all over everyone as they plummeted toward the Documentation folks who of course had already taken cover near ground level with Customer Support (mops in hand beneath the rest of the bubbles). This model is often referred to as waterfall, seen by many as an exercise in grade school “pass it on” where the message evolves from one end of the room to the other until participants ultimately end up in detention for saying things they shouldn’t to customers.
Enter Agile. A set of principles that can be applied in a variety of ways to meet a variety of needs.
Value...
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
The common goal: to involve the right people at the right time, asking them to communicate in the most effective way possible to deliver working software - to you. The question then becomes how to implement these principles to enhance communication (sharing a single bubble wherever possible).
When people talk about Agile and a method of application (such as Scrum) that would allow for more effective communication, there are some common themes, such as trust, transparency, accountability, commitment, and collaboration. All rather high falutin’ words dagnabit, but all rather critical, because much of where Agile processes look to mitigate risk is with team focus. “Customer teams” are provided with the opportunity to circle the wagons, roll up their sleeves and figure out how to get things done with just a basic set of guidelines. Our customer focus could be summarized as follows:
- We can minimize risk of missing the mark by involving you – our customers - directly and often. User story definition and the associated validations that drive conversation about your business needs.
- We can minimize risk by prioritizing your product development efforts working with you, analyzing needs and where they fit in a development plan, and communicating that to you.
- We can minimize risk by developing software in shorter periods (called “sprints” or “iterations” for those who enjoy tech jargon). This enables us to respond more quickly as your needs change.
- We can minimize risk by focusing as a team. Project team focus with you as a member helps us enhance efficiencies by bringing us together throughout the project - avoiding the hand-off from group to group and minimizing the impact of *Surprise #217).
- We can minimize risk through frequent product demos – enabling faster feedback for course correction, and again increasing our chances to respond to changes quickly.
* Surprise #217 – to be followed by Surprise #218 just as Jim said it would when he met with his bubble mates after the catastrophic Surprise #216 of 2006, now known forever as “The Great Surprise.”
There are other recommended <Scrum> practices that deal with enhancing our internal processes (areas like estimating, task size, team size, etc.), but the Agile highlights identified above speak more to you and your role as a customer helping us close the feedback loop. Communication is rarely easy when it involves many people across companies - and even if it sounds good, finding the time for the partnership can be hard. It has to be prioritized. You need to see the value as it relates to your own success, helping to insure you get what you truly want from AMS and the software products you plan to use. Allocating time and resources helping to identify business requirements, develop user stories, review test validations, provide test data, get involved in product demos, etc. makes sense if we are going to get things right the first time.
Soma Somasegar, senior vice president in charge of development tools for a tiny company called Microsoft, is quoted as saying about their Agile approach, "I don't know that there was an 'Aha!' moment… We just realized that we're building products for customers, not just for technology's sake. So the sooner we could engage with our customers, the better we could make it." A statement demonstrating that Agile principles and the associated customer involvement expectations have entered the mainstream.
Probably much of what this speaks to seems like common sense. If you are going to build something with other people, you should probably involve them in ways that move relevant information to where it needs to be quickly. Really all aspects of implementing Agile values point to this end. Customers who are given the opportunity to be involved in the development process and make the choice to do so, improve their odds of satisfaction. By partnering with us at AMS to identify relevant business needs, we can more effectively prioritize our focus. This will increase your ability to manage your business, adding value for your customers, reducing costs and enhancing your competitive advantage.
Together, we need to focus on involving the right people, at the right time, communicating about the right needs – your needs. Please join us in looking for opportunities to encourage the conversation – to build better software faster.
Thanks for reading…
About the Author: Mike Levine is Quality Assurance Manager at AMS Services, working in their Portland, Maine office. Mike has worked at AMS for over 9 years, in areas such as Line of Business Development, Product Support, and Quality Assurance. Mike has been a strong advocate for using the Scrum process at AMS.
Contact Bonnie Johnson today and discover how agility in communication can improve your software experience.