Tag: Agile

It Ain’t Easy Being Agile

Written by Keith Ellis on September 8, 2009. Posted in Articles.

You have to admit – agile folks are conflicted. On one hand there’s the folks screaming requirements are dead***. On the other hand, people teaching agile practices have to explain the asterisks; mention these things called user stories and the practices of getting good user stories (like making each user story testable and how to deal with non-functional requirements). Then there are the folks rolling out these practices and using them in real life on complex engagements. We’re facing the issues of sequencing and redundancy of stories, figuring out which ones accidentally change the architecture of the system (oops!), which ones were really a whole book rather than just a story, etc. and how to actually get to the promised land of higher productivity. No wonder you get questions from developers like, “can I write down this non-functional requirement?” Agile is still a storm of mixed messages – and like the Internet bubble of the late 90s hype might do more harm than good to the movement over time.

Let’s get away from the hype and look at the facts of performance – meaning development efficiency, timeliness and stakeholder satisfaction. I recently looked at all of these variables in a large scale research study – The Business Analysis Benchmark. What I found is that Agile, Waterfall, Iterative, Prototyping/visualization-centric approaches all performed identically. Statistically there is absolutely no difference between any of them. What creates the performance difference is the level of requirements discovery and management maturity behind the primary SDLC selected. Any hype that says agile practices are universally better is simply wrong and detrimental over time. It will lead to very large scale and eventually public failures – and a counter-movement away from these practices. This would be a real shame. Agile is great stuff when used correctly.

Methods and practices of business analysis have to follow the mantra of “the right practices at the right time.” You can’t use OLTP analysis practices/techniques and expect to produce effective requirements on a data warehouse. It’s silly! Similarly, you want to target agile practices to the right projects where agile makes the most sense and have enough corporate requirements discovery and management maturity to know the difference. Anything else is like trying to blast a square peg through a round hole. If the stakeholders don’t want to participate in scrum meetings every day… get onto another track! If you’re dealing with something data driven or with very high numbers of transactions in a regulated system – run away… don’t walk. Yes, you could do it… why would you? I could run around on the freeway too, but I’m suggesting there are better ways to use some roads. In the long run, using the right techniques at the right time will pull far more momentum to the movement than creating hype and watching the carnage.

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

Authoring Requirements in an Agile World

Written by Tony Higgins on March 31, 2009. Posted in Articles.

Equipping and Empowering the Modern BA

The principles of agile development were proven before agile – as a defined approach – became vogue. Agile principles were being practiced to varying degrees in most organizations as a natural reaction to the issues surrounding a rigid waterfall approach.

Every individual task on a software project carries some degree of risk. There are many sources of these risks – some third party component may not function as advertised, some module your work is dependent on may not be available on time, inputs to the task were ambiguous and you made an incorrect assumption when ‘filling in the blanks’, the list is endless. All these risks in the individual tasks contribute to the overall project risk and, quite simply, risk isn’t retired until the task is done. Putting it another way, the risk associated with building something is really only retired when the thing is built. That’s the principle behind iterative and incremental development.

So instead of leaving the first unveiling of a new or enhanced application until toward the end of the project, break it down so that pieces (functional pieces) can be built incrementally. While this doesn’t always mean the portions are complete and shippable, stakeholders can see them working and try them out. This offers several advantages: it retires risk, as mentioned before. It often also exposes other hidden risks. These risks will surface at some point, and the earlier the better. Exposing hidden risk and retiring risk early makes the estimating process more accurate. This increases the probability of delivering applications of value that address the business needs in terms of capability as well as budget and schedule needs.

While agile is becoming main stream on small and mid-sized projects, challenges do exist elsewhere such as how to manage this approach on larger projects and in distributed development. Another challenge for many is how to apply a requirements lifecycle to agile projects. Many agile principles such as “just enough and no more”, to “begin development before all requirements are complete”, to “test first”, can be counter-intuitive. Also, what about non-functional requirements? What about testing independence? How can we cost something if we don’t know what the requirements are?

This article attempts to describe some ways to handle these challenges. It is based on an example of real, ongoing, and very successful product development that uses agile with a globally distributed team. It describes one set of techniques that is known to work.

