Archive of Agile Articles

Just Plain BadLameAverageGoodGreat (3 votes, average: 5.00 out of 5)
Loading ... Loading ...
January 5th, 2010

Most Engaging Articles of 2009

Engagement – that’s what this whole product management blogging thing is about.  Check out what Tyner Blain readers found to be the most engaging articles in 2009.

Read the rest of the article…

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (2 votes, average: 5.00 out of 5)
Loading ... Loading ...
November 3rd, 2009

Design-Free Requirements

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.”  Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Read the rest of the article…

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (4 votes, average: 5.00 out of 5)
Loading ... Loading ...
October 19th, 2009

Agile Prioritization: Which Widget?

Your company is building out a toolkit to support third-party developers.  You’ll need a bunch of different types of widgets – combo-boxes, text entry fields, domain-specific controls, etc.  You’ve got a long list of desired controls from your customers.  You’re agile.  What do you build first?

Read the rest of the article…

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (5 votes, average: 4.40 out of 5)
Loading ... Loading ...
August 3rd, 2009

Concise Requirements

Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done.  Great requirements exist to do three things:

  1. Identify the problems that need to be solved.
  2. Explain why those problems are worth solving.
  3. Define when those problems are solved.

Read the rest of the article…

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (5 votes, average: 5.00 out of 5)
Loading ... Loading ...
June 30th, 2009

Agile Maturity Model – What’s Next?

The maturity model approach to describing organizations and processes comes and goes out of fashion.  It is a repeating framework de jour.  In the game of agile jargon whack-a-mole, the agile maturity model is poking its head up again.

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (2 votes, average: 4.50 out of 5)
Loading ... Loading ...
February 19th, 2009

Failure To Launch (Your Product)

Jump forward in time to the day of your next big product launch (first release, new features, new market segment, etc).  And your site/application crashes due to the “unexpected” demand.  All you can do now is look for a bucket of water to put out the fire.  What could you have done to prevent this disaster?  Jump back to today and start doing it!

Read the rest of the article…

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (4 votes, average: 4.50 out of 5)
Loading ... Loading ...
February 10th, 2009

Agile Non-Functional Requirements

Just because your requirement is not a user story does not mean you have to throw it out when planning your next sprint.  See one way (that is working) for managing non-functional requirements with an agile team.

Read the rest of the article…

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (32 votes, average: 4.78 out of 5)
Loading ... Loading ...
February 2nd, 2009

User Stories and Use Cases

User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first.  They differ from use cases in some important ways, but share more commonalities than you might think.

Read the rest of the article…

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (7 votes, average: 5.00 out of 5)
Loading ... Loading ...
December 30th, 2008

Stakeholders in a Barrel

There’s really only one way to travel down a waterfall – in a barrel.  A lot of people died this way, but some survived.  Software projects have been predominantly waterfall projects since the start of software projects.  And stakeholders rode down those projects, basically in a barrel.  The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end.  Stakeholders in waterfall projects don’t know if they will succeed until the end.

An agile project is dependent upon tight interaction (and feedback) with stakeholders.

If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?

Read the rest of the article…

Post to Twitter Post to Facebook

Just Plain BadLameAverageGoodGreat (1 votes, average: 5.00 out of 5)
Loading ... Loading ...
December 11th, 2008

ProductCamp Austin Winter 2009

The second productcamp for Austin is just around the corner!  Are you going to be there?  You should.

Post to Twitter Post to Facebook

Loaded Web - Global Blog & Business Directory