jonathan Babcock's Library tagged agile →  View Popular

Some of my agile coaches in the past argued that use cases should not be used at all. I disagree respectfully. As use cases and user stories are in essence a verbalization of the requirements from the point of view of the actor or user, I argued and proved that they can be used to populate an agile product backlog.

www.plannowtech.com/blog - Preview

agile usecase userstory

Over the past few years, the rise in popularity of SCRUM has raised many questions as to how agile works in practice. One of the recurring questions has been: is there a place for the business analyst within the ADM environment?

In my view, the answer is unreservedly and unquestionably ‘yes’.

www.fronde.com/blog - Preview

scrum agile businessanalyst

Prior to agile, many enterprises have followed a sequential, stage-gated, waterfall development model. In these cases, it’s likely that the Product Manager’s mindset has moved through a series of increasingly foreboding attitudes, as the figure below shows.

scalingsoftwareagility.wordpress.com/...re-agile-waterfall-development - Preview

agile waterfall methodology

For those of you who didn't attend Scott Ambler and Terry Quatrani's keynote "Software Development Strategies, Philosophies, and Techniques: Traditional vs. Agile" at this week's SD West conference, let me give you the gist of the first half:
Advocates of traditional software development approaches, such as waterfall and V-Model, are myopic bureaucrats who worship detailed specifications and denigrate the code necessary to build those specs.
Agile development practitioners, on the other hand, are logical pragmatists whose only goal is to build what the customer wants.
I sat in on Ambler and Quatrani's keynote to get a sense of whether cooler, more pragmatic heads had prevailed. I ended up more entertained than informed, and left with the impression that the debate remains as religious as ever.

blog.devx.com/...e-over-traditional-vs-agi.html - Preview

agile methodology

Agile Project Leadership Network Atlanta chapter

www.aplnatlanta.org - Preview

Agile Networking Atlanta

Talking last year with Scott Ambler who is IBM’s global lead for Agile development at the company’s Rational Software Conference, I made the mistake of suggesting that the methodologies and processes behind Agile almost form a kind of religion for developers who follow its creed.

community.zdnet.co.uk/...7,10012239o-2000458459b,00.htm - Preview

methodology agile religion

There are a lot of methods for developing software out there now. Choosing the best one for your company or team can be difficult - and that’s before you start adapting it to suit your particular situation. Here’s a brief history and overview of some of the more common ones you’ll come across. Each of them have good elements that you can make use of or learn from.

sheilapollard.wordpress.com/...hoosing-a-software-methodology - Preview

methodology lean agile scrum xp waterfall rup

Most interesting aspect of this is the comments. Lots of dialog questioning how well agile can work in less than ideal circumstances......

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.

www.batimes.com/...108 - Preview

methodology agile requirements

There are some circumstances where an organisation's culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn't do agile software development:

1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.

2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.

3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.

www.agile-software-development.com/...ns-why-i-wouldnt-do-agile.html - Preview

agile methodology

The approach is, of course, Agile, but adding the concept of an Increment or Micro-Increment on top of an Iteration. Increments should be measured in days, yet still deliver some demo-able or executable software to stakeholders. Micro-Increments are important as they drive projects to meet short term goals that are focused on software delivery, even if it's a simple as a dumb HTML UI mock-up, this adds infinitely more value that lines of requirements text or use cases.

380z.blogspot.com/...quirements-collaborate-on.html - Preview

requirements agile prototyping

As you might know from previous posts, the Cranky Product Manager is pretty neutral on Agile / Scrum.

Yes, Agile is trendy. Everyone is doing it. Some consultancies out there have tied their entire brand to the Agile concept (digression - how smart is this when the inevitable backlash against something so over-hyped will inevitably occur?).

And don’t get the Cranky PM wrong, Agile/Scrum can help greatly with many types of product development problems. It’s good. It can be fun. But Agile/Scrum is not perfect. It has its problems too. Some of which have been elucidated more eloquently by others.

Well, the Cranky Product Manager is going out on a limb and declaring that:

The BIGGEST problem with Agile/Scrum is its crazy, insulting, demeaning, and threatening lunatic fringe.

crankypm.com/...agile-community-religious-war - Preview

agile methodology

MSF for Agile Software Development makes iterative software development enterprise ready by providing features like risk management, release management and design for operations. This site contains updates to the process guidance, bug fixes, and supporting material for this process.

msdn.microsoft.com/...aa718795.aspx - Preview

templates microsoft agile

Alistair Cockburn's treatise on why he prefers use cases over the user story and product backlog.

alistair.cockburn.us/Why+I+still+use+use+cases - Preview

usecase userstory scrum agile cockburn methodology

One of the bigger challenges facing software projects is determining when and how to begin the transition from specifying requirements to working on a system design. Questions arise during this phase, such as: "I'm on an Agile project--what design artifacts should I produce and when?"; "My project creates use cases; do I detail all the use cases first and then jump into design?"; and "Which requirements should I tackle first in design?"

www.stickyminds.com/sitewide.asp - Preview

requirements design methodology agile waterfall

Description of and commentary on results of a survey exploring the adoption rate of Test-Driven Development (TDD) and related techniques within the agile community.

www.ddj.com/212902568 - Preview

agile methodology

Agile methods don't say anything about requirements because the traditional approach towards requirements engineering and business alignment is fundamentally flawed. Agile methods say a great deal about business alignment by the way. That is what the Product Owner (PO in Scrum or Customer in XP) is here for. The whole development process is about business alignment as stories are prioritized (by the PO) according to business value. Moreover, the business alignment is tested after each iteration.

www.searchfull.net/1918546.html - Preview

requirements agile

Let us be up front on this: the discipline of System Requirements Definition and Management has a chequered history, even more so than system design and development. Certainly the creation and marketing of Agile development approaches has some roots in the failure of previous approaches to deliver quality requirements to design/development; it says that requirements will always be too vague, so be prepared to build and change as building helps the business articulate what it wants.

The problem lies in that last word: “wants”. Asking business people, or any people, what they “want” is too open-ended (how do you know when all has been asked for?) and too imprecise (how do you know the right things have been asked for?).

The better question to ask is: what do you “do”? now, and in the future? Business people should and mostly do know what their business is, and the things they do to carry out that business. What they “need” Information Systems to do is to support carrying out that business, and help make that business more effective and profitable.

So, the root to defining requirements is to have business people describe their business processes. Each process needs to be detailed down to individual steps, to the point where a step defines something that is done by some person using some information. If the system is needed to perform or support a step, that is the requirement, as in “The system must have the ability to” perform the step.

blogs.itworldcanada.com/...-myth-of-changing-requirements - Preview

requirements design agile userrequirements

Presentation on Agile.

www.cooper.com/agile2008 - Preview

Agile waterfall methodology slides

Let’s be perfectly clear about one thing: 2009 will not only be known as the year the financial crisis hits in hard, it will also be known as the year everything turned agile. Please allow me to explain. The times when banks, insurance companies, car industries and the likes could start up multi-million software development projects of titanic ambition, with dozens of stakeholders, never ending requirements sessions and five year deployment plans are passed.

sanderhoogendoorn.org/blog - Preview

agile waterfall methodology

The point is that SDLC management processes along with their human and non-human components form complex systems. Their selection and adaptation must be performed thoughtfully and nothing substitutes for experience here since to a large degree, human behavior will be the make or break factor.

drjbutler.wordpress.com - Preview

SDLC methodology agile process