Process Overview

There are many “flavors” of agile, but at a high level they all essentially adhere to the following basic principles:

PRINCIPLE	DESCRIPTION
Iterative	Both Requirements and Software are developed in small iterations
Evolutionary	Incremental evolution of requirements and software Just Enough “requirements details”
Time-Boxed	Fixed duration for requirements and software build Iterations
Customer Driven	We actively engage our customers in feature prioritization We embrace change to requirements/software as we build them
Adaptive Planning	We expect planning to be wrong

Requirements details as well as macro level scope are expected to change as we progress through our release.

For the purposes of this article, our example uses a Scrum-based Agile process1. In this approach the iterations (sprints) are two weeks in duration. A sprint is a complete development cycle where the goal is to have built some demonstrable portion of the end application. It should be noted that while the initial sprints do involve building a portion of the application, often this is infrastructure-level software that’s needed to support features to be developed in later sprints. This means there may not be much for stakeholders to “see”.

Each organization needs to determine the sprint duration that’s optimal for them. It needs to be long enough to actually build something, but not long enough for people to become defocused and go off track (thereby wasting time and effort). We found two weeks to be optimal for our environment.

Key during the first part of the process is to determine and agree on project scope, also known as the “release backlog”. Determining the release backlog itself could be a series of sprints where the product owner and other stakeholders iterate through determining relative priority or value of features along with high level costing of these features to arrive at a release backlog.

At the other end of the project, development of new code doesn’t extend to the last day of the last sprint. We typically reserve the last few sprints, depending on the magnitude of the release, for stabilization. In other words, in the last few sprints only bug fixing is done, and no net new features are developed. This tends to go against the agile purists approach to software development as each sprint should, in theory, develop production ready code. However, to truly achieve that requires significant testing and build automation that most organizations don’t have in place. This is always a good goal to strive towards, but don’t expect to achieve this right away.

Requirements Definition in this Process

There are several ways you could perform requirements definition in an agile process, but again our goal is to introduce an example that’s been tried and is known to work. This example begins with the assumption that you already have a good sense of the “business need”, either inherently in the case of a small and cohesive group, or by having modeled the business processes and communicating in a way that all understand. So we begin at the level of defining requirements for the application.

Requirements at the Beginning

Begin with a high-level list of features. Each feature is prioritized by Product Management or Business Analysts (depending on your organization). These features are typically then decomposed to further elaborate and provide detail and are organized by folder groupings and by type. If needed to better communicate you should create low-fidelity mockups or sketches of user interfaces (or portions) and even high-level Use Cases or abstract scenarios to express user goals. We sometimes do these and sometimes not, depending on the nature of what’s being expressed plus considering the audience we’re communicating with. For example, if we’re communicating a fairly simple concept (how to select a flight) and our audience is familiar with the problem space (they’ve built flight reservation applications before) then clear textual statements may be “just enough” to meet our goals at this stage. These goals are to establish rough estimates (variance of 50-100%) and based on these and the priorities, to agree on the initial scope of the release (what features are in and which are out).

Once reviewed, this list of features becomes the release backlog. The features are then assigned to the first several sprints based on priority and development considerations.

Click image for larger view
Example High Level Features with Properties

Requirements During the Sprint

With respect to the requirements, the principle of “just enough” is paramount. If the need has been expressed to a degree adequate enough to communicate and have it built as intended, then you’re done. Going further provides no additional value. This means you’ll have a varying level of detail for the requirements across the breadth of the product. For some parts of the product a high-medium level of detail may be “just enough”, while for other more complex areas a very fine level of detail may be needed.

In each sprint there are tasks of every discipline taking place. Requirements, design, coding, integration, and testing tasks are all being performed concurrently for different aspects of the system. The requirements being defined in one sprint will drive design and coding in a subsequent sprint. The net effect is that all these disciplines are active in every sprint of the lifecycle, but the relative emphasis changes depending on what stage you’re at in the project. For example, requirements tasks are being performed in all sprints, but they are emphasized more in the earlier sprints.

