Follow up from Christian Kaas, our Director Development, and his series of articles talking about “The way we do things around here” at LORENZ.
The LORENZ Heartbeat
What does this expression mean? Broadly, our development teams have created an easy to use and repeatable process for managing our release projects, a rhythm that some people call the “heartbeat” of the development teams. The major beat is manifested in our promise to our customers that we will deliver two major releases per product per year – one in April and one in October.
Based on this clear wider commitment, the teams work in short iterations (commonly called “sprints”) to develop product increments. At the end of each sprint – a rigidly timed two-week development period – we hold a review meeting for the teams to reflect on what they have achieved and a planning meeting to determine what they want to do next , including lessons learned for how they want to improve the way they work.
This is supported by a simple, daily routine. Every morning at the same time, for 15 minutes the team gets together and discusses progress in reaching the sprint and release goals, to determine who needs help and who can provide it. This daily ritual makes it very easy for the team members. The meeting times are of course documented and Outlook invites are sent, but we don’t actually need them. The 15-minute morning meeting is such an ingrained habit, everyone just does it automatically. No need for prepared agendas, no finding timeslots where everyone is available. Everyone can focus their valuable time on doing the work instead of planning for the planning.
Of course every organization needs to determine how much value they might get from this sort of routine. For us, it has proved to be a highly effective way of team coordination and communication.
Deliver Working software
To deliver working software, carefully planning the scope of the release is essential. This means mapping out exactly which functions and features must be available in a given release. The scope of software projects often goes hand-in-hand with the written requirements and functional specifications documents. Many people consider these documents to be very important – and they are right. However, our experience shows that most customers – especially the end-users in customer organizations – don’t care all too much about these sorts of documents. No matter what words are used to describe it, nothing can replace a good, usable product.
It is the product that proves to the customer that we can really serve their business needs – not a project plan, not a slide deck, not a FSP, not an audit report. So we deliver working software to customers in order to demonstrate what we build.
Here it is important to remember that deliver is not the same as release. In a highly-regulated environment, our customers have good reasons for not putting each delivery directly into their own production. However, we still can use our iterative delivery cycles to allow everyone to evaluate and learn from the growing product. For this, we have established a customer collaboration process where we regularly deliver product increments to customers, collect their feedback and act on it.
My next post will cover how we go about responding to change.
Click here to read part 1 of the series.