From Guest Editor Dave Rooney:
As a consultant and Agile coach, I’ve had the opportunity to work with many different clients and speak to many people about Agile methods. From my earliest Agile experiences in 2000 to the present day, I’ve encountered a common statement made by those who haven’t been part of teams working in an agile manner, and even from some who have. The phrasing always contains the words, “in the real world.”
For example, “Agile is great in theory, but I can’t see it working in the real world.”
Or how about, “Test-driven development sounds great, but in the real world it’s impractical.”
Then there’s, “Having each team member dedicated 100% to the team would be wonderful, but in the real world we have to live with partial allocations of time.”
The Real World. What does that really mean? In the cases where I’ve heard the term, I think that you could substitute the phrase “in my experience,” or “in this organization in its current state.” As a coach it can be frustrating to hear someone want to stop the conversation, but it’s also an indication that the person or group has other issues that are causing them to lose sleep.
When I first connected with others in the Agile space over a decade ago, there was another common thread among most of us. Almost all of us saw the practices of Scrum and Extreme Programming and recognized them from previous experience as “things that worked well.” In 1992, I personally worked on a team that was co-located with its customer, worked in small increments and solicited feedback on the work early and often. I would consider that group successful; meeting customer needs in a timely manner even when they changed. The group was able to consistently do this over the long term, which certainly fits a loose definition of Agile.
Since Agile didn’t exist then, and we didn’t call our process anything or have certifications, how could it have possibly been successful? Joking aside, this is the crux of the matter: teams and organizations are successfully delivering software systems and products in this so-called Real World. They’re too busy being effective to worry about what their process is called.
Do you have experiences similar to this? If so, please consider contributing your story or stories to this edition of the Cutter IT Journal. Let’s compare and contrast what we have seen, with an end goal of providing a dogma-free, buzzword-free view of what represents software delivery agility in The Real World.
Suggested topics may include, but are not limited to the following:
- Which “mainstream” Agile practices worked well, and/or which ones did not?
- Did you have an effective experience working with COTS products, where a project is more configuration than development?
- What groups or organizations delivered a constant stream of business value, but didn’t use any special names for it?
- What is your experience responding to market opportunities and changes quickly without incurring technical debt?
- Do you know of any groups or organizations that were “Agile” before it had a name?
- What practices were effective in domains not often represented in the Agile community, such as: avionics; plant control systems; life-critical software; embedded device software; pharmaceutical industry software; medical software; business intelligence systems; data analytics (Big Data); effective practices in the open source world?
SEND US YOUR ARTICLE IDEA by 27 August 2014.
Please send your article proposal to the Guest Editor Dave Rooney at drooney[at]cutter[dot]com, with a copy to Christine Generali at cgenerali[at]cutter[dot]com no later than 27 August and include an extended abstract, a short article outline showing major discussion points, and a brief bio of the author.
Accepted articles are due by 26 September 2014.