In each sprint, the high level features are elaborated into greater levels of detail. This more detailed expression of the requirements usually begins with usage scenarios/stories and/or visuals and it’s expressed in the form of a model. The models can emphasize user interface, use cases, scenarios, business rules, and combinations of these, depending upon the nature of what is being expressed. Sometimes these are created collaboratively but more often in our experience, one person creates an initial version and then holds a review with others for feedback. In our case it is typically the product managers and/or business analysts who create these models and usually between one to three reviews are held with the developers, testers and other stake holders. The review serves multiple purposes including:

To facilitate knowledge transfer to all stakeholders including architects, UE designers, developers, testers, and executive sponsors on what is needed
To allow the architects, UE Designers and developers to assess feasibility
To determine if there is sufficient detail in the requirements to allow development to proceed

With appropriate technology, tests are automatically generated from the requirements producing tests that are 100% consistent with the requirements and enable the immediate testing of code developed during sprints.

Continuous and Adaptive Planning

With this approach planning is continuous and adaptive throughout the lifecycle allowing resources to be redirected depending on new discoveries that come to light during each sprint. This ability to course correct in mid-flight is what gives projects their “agility”. At the end of each sprint we take stock of what was achieved during the sprint and record progress actuals. The work of the next sprint is adjusted as necessary based on this but also based on testing results, feedback from reviews of that sprint’s build, any new risks or issues that surfaced or others that were retired, and also any external changes in business conditions. Estimates and priorities are adjusted accordingly and any changes to release scope and sprint plans are made. In general we try not to make major mid-flight corrections during a sprint, which is one of the reasons why we like two week sprints. If sprints were, say, four weeks then we would lose agility. Also a two week sprint is easier and more accurate to estimate than a four week one.

Click image for larger view
Example Story with Tasks, and Estimates

With respect to the requirements, for those features assigned to the sprint along with any high-level requirements models, development creates high-level goals for the particular feature and estimates them. The goals express what aspects of the feature they will attempt to build during that sprint, recognizing that one sprint is often not enough time to implement an entire feature. The feature and its high-level goals become the content of the “story”. Once the story is defined the developer then details and estimates the tasks to be done for that story over the next two weeks (sprint) and proceeds with development, tracking daily progress against these tasks in an agile project management tool, and covering issues in the daily scrum.

What about the Non-functional Requirements?

The various agile approaches have evolved several techniques to express system functionality. These are things like user stories, use cases, or usage scenarios, that represent “observable system behaviors and artifacts that deliver value to users” like screens, reports, rules, etc. These functional requirements express “what” the system is to do. Examples of this could be things like “generate a stock-level report”, “make a car reservation”, “register for a webinar”, or “withdraw cash”.

Associated with the functionality of a system are its “qualities”. These express “how well” the system is supposed to do what it does – how fast, how reliably, how usable, and so on. Sometimes these non-functional requirements are associated with certain functional requirements and other times they apply to whole portions of the system or the entire system. So how do these very important requirements get accounted for in our agile process?

They are expressed at the high-level in the form of textual statements. For example: “Any booking transaction shall be able to be completed by a user (as defined in section a) in less than three minutes, 95% of the time”.

As functional requirements are decomposed and derived any associated non-functional requirements should similarly be decomposed, derived, and associated to lower levels. For example the above performance requirement is associated with all the “booking transaction” functional requirements (book a car, book a flight, book a hotel). If the functional requirements are decomposed into the lower level requirements “select a car”, “choose rental options”, and “check-out”, then the non-functional requirement may similarly be decomposed into requirements for selecting a car in less than 30 seconds, choosing options in less than one minute, and checking out in less than 1.5 minutes.

During review sessions the functional requirements take center stage. However, during these reviews any non-functional requirements that are relevant need to be presented and reviewed as well. Traceability is usually relied on to identify them. Any non-functional requirements relevant to the functional requirements of the story need to be expressed as part of the story, so the developer can take these into account during development.

QA needs to create tests to validate all requirements, including the non-functional requirements. Sometimes before a feature has been completely implemented, non-functional requirements can be partially tested or tested for trending, but usually cannot be completely tested until the feature is completely implemented (which can take several sprints).

