Take for example, the use of User Stories on an agile team.  Most novice teams (new to agile) I’ve coached struggle with the shift to story-based, incremental development.  Fundamental to productive adoption of User Stories requires an understanding of how they fit into the overall life-cycle of the project as well as how to identify and author good stories.

Small stories are great because they enable fine-grained prioritization by the customer.  Small stories are great because they provide a continuous sense of accomplishment to the developers.  Small stories are great because there is less to test at one time.

Yes, but what about the edge case where you have to integrate with a nasty old legacy app with no notion of an API.  How to you break the epic integration story apart?  Simple.  Create small, testable stories that each support some up-stream business need and incrementally build towards a solution.

Yes, but what if I need a large framework build or installed?  Again, think small.  Think incremental.  Think testing.  But what if we make a mistake and have to re-do everything because we haven’t designed and planned everything up front?  Well, we rarely if ever get software right the first time regardless of how much time we spend up front.  In fact, usually when we design and plan for everything up front, we get some things right, and some things wrong. Up front thinking tends to get us locked into a solution space.  After all, we’ve invested so much time and energy in designing this baby.  So maybe some of the features won’t be needed.  And maybe some will have to be tweaked to fit what’s actually needed.

Code is never written all at once, even when there is a up-front design.  The fundamental question is, how do we know when any given piece of functionality is DONE?  Stories, assuming they contain acceptance criteria (otherwise I don’t consider them stories), give us an edge.  We can objectively measure when they are complete because we can test them.  We can take large problems and divide them into small chunks to help us manage our work and reduce risk.

So, are there edge cases where user stories won’t work?  I suppose so, but I fail to understand why.  In fact, I’m not sure I understand the question.  Are user stories a panacea for our development woes?  Of course not.  But, an understanding of decomposition, incremental development, and teams with the skill set necessary to tackle the project at hand is a recipe for success.

On the other hand, once my wife Terri has finished her Sunday reading of the paper and we sit down together to work on the puzzle, it’s a whole new world.  Yes, she chides me if I try doing it in pen as the optimist in me often results in crossed out answers which take up most of the correct answer space.  But the results are worth it.  As in pair programming we’re discussing possible answers (design options), laughing when we solve some pun-based clue (simple solution), complementing each other when we solve a particularly challenging one (team work and mutual respect), keeping each other focused, exchanging the pen (mouse & keyboard) from time to time, and generally enjoying the collaborative effort.

In the end, the results are far superior to the results of going solo.  I believe this holds true for solving programming problems as well and representing another case for pairing.

I’m very excited about the upcoming Agile 2009 conference to be held in Chicago this August for many reasons:

1)      One of my “talks” got accepted.  I’m going to lead the Agile Game Monday afternoon, so join in if you’re around.  For those new to agile, it’s lots of fun and you’ll come away getting what the rhythm of an agile project is like.

2)      The company I’m working for, Redpoint Technologies is sponsoring the event: logo on tee shirt and link from sponsor page on the conference web site.

3)      The conference is local so I can’t wait to meet lots of other agile enthusiasts from the area.  It’s also a great time to catch up with old friends and network and meet lots of new people.

4)      I love the experience reports and case studies people present.  Hearing from the trenches is always enlightening.  I also enjoy learning some new techniques to try while coaching and mentoring teams.

Hope to see ya there !!!

Here’s what I like to bring: a new set of sharpies, white board pens (so many conference rooms have just black or ones that are old and nearly out of ink), multi-color index cards, usually in 2 sizes, post-its of various colors and sizes, business cards, sticky tack to help display things on walls, and that’s about it.  Hopefully I can find tape on-site and other supplies are usually picked up later.  If we’re creating a story wall, 12″x12″ cork tiles can come in handy and some heavy card stock for signage and reusable status indicators.  I used to use thin plastic CD holder stapled together until a colleague showed me a tracking technique that didn’t require a left to right progression of this precarious assemblage of plastic, cards, and dots.  Oh, of course…at some point different color mini sticky dots are great status indicators.  Finally, snacks and maybe toys.  Nothing to cheer up the collaborative workspace than nice things to munch on or toss around as a talking token during daily stand-ups.

I’m sure I’m leaving a few things out, but there’s always an office depot or other within shouting distance of the project site.

3)    We have lots of concurrent projects underway.  I hear agile works best with dedicated teams.  How will we get all of our projects done under this new approach?
4)    How will the staff in IT respond?

