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.

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

• A 68 slide deck on “Responsibilities and Challenges of the Agile Product Owner”
• A paper on “Usability investigations for Agile user centered designs”
• A very comprehensive blog post on “Agile Development is more Culture than Process”

Centralize vs. De-centralize. Is SOA the answer?

With the economic downturn, businesses will be looking for ways to control costs. Will that mean more centralization? How will more centralization conflict with the web2.0 trend towards lighter more de-centralized apps. Will the lighter and more niche software/hosted products find that funds from business units are drying up?

Popular Knowledge Management expert David Gurteen spoke about this tension even before the financial crisis on his blog. Larry Hawes has a recent blog post discussing Autonomy in Collaboration.

I have had several discussions in the last few days with a VA-based firm currently struggling with the issue of centralization. Historically, their business has been run as autonomous business units free to operate in the way that best meets their customers’ needs.

While I am sure this firm has always struggled between centralization and de-centralization, the web has exacerbated the problem and web2.0 has taken it to yet another level. With the advent of the web, each unit began developing a channel to interact with their customers. A few years ago when the company wanted to upgrade to a more web2.0 approach which allowed their customers to contribute more in the online environment, they sought to build a common platform.

However, the autonomous business units lived on. Because they are quite independent, they are constantly seeking to diverge in order to meet the specific needs of their customers. At the same time IT continues to work towards increased centralization. As you can imagine, this is creating some tension.

A service oriented architecture (SOA) with shared web services and appropriate SOA governance might be their salvation. If IT can control the main architecture and help facilitate the sharing of approved web services, this firm may be able to get the centralization they need while allowing for business units to meet their own customer needs.

Is SOA the way that this increasing tension might be relieved in many organizations? I doubt IT is going to give up working towards standardization and cost savings and I know that if business units feel their customers are not being served by what IT is providing, they are going to continue pushing for autonomy. If not SOA, how is this tension going to be resolved?