What about Testing?

The high degree of concurrency in agile processes means that testing is performed in every sprint of the lifecycle. This can be a considerable change from traditional approaches and offers several benefits. First, it tends to foster a much more collaborative environment as the testers are involved early. It also, of course, means that items which wouldn’t have been caught until later in the lifecycle are caught early when they can be fixed much more cheaply.

In agile, Product Owners play a very big role in the testing process and they do so throughout the development lifecycle. Whereas many traditional approaches often rely on requirements specifications as “proxies” of the product owners, agile places much more reliance directly on the product owner effectively bypassing many issues that can arise from imperfect specifications. In addition to the product owners, developers also test. Test-driven development is a prominent technique used by developers in agile approaches where tests are written up-front and serve to guide the application coding as well as performing automated testing, which helps with code stability. To augment test driven development, which is primarily focused at the code level testing done by developers, new technologies that can auto-generate functional tests from functional requirements enable a QA team to conduct functional testing based on test cases that are not “out of sync” with the requirements specification. This enables the QA team to conduct testing on a continuous basis, since executable code and test cases are available throughout the lifecycle. In our example, all three are employed – product owner, development staff, and independent QA – on a continuous basis.

The requirements that we develop in our example are a decomposition of high-level text statements augmented by more detailed requirements models that give a rich expression of what is to be built. Requirements reviews are based on simulations of these models and they are incredibly valuable for a number of reasons. First, just as agile provides huge benefit by producing working software each sprint that stakeholders can see and interact with, simulation lets stakeholders see and interact with ‘virtual’ working software even more frequently. Second, people often create prototypes today trying to do much the same thing. The difference with prototypes, however, is that simulation engines built for requirements definition are based on use cases or scenarios and, therefore, guide the stakeholders in how one will actually use the future application, providing structure and purpose to the requirements review sessions. Prototypes, including simple interactive user interface mock-ups, on the other hand, are simply partial systems that ‘exist’ and provide no guidance as to how they are intended to be used. Stakeholders have to try to discover this on their own and never know if they’re correct or if something has been missed. It is important to note that the principle of “just enough” still applies when producing these models. We rely on the requirements review sessions held with designers/developers to determine when it is “enough.” This approach produces very high quality requirements and it is from these requirements that the tests are automatically generated. In fact, such thorough testing at such a rapid pace without automatic test generation is likely not possible.

Although we strive to have shipable code at the end of each sprint, this goal is not always achieved, and we may need to use the last sprint or two to stabilize the code. Since testing has already been taking place continuously before these final sprints, the application is already of considerably high quality when entering the stabilization phase, meaning risk is manageable and rarely is ship date missed.

What about Estimating?

Remember in agile it is typically ‘time’ that is fixed in the triad of time, features, and quality. In our approach also remember that, with continuous testing and the reserving of the final sprints for stabilization, quality tends to be fairly well known as well. This leaves the features as variable so what we’re actually estimating is the feature set that will be shipped.

As always, the accuracy of estimates is a function of several factors but I’m going to focus on just three

The quality of the information you have to base estimates on,
The inherent risk in what you’re estimating, and
The availability of representative historical examples that you can draw from.

In our approach, estimates are made throughout the development cycle, beginning in the initial scoping sprints. As mentioned earlier, once the list of candidate features is known and expressed at a high (scoping) level, they are estimated. Naturally at this point the estimates are going to be at their most “inaccurate” for the project lifecycle, since the requirements have not been decomposed to a detailed level (quality of information). This mean there is significant risk remaining in the work to be done. Similar projects done in the past may help mitigate some of this risk and help increase the accuracy of the estimates (e.g. we’ve done ten projects just like this and they were fairly consistent in their results).

The initial estimates are key inputs to the scoping and sprint-planning processes. As the project proceeds, with each sprint risks are exposed and dealt with, requirements are decomposed to finer levels of detail, and estimates naturally become more accurate. As you might guess, estimation is done toward the end of each sprint and is used in the planning of future sprints.

What about Distributed Teams?

