Executive Summary
Much focus has been paid in recent years to the introduction of Agile methodologies into the overall software project space. The bulk of these methodologies focus on quickly generating ‘code’ that can be tested. However that alone does not fully accomplish all the business goals, of a project. This is because not as much consideration has been given within Agile methodologies on traditional ‘Requirements’ stages, or if in fact ‘Requirements’ even belong in the discussion.
This paper sets out to recap the business value of Agile, and then express how the same benefits that Agile provides to the overall lifecycle can and must be introduced and implemented specifically within the Requirements Definition function.
Agile, at the conceptual level
In 2001 the Agile Manifesto was launched, whereby 17 “organisational anarchists” defined four values for better ways of developing software:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The result of many years of Agile methods momentum has produced flavors such as Scrum, Crystal Clear, XP, ASD, FDD, DSDM, etc. Additional entries have included OpenUP / RUP, Lean, EVO, and The Eclipse Way. Collaborative practices are key in them, and many have jumped on the opportunity to be what they think is “faster and cheaper.” In some cases this led to fragilism.
A good definition of Agile at its highest level is: an iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce project deliverables in a cost effective and timely manner which meets the changing needs of its stakeholders.
Core principles of this therefore include:
- “Fits just right” process – Do the simplest thing possible, Self-correcting teams
- Continuous testing and validation
- Consistent team collaboration – De-emphasize ‘meetings’
- Rapid response to change
- Ongoing and useful customer involvement – active customer involvement is imperative! – find a champion, Nothing counts until you deliver software
- Frequent delivery of working product – Weeks rather than months; days rather than weeks
In a traditional lifecycle of a project, risk is delayed. Much activity occurs “up front,” whereby design and construction occur in a vacuum. Architecture and functionality is not “seen” until near the end of the lifecycle. Contrast that with Agile, where candidate architectures are revealed earlier, serving to expose potential problems. The gap between these two approaches can be seen as the amount of risk reduction that can be salvaged.
Finally, there are some concerns to face, regarding Agile. Many of these are misconceptions, however:
- Uncontrolled Change
- Chaos – No process
- Develop with insufficient requirements
- Developers run the show
- Process itself becomes the goal
- Placebo effect
- Key point gets missed
So what should be the fit, with Requirements Definition?
As Agile increases in popularity, there can be a belief that stringent Requirements processes can be seen as overhead. A mistake can occur whereby there is the feeling of a need to ‘rush’ almost directly to development, and Requirements only serve to slow things. This misses, however, the need for business side users to (still) connect with their external development partners/organizations. So regardless of Agile’s speed to market benefits, business subject matter experts still have to play an important role; which dictates that they must have a place at the table along with development providers.
The problem with traditional ‘Requirements’ activity
The underlying problems with traditional Requirements Definition are distilled into three main causes:
- Misunderstood product requirements due to ambiguity of written specifications
- Lack of sufficient information to support complex applications/systems
- Inability to “test drive” a product design with customers and stakeholders before development
One can easily see that the above issues are not Agile, in philosophy.
Additionally there exists a desire by project teams to always minimize ‘change.’ This desire leads to an attempt to define everything up front. Agile methods can improve on this through iterations that stagger ‘commitment.’
After years of experience at OneSpring, we feel we’ve learned a better way.
We call this approach the Stream Process™. The Stream Process™ is a methodology that offers companies a collaborative and highly-visual approach to creating superior products and solutions in less time, with reduced project re-work. This helps companies dramatically improve productivity, quality and customer satisfaction.
Stream’s core process is made up of three areas: Insight, Clarity and Focus. Each of these areas are performed in a Realization Cycle. The output of a Realization Cycle is the Definition. Each time a full Realization Cycle is performed, an iteration of the Definition is achieved.
The output of each Realization Cycle is “delivered” to the stakeholders. Unlike a SDLC (Software Development Lifecycle), however, this output is not delivered to the development team with the intention to code from, but rather delivered to the consumers of the requirements definition (e.g. business, customers, IT).
The purpose is to achieve a common understanding before beginning to code. Once this common knowledge is achieved by the team of stakeholders, the Definition may be used for IT architecture/development. In other words the inputs for development – user stories, use cases, etc. – are now stronger. Visualization has mitigated the risk of missing out on the real business goals.
This scalability and flexibility therefore allows StreamTM to easily be integrated within any organization using Agile based methodologies, or to in fact introduce Agility into an organization who has not yet taken this path.
Some Agile proponents might argue that there is no Requirements Definition ‘stage’ with an Agile approach. We find that stance to be unrealistic at best, and foolish at worst. Defining requirements is where it all begins. Without that, what are you designing/negotiating/working for? An aimless, amorphous goal? How will you know once you get there? How will you know if you don’t?
Others will focus on ceremony, and state that since visualizations do not automatically turn into working ‘code’ they aren’t of value. This is naïve, for a Visualization prototype that all stakeholders agree on and take ownership of does provide a detailed blueprint that can provide immediate value, without need for ‘translation.’
Therefore and in conclusion, we propose the following analogy:
- Agile approaches, regardless of the flavor, apply to the development lifecycle as a whole
- The Stream Process™ introduces the concepts of Agility via a specific set of activities, to the Requirements discipline of the lifecycle
General Sources:
http://agilemanifesto.org/ http://en.wikipedia.org/wiki/Agile_software_development#Agile_methods http://www.ibm.com/developerworks/rational/rationaledge/ http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf
