A View to Agile Requirements

Featured
18052 Views
15 Comments
9 Likes

A View of Agile RequirementsThe patterns, workshop design guidelines, and collaboration techniques I describe in Requirements by Collaboration are agnostic to product or software development method. When I wrote the book, agile methods were beginning to gain in popularity. Fellow agilists tell me they find the book useful when they design and facilitate workshops for their agile teams.

Yet some agilists ask me, "We have to constantly figure out our requirements-what to build, and when. How do I adapt requirements and requirements workshops to fit my agile project?"

They're right about the need to constantly adapt requirements and elicitation practices. In agile projects, you deliver the product in a series of successive and sensibly staged releases.1 Each release represents the culmination of a series of requirements decisions. Working on cross-functional teams, you plan and deliver working software in a series of fixed time frames, with "business value" as your mantra. Your team has a ferocious focus on sculpting portions of the product from a mass of backlog possibilities.2

One of your biggest challenges is ongoing-how to group and sequence requirements for optimal delivery. Let's take a look at adapting requirements workshops to meet that challenge.

The Timing, Rhythms, and Patterns of an Agile Cycle
Agile development and delivery rely on many short cycles with a clear cadence: iterations occur within multiple releases as you deliver the product successively. Each cycle-product, release, and iteration-necessitates its own view of the requirements.

Furthermore, it's wise not to conduct highly detailed planning at the start. Instead, you allow for the possibility that you might not build the entire envisioned product. You also take into account that the sequence, timing, and specifics of delivering requirements can change.

Thus, time drives requirements decisions, and time drives how you structure your agile requirements workshops.

Agile product development takes on a pattern of plan-do-inspect-act:

  • Plan: define the product, release, or iteration.

  • Do: define, build, and test working software.

  • Inspect: review and retrospect your process.

  • Act: adapt team practices, prune and prioritize the product backlog's items, and prepare for the next planning cycle.

You want to learn from each product cycle delivery and, based on what you learn, adjust your plans for the next cycle. These best practices optimize both your product investment and your development process. To this end, you punctuate the cadence with a starting ritual (planning) and ending rituals (reviews and retrospectives).

You do your planning, reviewing, and retrospecting in collaborative workshops. These workshops use group interaction rituals led by a skilled facilitator to deliver agreed-upon outcomes that feed the team's work. (For insight into those rituals and facilitation techniques, see Derby and Larson, Gottesdiener and Tabaka in Additional Reading.)

This article focuses on planning, when you explore and confirm requirements. The two key approaches I recommend my agilist clients are (1) to deliver requirements in collaborative workshops and (2) to organize agile requirements planning according to three product views.

Successful agile teams use requirements workshops to collaborate on the key planning cycles, holding a series of integrated workshops to deliver requirements. You hold collaborative requirements workshops for

  • The entire product (once)

  • Each release (once for each release)

  • Each iteration within a release

Requirements by View
On an agile project, you don't attempt to understand or predict all product requirements up front. But you do need to sketch out the long view of the product to establish a common focus and marshal organizational resources (people, money, space, governance). From that vantage point, you define what to build in each release, and then in each iteration.3

These three levels-product, release, and iteration-correspond to three views (what I call the Big-View, the Pre-View, and the Now-View) of the product requirements, as shown in Table 1.

Table 1 - Views of Agile Requirements

Requirements View

Purpose

Big-View (Product)

Gain an overall understanding of what the product will be, and plan the sequence of delivery. Agree on vision, scope, and time line for the entire product.

Pre-View (Release)

Define what product functionality to deliver in a given release, and obtain agreement on the backlog items to deliver in the first few iterations in the release.

Now-View (Iteration)

Identify enough requirements to deliver in an iteration to enable the team to make a commitment for delivery.

Let's review each view.

The Big-View
The Big-View provides a holistic, evolving product roadmap of all the product requirements you will deliver over time to satisfy the product vision. Because the requirements represented in your product roadmap are high-level, the roadmap shows features: "cohesive bundles of externally visible functionality that should align with business goals and objectives. Each feature is a logically related grouping of functional and nonfunctional requirements described in broad stokes." The roadmap shows features arrayed across time and releases. The features in the roadmap are used to build or extend you product backlog.

The roadmap enables senior managers to plan their sponsorship of the development effort and establish governance and feedback loops for their funding decisions.

The product roadmap is an evolving framework, because you want the flexibility to end the product development journey before the originally envisioned development time frame. You might achieve sufficient value sooner than planned, or you might learn that you haven't gained the expected value and so it's best to cut your losses and kill the project. Because the product's payoff is uncertain, your plan needs the flexibility to change the routes at any time based on user feedback and market conditions. The roadmap has ongoing value as a tool for planning, requirements discovery and communication among product stakeholders as enhancements and extensions are added to the product until its retirement or replacement.

Types of Product Roadmaps
Product roadmaps can take on different perspectives, communicating different things to different audiences. For example, you might have a time-based roadmap that shows the functionality you plan to release at certain key milestones, industry occurrences, or market events. Another version of your roadmap might illustrate key market-worthy features or themes. If you are building commercial software, you will want both an internal and an external roadmap. Your internal roadmap supports funding and reveals the features you will use to compete in the market. Your external roadmap (which contains less detail) is helpful for engaging your customers, promoting market innovation, or shaking up the marketplace.

Pre-View
Whereas the product roadmap (Big-View) provides guideposts for the features to be delivered, the Pre-View reveals details at the next level: the release. Each release should contain cohesive chunks of consumable, marketable, valuable features.

To develop the Pre-View, business and technical stakeholders explore and define possible delivery sequences and dependencies for a release. A good release plan reflects analysis of functional as well as nonfunctional requirements (the quality attributes, design and implementation constraints, and external interfaces that the product must have). This analysis exposes risks and unknowns about the product that need to be investigated, allows you to tune and prune your product backlog, and helps you focus on the backlog items that need the most attention in the next few iterations.

Now-View
The Now-View defines the requirements for a time slice within a release: the next iteration. This provides the iteration's requirements in sufficient detail that your team can make reasonable estimates of the work needed to deliver those requirements to a predefined set of acceptance criteria (conditions of satisfaction, or "doneness").

Together, these three views help you form a coherent, focused, flexible plan for agile development.

A Strategic and Tactical Product Owner (aka Customer)
On agile projects, team members need to make tough decisions about requirements throughout development.

You work with your product owner to answer questions such as, Is this requirement necessary? Is it more important than another? Can we deliver part of a requirement and still get value? Do these requirements go together? How can we group requirements to best serve our end users, or to deliver optimal value and return on investment? Will building one requirement (or set of requirements) before another cause too much rework later?

These are critical questions, and large agile projects need more than one product owner to answer them. It's almost impossible for a single person to handle the Big-View, Pre-View, and Now-View day in and day out. Consider that the "complete" product owner must do all this:

  • Manage the product backlog.

    • Prioritize and prune a large backlog (or set of backlogs).

    • Participate in planning meetings at all levels.

    • Attend the demonstration/review and retrospective.

  • Provide requirements expertise to the team.

    • Answer requirements questions about the current iteration.

    • Attend daily stand-ups.

    • Develop (or assist in developing) user acceptance tests for the current and next iteration (or provide details so that others can develop them).

  • Participate in formulating business strategy.

    • Conduct market and competitive analysis.

    • Assist with marketing the product to the user community.

  • Prepare for deployment.

    • Determine how to market to, train, and communicate with the customer.

    • Determine how the organization or customer will manage change.

One way to handle this overload is to split the responsibilities among two roles, having a strategic product owner and a tactical product owner. The strategic product owner owns the Big-View and the Pre-View, and the tactical product owner owns and maintains the Now-View.
The strategic, or Big-View, product owner. . .

  • Is external facing

  • Handles product marketing and portfolio analysis

  • Is responsible for the product vision, product roadmap, "voice of the (end) customer" (balanced with the "voice of the business")

  • Defines and adjusts the roadmap and release plans in response to market needs

The tactical, or Now-View, product owner . . .

  • Selects and negotiates backlog items to deliver for each iteration

  • Elaborates on requirements for backlog items (just-in-time)

  • Defines dependencies, balances value with risk

  • Defines criteria of acceptance ("doneness") for each item

The Long View
Collaborative requirements workshops are a useful way to plan and manage the changing and changeable requirements of your agile project. By organizing your tasks and conceptualizing around the three views discussed here, you can learn how to manage and improve your agile process and maximize agile's business value for your organization.

References

(i) EBG Consulting, "Agile Requirements: Collaborating to Define and Confirm Needs," Course Guide, Version 09.08, 2009