Today distributed development is the norm. For reasons of efficiency, cost reduction, skills augmentation, or capacity relief, distributed development and outsourcing is a fact of life. There’s no free lunch however – there are costs associated with this approach, and much of these costs are borne in the requirements lifecycle. Chief among these is “communication”. There are practices and technologies that can mitigate this issue, so that the promised benefits of distributed development can be realized. The approach in this we’ve looked at here, for example, uses the following and has been very successful:

Concerted effort for more frequent communication (daily scrums, and other scheduled daily calls)
Liberal use of requirements simulation via web-meeting technology
Direct access to shared requirements models via a central server
Automated generation of tests and reviewing these in concert with the requirements to prove another perspective of what the product needs to provide.

Conclusion

“Have you heard that England is changing their traffic system to drive on the right-hand side of the road? But to ease the transition they’ve decided to phase it in – they’ll start with trucks”.

A common mistake of development organizations making the shift from waterfall to agile is that their organization mandates they still produce their big, heavy set of documents and have them reviewed at the same milestones, clinging to these familiar assets like security blankets. It doesn’t work. As scary as it might seem all significant aspects of the approach, like documentation, need to change in unison if it’s to be successful, and requirements are one of those significant aspects.

However if you still want that security blanket and you want to have some benefit of agile, at least generate your requirements specification in an agile manner (iterative, evolutionary, time boxed, customer driven, adaptive planning) that includes simulations integrated and driven by use cases traced to feature. This is one way to reap some agile benefits without making the leap all at once.

Risk is the ‘enemy’ on software projects. High risk profiles on projects drive uncertainty, render estimates inaccurate, and can upset the best of plans. One of the great things about agile is that its highly iterative nature continually ‘turns over the rocks’ to expose risk early and often so it can be dealt with.

On the other hand, one of the great challenges for larger and distributed teams is keeping everyone aligned as course-corrections happen sprint by sprint. A big part of this is the time and effort it takes to produce and update assets and the delays caused by imperfect and strained communication. The good news is that tools and technologies now exist to produce many of the assets automatically, and to also dramatically improve communication effectiveness, allowing agile to scale.

With the right approach, techniques and technology, distributed agile can be done. We’ve done it. So can you.

Tony Higgins is Vice-President of Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst. Tony can be reached at [email protected].

References

1 The Scrum Alliance http://www.scrumalliance.org/

2 Approaches to Defining Requirements within Agile Teams
Martin Crisp, Retrieved 21 Feb 2009 from Search Software Quality, http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310960,00.html

3 Beyond Functional Requirements on Agile Projects
Scott Ambler, Retrieved 22 Feb 2009 from Dr.Dobb’s Portal, www.ddj.com/architect/196603549

4 Agile Requirements Modeling
Scott Ambler, Retrieved 22 Feb 2009 from Agile Modeling, http://www.agilemodeling.com/essays/agileRequirements.htm

5 10 Key Principles of Agile Software Development
Retrieved 22 Feb 2009 from All About Agile, http://www.agile-software-development.com/2007/02/10-things-you-need-to-know-about-agile.html

6 Agile Requirements Methods
Dean Leffingwell, July 2002, The Rational Edge

7 Requirements Honesty
Francisco A.C. Pinheiro, Universidade de Brasilia

8 Requirements Documents that Win the Race
Kirstin Kohler & Barbara Paech, Fraunhofer IESE, Germany

9 Engineering of Unstable Requirements using Agile Methods
James E. Tomayko, Carnegie Mellon University

10 Complementing XP with Requirements Negotiation
Paul Grunbacher & Christian Hofer, Johannes Kepler University, Austria

11 Just in Time Requirements Analysis – The Engine that Drives the Planning Game
Michael Lee, Kuvera Enterprise Solutions Inc., Boulder, CO. 03/09

B.A.gile!

Written by Marcos Ferrer on February 17, 2009. Posted in Articles. 1 Comment on B.A.gile!

This is NOT another Agile Methodology posting. I make no claims to any special agile expertise, nor am I interested in methodology wars. I just want to say that fads are fads, and never substitute for analysis. I completely understand the attraction to agile. It is an excellent summary of what can work for some teams, on some projects.

