to realise that what makes me 6ck and get’s me out of bed in the morning isn’t so=ware development as such, not even agile tes6ng or BDD, it’s about helping teams flourish and thrive and be themselves. So I’m all about collabora6on. But collabora6on is hard. When you come out of your Scrum cer6fica6on training you kind of come out thinking “OK – now I’ve got this post-‐it note I need to go and have conversa6ons and collaborate”. I work with teams who find that difficult, which poses problems -‐ because effec6ve collabora6on is absolutely crucial to the success of our projects. As well as collabora6on, I’m also convinced that one of the biggest challenges that organisa6ons face when implemen6ng Agile, is how to do the right amount of analysis and design, & knowing when to do it. So today we’re going to examine and discuss how much is the right amount of upfront work, and when to do it, & how taking a collabora6on-‐driven approach can help you get the balance right in your own team. I’d like to introduce you to a couple of characters you might have met before…. 1
name, Umberto likes to do all the work up front. He likes all sorts of diagrams and massive data models. Umberto loves work in the solu6on domain and he likes to decompose a solu6on in its en6rety before a single line of code is wriUen. So let’s now take a look at Umberto Upfront’s nemesis. Nancy Nimble 2
she just can’t wait to get the next task off the backlog. Nancy nimble is super-‐agile and her team works with really small units of work and limited documenta6on. She’s a great team player -‐ She’s always on 6me for stand up mee6ngs, always keeps her update to 45 seconds and makes great notes on her Jira 6ckets. She doesn’t really do analysis or design, she just focuses on building so=ware and defers technical decisions as long as she can. So as you have probably gathered, Umberto Upfront and Nancy Nimble both have issues. 3
The Business some6mes get cross with Umberto Upfront because they find some of his documenta6on difficult to digest and they don’t always understand the terminology he is using. So they miss stuff when they review it & by the 6me they see it working there’s load of costly rework to do. Another issue Umberto has is that all of his technical vision needs to be delivered for the Business to get any of the value. And he doesn’t really know where the value lies in his solu6on because he hasn’t spent any 6me understanding the real business domain and the issues they face. And even though his solu6ons are carefully architected, a small business change some6mes leads to a massive technical change with a huge lead-‐6me for delivery. 4
Umberto, more like gravel than a great big boulder. She’s confident working with minimal documenta6on and she can let the design kind of take care of itself. There are hundreds of user stories on the backlog, but she can’t see the big picture and she doesn’t understand the technical vision. Nancy’s team deliver at high velocity but they have no idea if their solu6ons are actually delivering any value to the business Some6mes Nancy feels like she’s building a great big ball of mud and she’s spending more and more 6me trying to refactor her way out of it. She’s beginning to feel overwhelmed. 6
red is the amount of analysis and design effort. As you can see from this Umberto does all of his at the beginning of a project and releases in one big bang. 8
minute that Umberto and Nancy came to Agile in the City and began discussing their differences. One thing led to another and they had a love-‐child ’Agile Angelina’ She s inherited Nancy and Umberto’s best quali6es. 10
to be easier to know this in the waterfall days. You had a requirements document and then specifica6on and design documents, and this process of analysis and synthesis happened in between. We need to do enough up front work to be able to see the big picture and make good decisions, but be able to start really small so that we can get to market quickly. 12
big boulder and the gravel. A huge project versus a 6ny story. But changing from waterfall working to itera6ve delivery is not as simple as turning everything into fortnightly sprints delivering user stories. There are many other heartbeats and itera6ons that we need to consider. 13
which I developed with a colleague Pete Buckney a few years ago. It represents Collabora6on driven development. We have different layers of collabora6on in our organisa6ons At each layer there are different ques6ons to answer and different challenges. There are different audiences working with different levels of detail, and the audiences are different sizes. In our Umberto and Nancy example, the project is the great big boulder, delivered in one big bang with lots of people involved and the feature in the middle is the 6ny piece of gravel where only a few people understand the details. 14
These layers represent the process of decomposi6on that Umberto went through as he broke down the boulder into smaller bits. But instead of smashing at the boulder with a great big hammer you need to go a=er the value in a much more deliberate way. If you pay more aUen6on to these different itera6ons and heartbeats, these layers of decomposi6on and collabora6on you can be more effec6ve and accelerate delivery. 18
move from one layer to the next we have some up front work to do. We need to pause at each of these layers to make sure we know which direc6on we’re going in and why. We need to be aligned on our technical vision and to understand the scope and risks of what we’re taking on 20
Design thinking is made up of 2 parts, divergent thinking where you start by examining op6ons, crea6ng choices and then convergent thinking, where you make choices. These 2 sec6ons are also synonymous with analysis and synthesis. So analysis is where you break down the whole and examine it and then synthesis is where you turn that into a way forward. I also think there’s a rela6onship here between looking at the problem domain and then moving into the solu6on domain. In the olden days we went through this process in silos – Umberto would have done it all by himself before wri6ng his 987 page document…. But if we do this collabora6vely, this is where the magic happens. as we collaborate and explore the as is, look at customer goals and examine risks, we’re able to come up with a to be solu6on, with risk mi6ga6ng ac6ons and with a clear technical vision as to how to proceed. Which is really important if we’re trying to extract the value in the leanest way. We all know now (par6cularly in the DDD community) the benefits of collabora6ng – domain experts and technical experts. Raising the level of shared understanding, avoiding costly misunderstandings and making good decisions. 22
need to do some design thinking. At the beginning of each project, at the beginning of each release at the beginning of each itera6on and at the beginning of each feature. The audiences might be different and the techniques we use might be different. For each of the collabora6on layers we need to understand the high level landscape, the goals, the risks etc before agreeing on a concrete ar6cula6on of what success looks like, and a target for delivery. 23
years I’ve been looking a lot at the benefits of collabora6on and par6cularly which techniques help at different layers. Here are some techniques you might be familiar with Each of these techniques has divergent and convergent aspects Lean Canvas Impact Mapping Story Mapping OOPSI Specifica6on By Example 24
So can you see how if you understood the itera6ons and heartbeats in your own organisa6on, you might be able to plan specific collabora6ve ac6vi6es around tailored to your context. So it would depend how regularly you were able to do releases and how greenfield you were etc. 25
– what about all the other types of tes6ng? This model also reflects different levels of tes6ng and how different techniques and tools might be appropriate at different levels. How does that look on the 6meline for Lean -‐ Agile Angelina? 27
as con6nuous and collabora6ve as possible, by using techniques like specifica6on by example we’re trying to eliminate handovers to that there is no specific acceptance tes6ng needed, it just works as expected. But depending on your context and heartbeats in your organisa6on there might be specific ac6vi6es required that 6e to the end of an itera6on. Where you need things to be stable. For example to run representa6ve performance tes6ng or lock down regression tests. 29
of detail & it might help us recognise for these different layers what appropriate artefacts we want to keep, and who’d interested in them. There’s also a kind of inverted tes6ng pyramid in here – Anyone heard of Mike Cohns Automated tes6ng pyramid? If we understand more about what ques6ons we are trying to answer and what level of decomposi6on we are at, maybe we’d be beUer at choosing appropriate collabora6on and tes6ng techniques to help us answer those ques6ons. And we might even be able to structure our projects around these heartbeats and collabora6ons rather than trying to force a one-‐model fits all approach. 30
hoping you might try a collabora6on driven approach in your own teams and I’m keen to hear if it helps you get the balance right between up front work and in-‐itera6on work. It might help you deliver value faster like Agile Angelina and stop you gefng squished like Umberto or Nancy 31
Jenny Martin
jennyjmar
reverentgeek
rmw
skipperchong
carmenhchung
keathley
productmarketing
clairelew
thoeni
jcasabona
