June 2009 Archives

I had the opportunity to present at this year's Integrating Agile Conference in Amsterdam, Netherlands.  The daylong event was kicked off and closed by two fairly famous Agilistas.

First, Henrik Kniberg kicked off the event with an excellent keynote address focused on the value of Agile when applied correctly.  Check out his blog post on "Failing With SCRUM." During his presentation Henrik made some great points regarding root cause analysis.  I found one of his examples quite interesting - using his root cause analysis technique he had helped a customer uncover that the real issue was a lack of trust between IT and the business.  While Henrik's main point was about how Agile is simply a 'tool' that when applied correctly will improve application development, I found his point about trust most interesting because in my experience Agile, when practiced properly, will help overcome a lack of trust between IT and the business.  More on trust in a moment. . .

The closing keynote was given by Rob Thomsett.  I was actually late to the closing keynote but very glad I got to hear most of it.  For those of you who, like me, do not know of Rob, he is an 'old guy' with some very interesting insights into Agile.  You can read some of Rob's thinking in his personal blog.  While I don't know Rob, I felt like he was an old friend after his presentation - I guess that means he is a great presenter!  He is obviously a Star Trek fan and since he mentioned Stevie Ray Vaughn he must love music. BTW, I am sure if he reads this blog post he will chuckle about the "old guy" comment!

Rob also made some great points during his presentation regarding management style; agile adoption issues and he also hit on the point of trust.  He took the issue of trust beyond the relationship between IT and the business by calling out most of the audience (IT folks) and making the point that trust started with the technical team trusting each other.  Does your technical team trust each other?  Something to think about!
 

It was a great day in Holland for Agile - with over 100 people all sharing and learning.  For me, a key take away is how important trust is to being successful! 

I hope you will share your Agile experiences and how they have helped your business and development team overcome trust issues!
 
 

There seems to be a growing amount of discussion around the Kanban approach to software development.  For those of you who, like me, had never heard of Kanban, it has its roots in Japanese lean manufacturing concepts.  I read a great article titled "Kanban Development Oversimplified" by Jeff Patton.  If you are interested in the Kanban way to organize your development then give this a quick read - it is well written and starts off with a good look at the origins of the Agile methodology. 

From my perspective, having now done a little research into Kanban, the approach is very similar to something I practiced back in 2002 while looking after storage products for BMC Software.  In my opinion, Kanban is a great process for software product companies who want to drive efficiency across their product delivery process.  However, it is not ideal for corporate IT shops who are working on improving their application development processes and better alignment with the business.
 
Even though I'm an Agilista at heart, I believe we can learn from the Kanban approach, however, there are some things that just don't seem like a good practice.  For example:

• Lack of Iteration: Kanban doesn't include an iterative approach - which I feel is one of the key Agile tenets that delivers real benefit.  It allows us to continuously align with the business and deliver exactly what the business wants - regardless of the set of requirements we started with.  Invaluable in my opinion.

• No commitment to deliver: Without iteration and time boxed sprints you never have the opportunity to set expectations and then meet them - 'deliver early and often' as we like to say.  This is critical to drive business trust and Agile adoption. 

• Writing Larger Stories:  Kanban proposes writing larger stories around the concept of a minimal marketing feature (MMF).  Once again, a concept that makes a lot of sense for software product companies in the commercial software world.  In my experience, writing larger stories results in longer development cycles for a feature, resulting in the opportunity to wander off the path before a user sees what you have done.  Historically we have never managed to get  the MMFs correctly defined, which results in rework and extra costs.  The approach of developing some of the functionality and then getting feedback is a hallmark of Agile and leads to better business alignment by allowing the team to react to change from the business.  This works better with smaller, role based stories.

Even with these shortcomings, Kanban's lean manufacturing approach is interesting as it should really help a team identify process bottlenecks, and I suspect could be applied in a more Agile manner of development. 

I am sure you all will have lots more comparisons and thoughts on how Kanban could make your Agile approach better. Let us know what you think! 

So, SAP is embracing Agile development for their new SaaS strategy (see Phil Wainewright's post on the recent SAP announcements); About time don't you think?  Most ISVs are way ahead of the hype around Agile and have been applying some form of Agile development since the beginning of this century. Now, for those of you working in corporate IT shops who think SAP's move is a great endorsement of Agile methodology and are going to run to your management shouting "the time is now!" ...let me caution you on a few key points where you might run into some bumps. 
 
1. You probably don't have an ongoing product-based budget. This means that you can't simply keep on developing until the customer is satisfied.  In your corporate IT world you will still have to get funding for each project, which means some form of project scoping and estimating. If this is done the way it has been in the past it will not be very Agile! Also, if you really embrace Agile, those features that get pushed out of scope by the business (due to more important features) will have to be put into another project which will require more scoping, estimating, funding and perhaps even a bid process with your third party contractors - NOT very agile.  All this can defeat the benefit of Agile and leave your business with the Agile blues. (I discussed this issue in a previous About Agility Blog post)

2. You probably don't have a staff of full time Product Managers.  Of course you don't have product managers in a corporate IT shop.  This role is supported by the business users. Thus, you have to work really hard to change corporate culture and get these business users to play in an Agile way.  This will require more of their time, more trust and a shift of application ownership during development, that for many is a real culture shock.  Be prepared.  The good news is within a few sprints you should have them on board as long as you keep your sprints short (2 weeks max) and hit your sprint demo deliverables.  Once they get a good taste of Agile they will not go back!
 
3. Your self-organizing team isn't so well organized. The challenge many of you in the corporate IT world face is a lack of on-staff resources.  Thus, a lot of applications work is co-developed or outsourced to third parties.  This makes the concept of self organizing teams a bit risky as it introduces lots of politics, negotiations, etc.  Once again, not very Agile.  You will have to find the right contractors and get your procurement organization to let them participate in an Agile manner so they don't risk losing their shirt or end up using non-Agile practices. 
 
So, while I am a big proponent of Agile, to be successful in the corporate IT world requires a lot of culture change!  And while SAP may go Agile in one big push, for the rest of you, I say "be Agile - take it one project at a time, think big but start small and learn with your business as you go."  

Calling all corporate IT shops - have you adopted Agile practices? Have you encountered these issues? How have you dealt with them?