LMAX Exchange
Building great stuff fast
I’ll be writing some posts over the coming weeks about how we run our technology department including the processes and procedures we use to keep moving fast but continue to work within our regulatory constraints and the demands we put upon ourselves for operational excellence. This post will be covering how we get things done in IT using an agile mentality with minimal process.
The People
Before talking about stories, iterations and retrospectives (processes) or boards and cards (tools) let us stop to consider the people. You’re gonna find it hard to get anything done fast if you don’t have the right people to suit your organisation, technology and working practices. What you will probably find, in most successful technology companies, is the generalist, the Guy or Girl that can do nearly everything themselves if required and can work in small teams to deliver large pieces of work removing their own blockers or at least succinctly commuting the blocker to somebody else to remove it for them.
Before talking about stories, iterations and retrospectives (processes) or boards and cards (tools) let us stop to consider the people. You’re gonna find it hard to get anything done fast if you don’t have the right people to suit your organisation, technology and working practices. What you will probably find, in most successful technology companies, is the generalist, the Guy or Girl that can do nearly everything themselves if required and can work in small teams to deliver large pieces of work removing their own blockers or at least succinctly commuting the blocker to somebody else to remove it for them. Ideally, the people focusing on the building of stuff should be split away from the people running stuff, move them away from interruptions, let them focus on building. We have people highlighted as interruptible and strategically placed to stop the walk-ups towards our build team. An obvious warning, splitting teams could silo knowledge so it is important to rotate people through your different teams (run/build). I should mention here that we don’t use project managers, we give everyone a chance to run project teams, and this works well for an organisation like ours.
Lets be clear about what we are building
We encourage our engineers to start building as soon as they can but the first step is to create our lean stories. Don’t get bogged down in too much detail, come up with your plan, get your approach in place and some of your tasks into cards and kick your story off. We use Kanban, so any build work will be defined in a card and broken down into deliverable tasks that complete the card and ultimately the epic or story to which they all relate. There are plenty of tools out there to help you manage cards and stories, Leankit is our weapon of choice.
We encourage our engineers to start building as soon as they can but the first step is to create our lean stories. Don’t get bogged down in too much detail, come up with your plan, get your approach in place and some of your tasks into cards and kick your story off. We use Kanban, so any build work will be defined in a card and broken down into deliverable tasks that complete the card and ultimately the epic or story to which they all relate. There are plenty of tools out there to help you manage cards and stories, Leankit is our weapon of choice. Kanban works well for us and allows management of our workload effectively, using this approach ensures the optimal level of work is in play and blockers (something slowing down the work) are not holding us up.
Cycles
We work in iterations (the same ones our Developers work in) of two weeks with daily stand ups to keep everyone up to date with what is going on and to highlight blockers. The short interactions are important as it affords a quick feedback cycle, if we hit a blocker or need to change direction it is not too disruptive or costly. Our approach is not perfect, it is important to improve, so blameless retrospectives are common place at the end of stories, iterations, releases or anything that would benefit from them.
We work in iterations (the same ones our Developers work in) of two weeks with daily stand ups to keep everyone up to date with what is going on and to highlight blockers. The short interactions are important as it affords a quick feedback cycle, if we hit a blocker or need to change direction it is not too disruptive or costly. Our approach is not perfect, it is important to improve, so blameless retrospectives are common place at the end of stories, iterations, releases or anything that would benefit from them.All this sounds great you ask, its all agile and fast paced you say, what about your processes….
Of course these people building stuff need to change or interact with production systems at some point but we will cover that in another post.