Time and again, when I’m discussing the fundamentals and foundations of agile practices, someone will bring up an obscure edge case in an attempt to show why they can’t use agile in their organization or to solve their particular problem.  There are always situations where the straightforward use of any technique requires intelligent adaptation.  In order to adapt to the situation at hand, we first need a solid understanding of the fundamentals lest we misapply the technique and end up in the weeds.

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.


Everyone knows the saying, “two heads are better than one”.  Here’s another example of the benefits of pairing.  I like doing crossword puzzles.  I can do most of the Trib ones but the New York Times is a different story entirely.  Monday and Tuesday are the easiest.  By Thursday, Friday and especially Saturday, I’m hopeless.  Sunday is fun because it’s big and has interesting themes.  Sometimes my crossword brain, as I like to call it, is on holiday.  I stare at the Sunday puzzle, getting a few clues, then give up in despair.

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.

Agile 2009

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 !!!

I love starting new agile gigs, be they project work or coaching.  It feels a bit like the first day of school…..have to get a new lunch box, note books, shiny new shoes, etc.

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.

This is the last part of the Business Perpspective post.  The last 2 questions are:

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.

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?

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.


What impact will agile have on time-to-market?

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.


While most of my coaching gigs come through requests from IT, I would prefer it if there was direct pull from the business instead.  Given that, when IT organizations are considering adopting agile practices, I point out to them that one of the keys to success it to get business buy-in right from the start.

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……

Over and over…..”I’m agile”, “we’re agile”, “sure we’re agile”…but what does that mean anymore?  “We do iterations” ! “Oh?”, I ask as this is one of the most common answers I receive.  “And what do you do during those iterations?”

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

While I think the idea of certifying one’s mastery of knowledge in a specific field is a noble goal, it is also fraught with issues.  Many certification provide proof on one’s memorization and test taking abilities, but do not certify that the individual is capable of applying this knowledge in a practical or meaningful way.  There is plenty written on this subject so I won’t belabor the point.  I have been using Scrum and Scrum-like practices for nearly 10 years.  I know there are some 300k CSM’s around the globe.  It seemed to me like it might be a good thing to add to my resume, along with some of the other more advanced Scrum certifications; practitioner and coach.  So last week I paid the course fee and actually had a lot of fun in the class.  Lowell Lindstrom did a great job and there was some lively discussion amongst the experienced and not so experienced alike.

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.

Next Page »