It is my observation that all the named methodologies I have run into can map onto BABOK concepts, and the BABOK is a superset of them.

Here is the manifesto itself for context (derived from the Agile organization’s own web site at www.agilemanifesto.org ):

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation
4. 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.

———————————————————————————

And here is one analysis, based on general knowledge, personal experience and BABOK concepts:

BA Fundamentals (and hence the essential skills to perform Requirements Communication) have to be present before tools matter. Tools can only support competent, effective behavior, not create it. In a sense, all successful projects are “agile” – it is my observation that all successful projects are full of brilliant individuals who interact fast and freely. This single factor seems to compensate for everything else – counterexamples are welcome, I don’t have any.
Software over documentation is already the most common approach in software development, so it is hard to understand why it matters to “Agile”. Since 65% “failure” rates are already being achieved in software development, it must be items 1, 3 and 4 that really matter, if Agile is effective at all.
Substitute “Iteration of Requirements with Stakeholders” for “Customer Collaboration”, and substitute “waterfall requirements” for “contract”. Contracts, at their worst, are an attempt to “lock in requirements” before they are understood, leading to excess change order profits for the contractor (when changes are allowed), or failed stakeholder acceptance (when they are not). Waterfall requirements are best saved for “one shot” efforts like the moon program.
Over planning, and reluctance to adjust plans as requirements are “learned”, is clearly a cause of certain project failures – it is mostly a failure of intelligence (see item 1). What is missing from this concept is the idea of Enterprise Analysis (especially risk analysis, stakeholder analysis, and cost benefit analysis) and the Requirements Planning that must follow from these. Another way to put this is – IF the project is simple and low risk enough, Agile may be a fit (see BOK tables 3.0 and 4.0 in the Enterprise Analysis section, and see if you can spot which projects might use Agile.

SO, from analysis to opinion (if you have your own opinion, send it in, we will tally responses and report on same):

IN MY OPINION: Agile process fits certain kinds of projects, but hardly most. Here is my list – what is yours?

“Small potatoes” – low risk, decent to high payback systems that only have to satisfy a small number of users with homogeneous interests, have low visibility, or represent proven, successful increments to already successful systems (yes, maintenance and enhancement).

“Feasibility” or “Proof of Concept” trials, which could clear the way for more investment in a larger project?

“Research” projects, where almost all is unknown, budgets are huge, and the paybacks considered indispensable, if they can be achieved at all. These are really rare; one example was the “skunkworks” team that developed the unique (and ultimately unsustainable) Blackbird spy plane.

“Invention” projects for systems that can succeed “virally” and evolve, that represent completely new behaviors ,or huge boosters to behaviors, that people crave, regardless of how poorly delivered (e.g., cell phone service, social networking, 45rpm records).

WHAT AGILE PROBABLY DOESN”T DO is Enterprise level projects, projects that must organize the efforts of many people. I am sorry to say that I hold this opinion in spite of the fact that I helped lead just such a success – an Investigation Management system for over 1400 government users. We succeeded by using all four principles in the Agile Manifesto, AND this only worked because we were an A-1, Agile Item 1 team.

My advice – get the smartest team you can that actually CARES about their work, and put them under tremendous pressure – they will cut to the bone, and will NOT skip any critical steps, and you can call it Agile if you want, but I call it B.A.gile!

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!

Why Agile?

Written by Cynthia Low on February 3, 2009. Posted in Articles.

What’s so Great about Agility?

The Agile approach to managing software projects has been getting a lot of play recently. Why are people talking about it so much? Is this just the latest “new thing”? Or is there some real value to it?

“Agile,” as a set of software development methods, was defined seven years ago, so the “flash in the pan” would have burned itself out long ago. The fact is that more and more organizations (from small shops to large corporations) are finding real value in Agility.

After defining what Agility is and is not, we will look at the value it can bring.

What is Agility?

The Agile approach has a number or key attributes that can be referred to as the “Essence of Agility.” They are:

Learning and adaptation – Traditional approaches expect that we can foresee how the project will unfold with reasonable precision. The Agile approach accepts that there are many things we cannot anticipate, so it is structured to allow us to first learn about those unknowns and then adapt to what we learn.
Collaboration – The Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customers.
Customer focus – The customer is the central focus of an Agile project and is actively involved throughout.
Small self-directed teams – Agility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.
Lean principles – The principles that have been proven by Lean Manufacturing are embodied in Agility, especially concepts like “Just Enough” and “Just in Time.”
Progressive requirements elaboration – We expect to learn about the system requirements as the project progresses, so trying to nail them down in a full-blown specification at the beginning of the project doesn’t make sense. Agile projects establish a roadmap and elaborate the details as they are needed.
Incremental delivery – The best way to ensure we are building the right system is to regularly get feedback from our customer. Agility always includes incremental delivery of the product to the customer – at least for acceptance testing.
Iterative planning and adaptation – Agile projects place a high value on planning. They engage in planning at various levels of detail and engage in it regularly. Again, this is driven by the fact that we cannot foresee everything that is important, so we must adapt our plans as we learn.

What is Agility Not?

Many people have abused the term “Agility” by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:

No documentation – The documentation that an Agile project produces is significantly different from what traditional projects produce, and an Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.
No planning – Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day’s work.
No requirements – The Agile team’s Product Owner (customer) defines a Product Vision, and they work together to document the product’s high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.
No schedule or budget control – Agile projects always operate within a “Time-Box.” That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people’s time is the largest part of a software project’s budget, the time-box limits the project budget as well. The Agile mantra is, “We will deliver the greatest possible customer value within the project constraints!”
Programmers doing whatever they like – The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team’s only role is to estimate what can be done in limited timeframes. The team’s customer determines how that effort will be directed.

The Value of Agility

There are many reasons why companies find the Agile approach (when it is implemented as intended) to provide value. The value that is cited usually includes:

The right product – The customer is continuously involved in the project, ensuring that valuable software is being built and prioritizing the work. In addition, the customer accepts or provides critical feedback on each increment of the product that is produced. With this level of involvement by the customer, there is no way that the wrong product can be built.
Quality – Agility always includes a strong focus on the quality of what is built. This includes not only the customer’s acceptance testing, but also many technical quality practices. Properly functioning Agile teams produce high-quality software.
Schedule and budget – Time-boxing of an Agile project means that its schedule and budget are rarely “over-run” If things don’t work out as planned, the low-priority features can be skipped or cut short. If an Agile project does need to extend its time-box it would be with their customer’s and management’s full concurrence.
Early warning – Because an Agile project is essentially a series of short mini-projects, problems become apparent very early, when they can be corrected.
Adapting to change – Change is a fact of business. An Agile project can adapt to changes in the business environment, within the organization, or with the customer much more effectively than a traditional project.

Every business values agility (lower-case “a”). What many are finding is that Agility (upper-case “A”) provides what it promises.

Alan Koch, PMP, is president of Ask Process. Inc., (http://www.askprocess.com/) and an instructor with Global Knowledge Training LLC. A longtime member of the business analysis community, Mr. Koch has 28 years experience in software development. He can be reached at http://ca.mc883.mail.yahoo.com/mc/[email protected].

Defining Requirements within a Short Time Frame

Written by Cynthia Low on October 15, 2008. Posted in Articles. 3 Comments on Defining Requirements within a Short Time Frame

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework. As a result, over 60 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality. Without a clear idea of how to set requirements, most software development projects will face either significant rework or fail altogether. Over the past few years, Agile methodologies appear to be helping reduce this problem. This whitepaper will explore techniques of capturing requirements within Agile teams.

Wikipedia says that, “The term Agile Software Development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project.”

So, if we apply a sports analogy, using Agile methods to develop software is like a series of sprint races. Developers are focused solely on successfully completing the next iteration, which is often due within a matter of weeks, and they zero in on defining their requirements to achieve that short-term goal.

In other words, Agile teams don’t produce any requirements specifications that are not absolutely critical to making it clear to the team what is expected of them in the short term. So, the question becomes: How do you decide what requirements are “just enough” to complete the next iteration?

There are a number of factors that need to be considered, when deciding what techniques and how much level of detail to provide when defining requirements for an Agile team. These considerations should include:

Team size and the proximity of team members
Skill and experience of the team
Has the team worked together before?
Complexity of the requirements
Complexity of the software.

Keeping the above considerations in mind, you will need to decide which techniques you will want to use and how much detail you will want to provide while using these techniques.

Common techniques include:

Verbal Communications. Verbal communications, perhaps using a whiteboard to capture key thoughts, is typically the fastest way to define a requirement. However, what this approach makes up for in initial speed, it doesn’t ensure that all stakeholders are in the loop. Plus, participants may not all remember exactly what was decided after the meeting breaks up. It is all too easy to have a different recollection of details that were discussed two weeks ago. This can lead to misunderstanding of requirements during development and testing, and will be reflected in inaccurate product user guides and training material. So you may have saved time initially, but wasted more time in the long run.

So when is verbal better than written communication? Agile methods promote face-to-face interactions, but that can be impractical in cases where teams are scattered across the globe or even across a city. Relying only on verbal communications is a last resort, to be used only when short-term time gains are worth more than the longer term problems this approach can create.

Story Cards. A popular and valuable technique within Agile development teams is to create a story card. These story cards tend to provide a text-based description of who wants to do what and why, along with perhaps a picture of the screen and some test scenarios. This technique works well for very small features but may not scale well for larger or more complex features that integrate and depend on other features.

Requirements Lists. Often a common place to start from a product scoping point of view is to create a hierarchical “Requirements List” which captures in text form an organized and grouped list of functional requirements, technical requirements, business drivers etc. Often these text descriptions can be enough to clearly articulate what the requirement is For example a technical requirement such as, “The application must support IE 6 and IE 7,” does not really need any additional explanation. However a requirement such as “The application must be able to define which users can have access to specific functionality and data” will need much more detail. The point is to only expand on requirements that truly need more details.

Use-Case Flows. Sometimes to truly understand the overall flow of a more complex requirement use-case flows or simulations are required to capture “just enough” requirements. However from my point of view it typically is not a good idea to use “use cases” to document complex logic or business rules such as authorization logic. These types of requirements are often better documented in text or tabular formats. For example, a simple 2×2 table showing the roles on one axis and what they can do on the other axis is a much more efficient way to convey authorization business rules than embedding alternate flows into use cases.

Simulations. Simulations can add great value to really bring a concept to life, but adding every single detail into the simulation can take too much time. And, frankly, it is sometimes difficult for developers to reverse-engineer a simulation and extract a discrete set of requirements. It is much easier for an Agile team member to read a simple table showing who can do what, than to run through a simulation and reverse-engineer the same information. Also, it is possible to spend too much time doing elaborate simulations that don’t add enough value for the time and effort they can take to develop.

Everyone will have their personal preference as to when to use what technique for communicating requirements, but the key is for the team to work together and agree upon when it makes sense to use different techniques and not “force” a technique when it clearly can be done more easily another way.

General Repository. No matter what techniques you decide to use to document requirements, keeping these requirements details/artifacts in a central repository and linking them to each other in an organized manner is critical to the collective success of your Agile team. Relying on people to keep track of endless email trails and simple document repositories with manually maintained links is not the answer. People are too busy to do it, and, most likely, the data repositories will not be kept up-to-date. Because of that, any repository needs to do whenever possible to automatically create and maintain these links based on how the artifacts are organized. For example, if a use case refers to a screen on a given step, then that screen should be automatically linked to that step in the repository.

So how do you know what is enough detail? Your team will let you know when things require more details. Part of working within an Agile team is to expect the need for requirements clarification throughout the project. In traditional waterfall, this was almost discouraged and under the good intentions of change management. However, within Agile, it is expected and embraced, which takes some getting used to for Agile newbies.

Recap

This topic is much deeper than can be covered with this small article, but the key points are

Make a conscious decision on the level of detail you want but expect to tweak that during development.
Choose the right technique for the requirement you are trying to describe.
Make sure you keep an integrated central repository that links together the multiple requirements artifacts.

Martin Crisp is CTO of Blueprint Systems. He can be reached at [email protected]