(ii) Gottesdiener, Ellen. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. GOAL/QPC, 2005.

(iii) Ibid.

Additional Reading

  • Cleland-Huang, Jane, and Mark Dean. Software by Number: Low-Risk, High-Return Development. Prentice Hall, 2003.
  • Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.
  • Cohn, Mike. Agile Estimating and Planning. Addison-Wesley, 2006.
  • Derby, Esther, and Diana Larsen. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006.
  • Gottesdiener, Ellen. Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley, 2005
  • Gottesdiener, Ellen. "Agile Requirements, in Context," Success with Requirements, Vol. 2, No. 1 (2008).
  • Gottesdiener, Ellen. "Requirements Practices on Agile Projects," Success with Requirements, Vol. 1, No. 8 (2007).
  • Hohmann, Luke, Steve Johnson, and Rich Mironov. Living in an Agile World: The Role of Product Management When Development Goes Agile. Kindle Book available on Amazon.com.
  • Smits, Hubert. "Five Levels of Agile Planning: From Enterprise Vision to Team Stand-Up," Rally Software Whitepaper, October 2006, available at rallydev.com.
  • Tabaka, Jean. Collaboration Explained: Facilitation Skills for Software Project Leaders. Addison-Wesley, 2006.
  • Lawley, Brian. Expert Product Management: Advanced Techniques, Tips & Strategies for Product Marketing & Product Management. Happy About, 2007.
  • Comprehensive Agile Resources

Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps you get the right requirements so your projects start smart and deliver the right product at the right time. Ellen's company provides high-value training, facilitation, and consulting services to agile and traditional teams. An agile coach and trainer with a passion about agile requirements, she works with large, complex products and helps teams elicit just enough requirements to achieve iteration and product goals.

Ellen's book Requirements by Collaboration: Workshops for Defining Needs describes how to use multiple models to elicit requirements in collaborative workshops. Her most recent book, The Software Requirements Memory Jogger is the "go-to" industry guide for requirements good practices. In addition to providing training and consulting services and coaching agile teams, Ellen speaks at and advises for industry conferences, writes articles, and serves on the Expert Review Board of the International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge™ (BABOK™).

You can subscribe to EBG Consulting's offers a free monthly eNewsletter "Success with Requirements" offering practical guidance and requirements-related news. When you sign up, you'll receive a free article on essentials for scoping your requirements. You can follow Ellen on Twitter or contact her via email (ellen@ebgconsulting.com).


1 A release is a shippable product version; it is ready to be deployed to the customer. Time frames for a release vary but typically fall every one to four months.

2 The backlog is a catalog of prioritized and sized sets of work to be performed, including requirements as well as work needed to implement the product. Backlog items may vary in their degree of clarity. Some are defined in more detail than others.

3 An iteration, or sprint in Scrum vernacular, is a single development cycle, usually one to four weeks, resulting in a set of working software. Each iteration encapsulates a cycle of requirements exploration, design, coding, and testing.

 
 

 

Like this article:
  9 members liked this article
Featured
18052 Views
15 Comments
9 Likes

COMMENTS

ajmarkos posted on Tuesday, November 10, 2009 1:36 PM
Ellen:

The problem with, first thing, come up with a high-level - but adequate, "roadmap" of requirements: Nobody is smart enough.

If it were not the case, data flow diagrams would still rule the requirements engineering landscape.

Tony Markos
zarfman posted on Tuesday, November 10, 2009 4:38 PM
Ellen:

You wrote - One of your biggest challenges is ongoing-how to group and sequence requirements for optimal delivery.

How do you do this?

And, how to you prove the delivery is or was optimal?

Given an iterative process it would seem difficult to produce and optimal solution.

Regards,

Zarfman
KenAnderson posted on Tuesday, November 10, 2009 6:01 PM
Tony Markos:

I have to disagree with you - it's absurd to say that nobody is smart enough to come up with a high-level roadmap of requirements.

If that were true, how would any product or software application get off the ground? Do you think when Apple developed the iPhone, for example, that they had no idea whatsoever up front what functions they wanted it to have at a high level?

I'm currently managing an Agile project - we are building a system to manage treatment services for a county Juvenile Justice department. At the beginning of the project, we came up with a high-level roadmap - the system needs to be able to handle referrals, intakes, progress reports and exits, and needs to be accessible by both internal and external workers who participate in the treatment process. We are now on our 4th development iteration. And guess what - the high level roadmap hasn't changed at all, even though a lot of the details have and we've learned a lot that we didn't know up front.

