Sunday, June 26, 2011

Getting Better

My guess, based on experience and many conversations, is that these are 'our' top 5 impediments.
  1. Need better Product Owners
  2. Not enough focus on removing impediments
  3. Need better automated testing
  4. Technical debt
  5. No trend of improving velocity
When I say 'our', I mean overall, considering all the teams I see and hear about.  On average.

So, do these resonate for you? Or, as a general rule, do you find other impediments in the top 5 in the first year?

I hear people often say 'lack of support for agile from top management' as one of the top 5.  If we phrase that as 'inability to convince top management to support agile' at least that gives us the power to change ourselves (become more convincing) rather than feel powerless as we wait for management to support agile.  In any case, often we can make great progress without their support (although maybe more faster with the support). 

5 comments:

Anonymous said...

Better test data in the database. If you are dealing with lots of tables with links between them building a reasonable simulation of real live data is a lot more complicated than than most people think about... Hm.. Let's see I got a juvenile case so I need an attorney, juvenile guardian, case, case calendar, depositions, hmm translator, court documents.. it just keeps going and going.. and no one really thinks about it... Now lets have 500K cases for load testing.... What do you mean it takes 3 months to build test data..LOL

Rini said...

I always label management as "problem busters". Look critical at you 5 points and you will find out that the answer lies with management. They can take all 5 of them away!

Derek Gardiner said...

Inability to convince top management to support agile' is a weird statement for me. While I agree that we need to take extra responsibility you never hear management say stuff like, "we need to convince development of cost accounting" for example. We do make progress, but it's limited until some one is able to translate software engineering into accounting or business management terms. I've found that if you're doing your root cause - the 5 why's and you can't reach the 5th why because management isn't available then it's an indication that management does not have a solid understanding of agile.

Joe Little said...

Anon,

I like your comment about test data.
I think that is often a key problem.

Thanks,
Joe

Dizzy Dee said...

Test data is definitely a huge factor - in almost all companies I have worked at, this has always been a challenge.

Early in 2002 - before I was introduced to agile, I worked for a company that had a very effective way of handling this problem.

We spent about a month, populating with real-life, but not sensitive data. A former client had assisted us in making sure that the scenarios we tested were those in use by our clients. Once a sufficient amount of valid, high quality data had been built up, we backed up the database.

Before each release, this database would be restored, new SQL scripts would be run, and preset tests would be run - both manually and automatically. Results would be compared to expected results - as was recorded during the initial setup process.

I know this might be seen as narrow minded tested. By no means am I saying that these are the ONLY tests that need to be run, but it's a good and solid base which - if you have the capacity to go through at each release - is an excellent way to ensure that regression issues are minimal.