‘A day in the life of...’ articles typically go something like this, “8:02: my day starts with a walk over Waterloo Bridge. A flat white later and I'm ready to begin. Some quiet minutes to check emails before studying the wall. Now I'm prepared for the stand-up at 9:40...”
Such diaries are often pointless and mostly boring. Perhaps you’ll agree it’s more informative to read about the key functions of delivery managers instead. Stuff they do each and every day.
What is a delivery manager?
A delivery manager guards the team’s time, to ensure continuous delivery is possible. Team time is precious time.
Developers and other team members are capable professionals in their own discipline, self-organizing and cross-functional. But teams can only complete sprint tasks timeously when they are unhindered. The delivery manager is there to remove any and all things that are hindering or ‘blocking’ them, so the team can deliver the product.
We use a mixture of agile techniques at GDS, borrowing heavily from Scrum to organise teams and sprints. In Scrum the delivery manager plays the role of the Scrum Master. The Scrum Master is a kind of ‘servant-leader’ (read that with a big ‘S’ and a little ‘l’), someone who enables the team by removing impediments and building an environment people can work in effectively (things as uncomplicated as ensuring everyone has a space to work and a wall to stand up in front of, on which to monitor progress).
Other servant functions include planning for sprints and organising retrospectives. The delivery manager should also help other product teams and stakeholders to understand the work being done, as no team is an island.
These jobs are neatly summed up by one of the twelve principles behind the Agile Manifesto: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”.
All stand up
It’s the daily stand up where the little ‘l’ in leader comes in. Delivery managers or scrum masters will facilitate a daily stand-up and make sure everyone can make it, but it’s the team who self organise. These meetings are for the team talk to one another, not address the delivery manager - some say it’s the wall that should do the talking, and I agree.
‘Help’, ‘support’, ‘guide’ and ‘facilitate’ are used deliberately. The reason for delivery managers is to manage the delivery of the product, not individual team members. Big Servant, little leader.
Stand ups happen at the same time each day usually in front of ‘the wall’, which Emily will tell you more about next week (EDIT: you can read that now). Daily and at the same time because, as is recognised in another of the twelve Agile Manifesto principles: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Daily meetings ensure that happens. At the same time, so that team members, stakeholders and other interested parties know exactly when the meeting will take place.
Another of those principles states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. The team also meets daily so that product work can be reviewed. Regularly. And direction changed if needs be - that’s why it’s agile.
Finally, why stand up? So the meeting is brief!
Each day is different
Every day the delivery manager is both Servant and leader to the team; guardian of its time, protecting its ability to deliver.
Creating the right environment is important and daily meetings in front of the wall are core. Here the delivery manager ensures the team has wall space for the stand up, but to repeat this important point again, the team is responsible for conducting it. We delivery managers enable the work, we don’t impose how it’s done.
6 comments
Comment by The role of the agile wall at GDS | Government Digital Service posted on
[...] Mark mentioned in his blog post last week, daily stand ups at GDS take place in front of the team walls. The walls are a great focus for the [...]
Comment by Tim Manning posted on
It's important to acknowledge the general principles here, for the wider public sector, or business as a whole. Theory Y, rather than X. The role of management is to enable. It goes way beyond Agile and digital services. May DGS be an incubator, nestling in the heart of government 🙂
But don't you now come under Procurement ???!!! Or have I got that wrong.
Comment by David posted on
Very interesting. Could you expand on how this works where the 'team' is a virtual one spread across geographically dispersed sites where it just isn't possible to all stand up together (and we don't have the technology that enables virtual stand ups).
And how do you mitigate against micro-management by the more senior people (the control freaks) who arent capable of following the Agile manifsto that says "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”?
Comment by Mark Stanley posted on
Ah that's a tricky one, but have you tried using Skype or e.g. Google+ hangout? It's really important that face-to-face conversation happens every day. Technologies like these and video conferencing kit at least allow a team to see one another and 'stand' in front of a virtual wall. The wall could be wheeled into a video conference room for example and the facilitator could move the cards along it...
To answer your other question, the benefits of Agile need to be sold to the micro managers. Often those people are nervous about things they don't understand or see. So give them more visibility. Invite them to participate in the stand-ups, but remind they are chickens not pigs! Benefits of Agile include quick delivery, motivated (ergo hard working) people and continuous improvement. Even control freaks will like that! Most importantly the delivery manager must shield the team from that micro management. Being guardian of the team's time involves protecting them as best as possible from silly control freakery.
Comment by Ian Smith posted on
one way to help the micromanagers gain some confidence in the process is to ensure lots of demos of the work, from the developer (and indeed, at their workstation) to the m-manager.
this enables both people to start knowing and trusting each other, being able to see the progress 1st hand and to have the chance to discuss options, solutions and suggestions before the story even goes to the testers.
try it, i've never seen a m - manager not get enthused, start to really become one of the team and start to really 'get' the value that Agile can give them.
Comment by Gerry posted on
The manager is not a servant leader, a competent manager - is the first violin in the orchestra. It controls, so - creates.