Tag Archives: development

The Power of “done”

My agile scrumtastic friend Andrew Tsui invited me to join him for an evening meetup of Agile NYC led by the master of all scrum masters, Ken Schwaber. My primary takeaway from the session is the importance attached to the definition of “done”.

Too many software development teams move onto the next set of desired features before they have reached a full complete, tested, and shippable state on the current set of features. This creates an over-estimated sense of the velocity at which the development team is progressing. Unfortunately, it is not as simple as the team picking up where they left off and completing the unfinished pieces before a customer release. Leaving loose ends in each iteration (sprint) is actually a compounding problem.

A team that consistently falls short of “done” ends up with a required stabilization stage which lasts much longer than the sum of all the missing elements from each iteration. The problem is easily rectified by allowing the development team extra time per sprint (short-term) in order to dramatically reduce the stabilization stage and save time in the longer-term (release).

Another nice side effect of slower velocity and increased amount of “done” per iteration is that the code base staves off the complexity that naturally slows velocity over time. Thus velocity can be maintained at a higher rate over a longer period.

Advertisements

Customer Development

I am in the early stages of a new start-up idea so I am poking my head up to look around for the latest best practices before getting underway.   I was referred by some friends to Steve Blank’s  idea he calls Customer Development. It’s not brand new, but it is certainly far from mainstream yet.

Not only do I feel that Steve’s framework is right for my start-up, but I was also compelled to write a blog post.  During my research I found a post so well written that I knew it was better to link out rather than write a new one myself.  Therefore, I highly recommend Jussi Laakkonen‘s post called “Customer Development or why 9/10 startups fail

Please note: just talking to your customers (focus groups) about their needs is NOT customer development.  You need to actually try selling to them and see what happens.  Steve suggests that selling should be brought as far forward as possible in the process.

I have begun forming my customer hypotheses.

  1. I will test my hypotheses by talking to a variety of customers (not too many)
  2. Building simple iterations and seeing if early adopters will use/buy
  3. updating my hypotheses and iterations based on what is learned from early adoption
  4. Developing a larger marketing push once adoption/return is clearly good enough.

Agile IT Methodology

Click on image for larger version

This post is all about IT.  There is no doubt that IT can have a tremendous impact on business, but if IT stuff makes your eyes glass over, might be best to select a different post.

Some Background:

“Waterfall” has been and is still the primary methodology for IT development.   It consists of a series of phases (eg. Strategy, Requirements, Design, Development, Testing) that are each completed in serial in order to reach a release.  The next phase in the series is not started until the previous one has completed and been “accepted”.  

Agile (in a nutshell) is an alternative that seeks to mash all the phases together and iterate through smaller blocks of functionality

Analysis:

Agile has been around since the mid-90’s.  Even with Google leading the charge with the concept of perpetually improving beta, we have not yet seen Agile take over as the de-facto standard.  If you ask the bulk of consultants at large IT shops like IBM or Accenture, they will tell you that they are primarily still using a waterfall methodology.   There are a few conclusions that may be drawn:

  1. Agile is mis-used
  2. Agile is inferior to waterfall
  3. It is difficult to transition from waterfall to agile

re: #1.  I have come across MANY people who say they are using Agile methodology, when in fact they are involved in chaos with no clear direction.  Projects like this give the methodology a bad name.  Just because you are not building huge requirements documents does not mean you are “Agile”.  It just means you are not “Waterfall”. 

re: #2.  I have also come across many IT professionals whom I respect greatly that sing the praises of “Agile” and confirm that their teams are far more effective with that methodology.  That is just proof by example, but likely you can point to similar examples?

re: #3.  I think that adoption difficulties are the crux of the issue.  Agile sounds simple at its core, but to really get it right, requires a lot of attention, a lot of focus, and complete buy-in from the entire team that they are going to interact in different ways than they ever have before.  They have to be willing to open the kimono and let everyone see their issues at all times.   This is a change management challenge.  Teams need to be willing to improve upon the process with each new project and not give up along the journey.

What experiences have you had with Agile?  Why has it not seen wider/faster adoption?

This post was inspired by a phone call that I had with Shaheen Hossain.  He is an Agile/XP coach and a scrum master.

Some resources you might find useful