Talk: Mob Programming for Continuous Delivery
Speakers directory
Speaker:
David Legge
Talk description
Title:
Mob Programming for Continuous Delivery
Short synopsis:
Continuous Delivery (CD) emphasises releasing value incrementally and as often as possible. Trunk Based Development, Single Piece Flow, and Mob Programming can be seen to flow naturally from CD and mutually support each other as practices. Mob Programming can also reinforce the togetherness of the team, increasing effectiveness further towards being a High-Performing Team. This session will look at how they’re inter-related, the benefits of adoption, but also the pitfalls.
Max size: 500 chars
Long synopsis (optional):
Continuous Delivery (CD) says that you should be able to ship your software after every single commit (or push, in today’s parlance but at least once a day) and that automated processes should support that and be able to validate that that is so. To be able to do this, it is pretty much requisite that you use a practice called Trunk Based Development, whether you commit directly to Trunk (also known as Master) or just limit the life of branches to a day. From the world of Lean, comes the concept of Single Piece Flow, where Work in Progress (WIP) is limited to One task or ‘thing’ at a time. This naturally fits with Trunk Based Development as then there is no point in a branch in the first place (there is no other work to conflict with). And if you’re using these practices, then why not consider (or even just do) Mob Programming? After all, if everyone is working on the same thing then what else are they going to do? Team Work There are side benefits to adopting Mob Programming; as the team will be working more closely together the team is likely to become more of a closely-knit team, more likely to become Highly Performing, as defined by Katzenbach & Smith (1993). There is a danger that in the context of working more closely with each other, tensions begin to surface, but they were likely there already with the dysfunction hidden, and the team had work arounds that reduced their effectiveness anyway. In this sense, the resolution will be quicker. It is also important to note, that you people are likely to require different levels of support to meet them where they are; the techniques described here are radically different, indeed heretical, from accepted practice 20–25 years ago. Some will take to them like a fish to water, others will need support and guidance. And that’s not just the managers giving up what they consider to be “Control”. Getting the team to work better together is important because software systems anywhere beyond the trivial are best produced by a team, not by individuals ploughing their own furrow. A number of organisations call this out: “The Unit of Delivery is the Team” — Government Delivery Service (GDS) “We do our best work in teams” — Redgate Partly this is because of the range of skills involved but also the classic Silo problem — if people on the same team aren’t talking to each other enough, the solution isn’t likely to work well as a whole. Just as Kent Beck described the practices of Extreme Programming as mutually-reinforcing, the set of practices discussed here do so too: If you’re doing Mob Programming, you naturally have a WIP of ‘1’; all the team have been involved so there’s little point in pre-commit Code Reviews or indeed Pull Requests; which means branches are not required — Trunk Based Development. And Trunk Based Development feeds in to Continuous Delivery, so having automated the release process over time, when a change is committed (and pushed), assuming the tests pass* then the software is released. With the team working closer together on a constant basis, the team is likely to improve over time, reinforcing the effectiveness of all the practices further. But remember, this may make some feel uncomfortable, and like with any change, they will need support. *= This can be a big assumption.
Max size: 5000 chars
Tags:
Speaker directory:
Listed in directory
Not listed
Speakers directory