Posts tagged feedback
Principles Part 4 - Feedback Loops

So, where are we now? Over the last few weeks we have looked at the first 5 of my agile principles -

  • They are built around small, self organising teams

  • The team has a clear vision of what they are doing and where they fit into the bigger picture

  • The team has a well defined backlog of work

  • There is a content authority responsible for making sure decisions are made quickly

  • There is a clear bidirectional service agreement between the team and the rest of the organisation

We have a pretty good setup going now - we have an efficient delivery engine (the team), a destination (the vision), a route (the backlog), a navigator (the content authority) and last time we added a clear service agreement, so the team and organisation know what's expected of each other. With this sort of structure they can really start to get things done. But there is still one more thing to add to make the team really high performing - the ability to improve.

Read More
Legacy is Anything Without Feedback

This post is the result of a conversation I had the other day, over a few after-work beers with Andrew Knevitt. He deserves a large part of the credit (and/or blame) for this for starting the ball rolling. Andrew was bemoaning the amount of legacy he had to deal with and I immediately started talking about code and automated testing. This wasn't what Andrew was referring to though. He was working mostly with business process and was referring to the problem of legacy business process. We all know the problems of legacy code - hard to maintain, fragile, lots of manual testing required. Legacy business processes have similar problems - clumsy, fragile, constantly out of date, lots of manual work required, and so on.

We both agreed that legacy process was a problem but neither of us could come up with a good explanation of what made a business process legacy. It's more than age - some old processes work really well but some brand new ones are out of date as soon as the ink is dry. So what makes a business process legacy? During the course of the discussion, I trotted out one of the more common definitions of legacy code - legacy code is any code written without automated tests. That was when the lightbulb went on for both of us. Legacy business process is any business process without a built-in feedback loop. But not just any feedback loop. A 2 yearly process review cycle isn't enough. It has to be fast feedback.

Read More