The high-level roadmap is about strategy and business value - if you don't know what the strategic goals of a system or product are, then you really don't have much business undertaking a project to build it.

And what do data flow diagrams have to do with anything? They are a technique - granted, one that is not used that often any more, but that is more because OO techniques have supplanted them, not because they have anything to do with the issue at hand, which is about how to handle requirements gathering in an agile fashion.
Anonymous posted on Wednesday, November 11, 2009 4:41 PM
Ken:


What I said is that nobody is smart enough to upfront, first thing, come up with an adequate high-level requirements map.

Note that I stated "first thing". This is key. For larger scale systems - and when we are talking about the need for a high-level roadmap, we are not talking about smallish systems - there is a tremendous difference in being able to first-thing come up with adequate high-level requirements roadmap versus the way projects typically proceed where an adequate high-level big picture is not understood until well, well into the project - and often no adequate high-level roadmap is ever created. The difference is alot of time (money) and the quality of the solution.

If your project first thing created a accurate high-level roadmap for a larger scale system that has not required any changes of significance - even well into development, congradulations. But such is far from typical.

How many people and other systems interface with your system and what does your "road map" consist of?

I mentioned data flow diagrams because they are the the original up-front, high-level "roadmapping" technique. If adequate first-thing, high-level roadmaps were at all common, DFDs would have gotten alot more "press" than they have to date.

By the way, you are wrong about the applicability of data flow diagrams on agile projects, but that is not for discussion here. If you would like to discuss such, start a forum.

Tony



KenAnderson posted on Thursday, November 12, 2009 11:56 AM
Tony,

First, let me say that I didn't mean to imply that data flow diagrams are not applicable to agile projects - I'm sure they can be. What I meant was that data flow diagrams are one modeling technique among many, and I don't they they are necessarily the primary method of specifying a high-level roadmap, and hence not particularly relevant to the question of whether it is feasible to develop a roadmap up front.

I get the sense that you mean something different by a roadmap than what I do (and what I think the author of the article does).

First, I assume that any system or product development project is launched with some strategic goal in mind, or at least should be. The initial high-level roadmap is just a list of features that will potentially be included in the system, that will enable it to achieve the goals. I'm just repeating what the author of the article says in my own words.

As far as my project goes, our high-level roadmap was a Word document written in plain English. It was not that difficult to come up with, since the sponsors of the project had already done a lot of work to come up with the prioritized list of features that they wanted in the system. The document is oriented around business processes and basically enumerates the processes that need to be supported by the system.

The system will have one interface, with a statewide system that is used by all counties in the state, and will be used both internally within the county as well as by external social service agencies in the community that the county partners with. It's a fairly large project by the standards of our organization, but in the grand scheme of things, it's not that big, so it is of course easier to develop a roadmap than it would be for a much bigger project. Although, even on very large projects, there are ways to manage the complexity, such as by using a program structure.

I'm not sure what kind of organization you work in, but any place I've ever worked, you have to have a business case in order to get a project funded, and the business case has to include some articulation of what the project is going to deliver.

I'm really not trying to be argumentative here - I'm just genuinely having difficulty understanding why you think it is so difficult to come up with an initial roadmap. I would agree that some organizations don't do a good job of it, but that doesn't mean that it is particularly difficult to do.

It sounds like you've experienced projects where there was not a good high-level roadmap. On those projects, how did you decide what to work on and who decided that? Perhaps the difficulties you are alluding to are more organizational - many projects fail for political and organizational reasons - books can and have been written on that subject. Often, there are multiple stakeholders on a project who may have competing goals and priorities - this can make it difficult to establish a clear roadmap. But that, again, is very different than saying that people aren't smart enough to come with an initial roadmap.

I could see how on a very large project it would be more difficult. But in that case, if a project has problems because there is not a well-defined big picture, it is a management failure.

Finally, in many cases, the initial roadmap will change over time. But that doesn't mean the the initial roadmap was "wrong" or that the people who developed it were not intelligent and capable. The whole point of Agile is that change is an inescapable part of life, and that rather than try to fight it, development processes should be able to respond to it when it inevitably occurs. If a product roadmap changes 6 months after development starts due to changes in the marketplace, than that is just what being Agile is all about!