3) Concurrent Projects: Moving the Work to the Teams

It takes teams to build software. While individuals working in a chaotic, undisciplined manner, can and do deliver, highly productive and efficient teams will produce higher quality products, in less time, and for less cost.

Most IT departments move people to the work, resulting in highly inefficient time slicing scenarios.  With agile’s team orientation, we move the work to the teams instead.  Of course, this is not 100% across the board.  There are still specialists that work between projects and we do recommend periodic staff rotation between teams. However, the majority of the staff are working together one team, with each team focusing on one or more initiatives.

4) Impact on IT Staff
Most people like working in teams and agile is very team and collaboration focused.  Learning a new skill can elicit fear, trepidation, and excitement.  Getting the most value from the agile practices usually involves an increase in discipline via specific software engineering practices.  It takes some time to learn these practices, so it helps to provide guidance and support.  Having an adoption plan and a way to measure teams agile maturity provides visibility into the changes over time.

Dispelling Some Agile Myths: Agile is not…..

… working without a plan.    Adaptive planning occurs continually throughout the project so we deliver the highest value features first.
… working without documentation.    Documents that add value are created just-in-time. Much of the documentation is short-lived.
….glorified hacking.    Teams adopt a set of highly disciplined engineering practices.
….risky nor new.    A majority of software companies utilize agile practices, particularly on the east and west coast. The Agile 2009 conference will be held in Chicago this summer.  Attendance is expected to top 1,600 and more than 500 proposals for presentations have been submitted thus far. Additionally, many of agile’s practices come from other, longer established, fields such as manufacturing.

Customer Involvement: Making the Best Use of Your Time

There’s nothing like having to read through a 50 page “requirements” document or to sit the endless reviews of them.  What’s worse is that when the system is finally delivered, it doesn’t satisfy your most important requirements, so it has to go through an enhancement phase before it’s ready for prime time use.
Agile recognizes that we can’t accurately define everything up-front.  We start by working with you to create a shared vision and an estimate for the project.  Then we ask your help in defining small subsets of detailed requirement just as they are needed. Each subset is developed, tested, and reviewed by you before we start on the next.  We also ask you to clarify questions along the way so we build what’s most fit-for-purpose.
One advantage of regular yet short time commitments is that you see the system as it is being developed.  You can also change your mind if the business needs change. You might choose to use the product without all its bells and whistles, or you might decide to shift your efforts to a higher value project.  The diagram below show the overall pattern of one project release.

Time-To-Market Impacts: Adaptive Planning & Evolutionary Delivery

As a customer, you’re seeking business value and a solid ROI from your system investment.  Waiting one or two years to see results can be both risky and costly.  There is a high probability that your needs will have changed and there is the opportunity cost of unrealized benefits.  One beneficial aspect of agile is continued focus on the delivery of the highest value features first and to deliver those frequently.  This helps ensure you get want you need and do not spend precious resources on low value items. The figure below shows how the traditional approach defers both risk and benefits realization, while the agile approach moves risk forward and provides a steady stream of value over time.

Some of the common questions that business folks seem most concerned with are:

1)    What impact will agile have on time-to-market?
2)    I hear the business customer needs to be involved a lot on an agile project.  I have a business to run so I don’t want to waste a lot of time in meetings and reading lots of documents that I don’t really understand anyway.  How much will I have to be involved?
3)    We have lots of concurrent projects underway.  I hear agile works best with dedicated teams.  How will we get all of our projects done under this new approach?
4)    How will the staff in IT respond?

Exploration of different ways to answer these questions to follow……

I find it rather challenging at this point, to come up with a brief way to describe what I mean by agile…so here goes…attempt #301

• Consistent focus on activities that add business value

• Adaptive planning in time-boxed cycles

• Incremental, test-driven development

• Customer engagement

• Continual process improvement

• Collaborative and transparent

All this = highly productive, cost effective teams

Having said that, I firmly believe that the reward for attending the class should be a certificate that you attended a Scrum training class. A two-day class does not, IMHO qualify you to be a Scrum Master.  You can sleep through the class or not listen or not get the concepts at all, and yet you are still added to the growing roll of CSM’s.  Even if you do get it, you have no expereince yet.

Again, I like the idea of having an organizational structure around these sorts of things, but I also beleive names are important and should have meaning!!!  … end rant.