Retrospectives should be a natural and continuous process

As a Xebian my typical day is spent working on one of the projects we do for our clients. And for those projects that I do together with other Xebians I end every day with a fifteen minute chat; discussing what we have done that day, sharing our observations, learning lessons and adjusting our plans for tomorrow. Personally I love this short feedback cycle: the learning is more deliberate and it allows me to take into account all the details.

Retrospectives provide an opportunity for a team and its individuals to learn and improve. In their most simple form you answer the questions ‘what went well?’ and ‘what do we want to improve?’. This is followed by a number of action points that the team commits to picking up in the next sprint: iteratively becoming better.

However, if your retros consistently result in a long list of improvement and/or action points you have a serious problem. Your team is either failing to make the necessary improvements. Or, more importantly: your internal feedback cycles are way too long.

As developers we spend a lot of time and effort on building pipelines that can securely and automatically promote our code increments to a production environment. We slice our user stories in such a way that small chunks of value are delivered at a consistently high pace. We do this because we value the quick feedback cycles on our work. Are we really delivering business value?

We have to apply those same quick feedback cycles to how we work together. Nothing is stopping you from holding your own mini-retrospective once a day. Or from having a five minute chat with a colleague as soon as you notice something that can be improved, followed by: improving it. Does the improvement take more time? Slice it as you would with any user story.

Once your retrospectives are no longer just a bi-weekly ritual, but a continuous process you can instead ask the following questions: ‘what went well?’ and ‘what improvements have we made?’. A retrospective is not just a bi-weekly ritual, a recurring event on our calendars, but rather it’s a continuous improvement proces! 

I am a specialist at Qxperts. We empower companies to deliver reliable & high-quality software. Any questions? We are here to help!

Breaking through organizational silo’s with EventStorming

Tedious and lengthy internal processes delay the delivery of value to end-users and lower your competitiveness. The bigger your organization, the more likely you are to encounter this problem. Visual collaboration tools like EventStorming can help with kickstarting the necessary focus shift.

Internal Competition vs External Excellence

Once an organization reaches a certain critical mass, people stop looking outwards. Instead, the focus shifts to an internal competition: outdoing that other department.  When this is the case,  our “definition of done” or standard of  “quality” becomes anything that exceeds what our colleagues have set. As a consequence, we find it acceptable to have a time-to-market of six to twelve months between a feature’s request and realization. Not only do we accept this; we’re proud of it.  Our “quick” turnaround time makes us the best student in the class within our organization, and we’re praised for achieving results–until we’re not.

Like when we suddenly realize our competitor is taking feature requests on Twitter and has a TTM of just a few weeks (or even days)!

Read more →