Anonymous posted on Thursday, November 12, 2009 4:13 PM
Ken:

Ellen defined a roadmap as "...cohesive bundles of externally visible functionality that should align with business goals and objectives". In other words, first understand the business - then determine solution bundles. Lets keep things in perspective here: Typically, if a BA spends about a month creating data flow diagrams (which capture goals, objectives, and supporting functions/processes), he/she can then come up with the list of "solution bundles" in about a day.

Of course, if there is largely no need perform an analysis of the business, then you just largely implment a solution. This sounds like what happened on your project.

Except for the projects that I have lead, only the small projects that I am familiar with created first-thing a solution roadmap that did not require significant changes. As a consultant, I have evaluated the dozens of requirements specs - with the primary purpose of uncovering "the roadmap". Except for a couple of smallish efforts, I never found one of any rigor! Heck, I will go you one step further: I was not even able to uncover a single Context Diagram (formal model of system scope) on a larger scale system project.

P.S. Ken, we are not talking about roadmaps that will change over time. We are talking about up-frount, first-thing, roadmaps that don't require any other iteration.

Tony

KenAnderson posted on Thursday, November 12, 2009 4:47 PM
Tony:

Ellen actually says this about a roadmap: "Because the requirements represented in your product roadmap are high-level, the roadmap shows features: "cohesive bundles of externally visible functionality that should align with business goals and objectives. Each feature is a logically related grouping of functional and nonfunctional requirements described in broad stokes." The roadmap shows features arrayed across time and releases. The features in the roadmap are used to build or extend you product backlog.

The roadmap enables senior managers to plan their sponsorship of the development effort and establish governance and feedback loops for their funding decisions.

The product roadmap is an evolving framework, because you want the flexibility to end the product development journey before the originally envisioned development time frame."

I think you are missing point about agile development - the essence of the Agile philosophy is that roadmaps DO evolve over time, and the initial is just a first cut that helps management decide whether to fund a project, and to give the project team an initial direction to start in.

As I think I said earlier, the fact that an initial roadmap ends up being changed doesn't mean that there was something wrong with it or that it didn't have value at the time it was created.

You say: "P.S. Ken, we are not talking about roadmaps that will change over time. We are talking about up-frount, first-thing, roadmaps that don't require any other iteration."

But this is precisely what Ellen IS talking about!!! I really think you mean something different by "roadmap" than what Ellen does.

Have you worked on an Agile project?

Anonymous posted on Thursday, November 12, 2009 6:05 PM
Ken:

Two different scenarios:

* First-thing, up-front, create an adequate high-level roadmap of features that, during work on specific iterantions, will subsequently evolve to incorporate changes

* First-thing, up-front, create a high-level roadmap of features that, during work on specific iterations, is found to be so fundamentaly flawed that a new road map must be created

You are thinking in terms of the first. I, the second. What I am saying is that for larger scale efforts, no one is smart enough to first-thing create a high-level roadmap of features that will not have to be redone - not changed - but, so off base that it willl have to be redone.

You asked me if I have worked on an Agile project. The answer is yes. I in turn ask you if you have ever worked on a larger scale project were you performed all of a formal business analysis? (This would occur as part of features roadmapping.)

Tony

P.S. I don't know what the protocol is regarding having debates in the comments part of an on-line article. I suggest that if you want to further discuss this issue that you initiate a forum thread, and I will respond there.
zarfman posted on Thursday, November 12, 2009 6:30 PM
Greetings one and all:

I read this article once, I put it away and then reread it three or four times. Unfortunately, I still have only a meager grasp of what’s being said.

Then it hit me. This article looks like it was written by a jargon generator. Google “jargon generator” and you will see what I mean.

Other than lots of jargon, this article is big on DO this and DO that. However, in my opinion it’s very short on HOW to do this or that. Kind of like a boxers corner telling the boxer not to get hit so much.

Some examples of DO jargon follow; define, review, adapt, prune, prioritize, gain understanding, obtain, identify, agnostic, holistic, flexibility, optimal, answer, formulate, conduct, determine and handle. To name only a few.

Small wonder that some of you are fighting over the word roadmap. Questioning each others credentials suggests to me that reason and rational discussion have left the arena.

Regards,

Zarfman
KenAnderson posted on Thursday, November 12, 2009 7:33 PM
Zarfman,

