Getting Better

June 26, 2011

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

Some time ago, Jeff Sutherland said the biggest impediment is team’s not getting to done-done inside the Sprint.  Maybe that one as well, still.  Note that it is strongly related to #3 above and to others.

When I say ‘our’, I mean overall, considering all the teams I see and hear about.  On average.

Impediments

The idea is that, if we focus on the top impediment and fix it (perhaps a bit at a time), we can get better faster.

So, do these five impediments 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.  Yes, probably faster with their support.

 

 

« « Getting personal || Freedom » »

Posted in: Better Agile, Key problems
Tagged: Tags: , , , , ,

5 thoughts on “Getting Better”

  1. Anonymous

    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

    ↓
  2. Rini

    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!

    ↓
  3. Derek Gardiner

    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.

    ↓
  5. Dizzy Dee

    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.

    ↓

Leave a Reply