I was not questioning Tony's credentials - I was just curious about whether he had worked on an agile project before. I'm working on my first one, and there has been a significant learning curve for me, and it has taken me a while to get used to it.

Certain things about agile might not make sense if you haven't experienced them, so I really just wanted to know more about his background.

There is a lot of gray area when it comes to most of these topics...I'm really not at all trying to be combative - just to understand where Tony is coming from. I find these topics interesting and challenging, and I feel I always have more to learn. But it can be difficult to have a meaningful discussion with someone you don't know unless you are careful to clarify terms and understand what people mean by certain things.

As far as your comments, while there is plenty of jargon in the article, it is also a short article written for a website - I don't think it is realistic to expect it to do much more than provide a high-level, and necessarily somewhat superficial view of the topic. I think the writer does a reasonably good job of describing how requirements gathering be done on an Agile project - if you are interested in that subject and want to know more, there are plenty of books on the subject.

I would say that the techniques used to elicit and define requirements on an Agile project are not necessarily all that different that the techniques that you would use in a waterfall project - but the timing is different.
KenAnderson posted on Thursday, November 12, 2009 7:48 PM
Tony,

I started a thread called "Agile Requirements and Upfront Roadmaps" in the "Agile Analysis & Techniques" forum.

Ken
ajmarkos posted on Friday, November 13, 2009 8:52 AM
For Ken and Zarfman:

Ken. I am not offended. Your questions are welcome. By the way, the BABOK 2.0 emphasizes that the tasks on an Agile project are the same as on a Waterfall project, only, just as you say, the timing is different. (Note: The typically recommended techniques may vary.) "See you" in the forums.


Zarfman. I can relate to your comment about boxers in their corner! To me, the Agile movement often seems like a bunch of sound bites. Statements like: "Do just enought requirements modeling" is a prime example. I have been trying to determoine HOW this is to be done in Agile and have found nothing but confusion on the part of the Agile community. Example: Be minimailist - but utilize analysis techniques that are off base on capturing the essential. Translation: Be effective using ineffective techniques.

By the way, I tried the jargon generator tool that you suggested, and the second jargon it generated was: "Integrate Shared Functionalities". Is this not another a great Agile battle cry!

Tony
zarfman posted on Friday, November 13, 2009 7:42 PM
Tony:

I’m happy that there is a least one other person in the world that see’s some of the same problems software methodologies that I do.

By the way glad you could relate to the boxer metaphor. Back in the day I coached a golden gloves boxing team. Some of our boxers got through the local and into the regional tournaments but never made it to the nationals.

Regards,

Zarfman
zarfman posted on Monday, November 16, 2009 5:07 PM
Tony et al:

Unfortunately, I don’t seem to have all my thoughts about a subject on the same day.

It occurs to me that the agile methodology is very similar to the old software prototyping methodology. If I remember correctly both are iterative in nature. From what I recall prototyping seemed to work reasonable well.

I wonder why it went away? On the other hand maybe there were some problems and someone decided to re-name it and declare it the best thing since sliced bread. This happens a lot.

However, methodology is only part of the process. Those who convert requirements into code or create databases can really screw things up. I can’t count the times I’ve heard someone say I’m waiting for the computer to come up. Or, is this thing still running? Maybe I should re-boot.

Moreover, these were purportedly completed projects.

Regards,

Zarfman

KenAnderson posted on Tuesday, November 17, 2009 11:46 AM
Zarfman,

I think you are right that there are many similarities between agile methodology and older prototyping approaches.

I think the key differences is that agile methodologies take things a step further, in that the goal of an agile software development project is to deliver an increment of working software at the end of each development iteration. In theory, the software increment should be ready to deploy, and the product owner can decide to deploy at the end of any increment. In practice, I don't think it always works out that way, but that's the goal.

This approach lends itself better to some situation than others - I think it works well for example, when you are talking about a website where it is easy to add on small incremental features. It wouldn't necessarily work as well for a large enterprise IT project.

I couldn't agree with you more that methodology only gets you so far. Any methodology is at best a roadmap or a guidebook - every project is unique, and you have to be able to adapt the methodology to the situation at hand. And as you say, the skills of the people involved are critical - methodology cannot turn a bad analyst or developer into a good one.
Only registered users may post comments.




Latest Articles

Six Estimation Safety Tips
Oct 13, 2019
0 Comments
Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry w...

Copyright 2006-2019 by Modern Analyst Media LLC