Wardley Mapping Mondays – Development Doctrine Posted on March 9, 2020March 9, 2020 by Cory Foy Happy Mapping Monday! Today’s #mappingmondays video continues the series on Doctrine looking at the nine principles of Development. If youâ€™re interested in finding out how to apply this to your organization, donâ€™t hesitate to reach out via Twitter or email hello at coryfoy dot com! Your browser does not support the video tag. Links: Wardlepedia Doctrine Patterns Dan Ward’s F.I.R.E. book Connected Car Strands Driver Agile Manifesto XKCD Comic on Standards Defending Commoditization post from LAKC Transcript: Happy Monday! Iâ€™m Cory Foy, and welcome to this weekâ€™s Mapping Monday. Last week we introduced 6 categories of Simon Wardleyâ€™s doctrine – Communication, Development, Operation, Structure, Learning and Leading, as well as covered the four doctrine principles in Communication – Be Transparent, Focus on High Situational Awareness, Use a Common Language and Challenge Assumptions. Communicating is critical for every organization, especially as we figure out what we should be doing – our gameplays and strategies, and hopefully you found some great ways to integrate these into your organization. The act of figure out how to get to what we should be doing is the focus of this next category of doctrine – Development. Itâ€™s a big one, both in impact and number of principles. What are Simonâ€™s doctrine principles for Development? Know Your Users, Focus on User Needs, Think Fast, Inexpensive, Restrained and Elegant, Remove Bias and Duplication, Use Appropriate Methods, Focus on the Outcome – Not a Contract, Be Pragmatic, Use Standards Where Appropriate, and Use Appropriate Tools. Whew! Letâ€™s not waste any time. Knowing our users is something driven into every business. But do we really know them, or are we making assumptions about who they are and how they use the things we create? For example, building a car rental that people can reserve without needing to talk to anyone sounds great. Until you donâ€™t think about what happens when they drive that car into an area with no cell signal and it shuts down. Iâ€™ll also mention that in knowing our users we should also understand the bad with the good. We might think of software which can track and lock down our devices as helpful – until theyâ€™re used in abusive situations. So spend time with them, in their actual environments. And build diversity of opinions and people in your teams to challenge assumptions you make about those users. Once we have an understanding of our users, we want to focus on their needs. In a Wardley Map, User Needs are the anchors we use for all down level mapping. However, we have to be prepared for two challenges. The first is that different users may have different, conflicting needs. We need to be prepared to balance out those approaches. The second is that, when we talk about components in Genesis and Custom Built, user needs are uncertain. Weâ€™re still in a discovery process. So weâ€™ll see more rapid evolution of them as we learn more from them. As we focus on those needs and start to think about how to meet them, we want to be in a mindset of Thinking Fast, Inexpensive, Restrained and Elegant. This term – known as FIRE from Dan Wardâ€™s book – is about having a bias towards action, in a lightweight way that stays focused on the need weâ€™re solving but is high quality enough to be built on top of. This is a good place to learn more about Extreme Programming – the idea of working small, fast and with high quality, in a way that can be evolved. Or invoking the acronym I heard most from Ron Jeffries – YAGNI – You Ainâ€™t Gonna Need It. And when we donâ€™t need it, we want to remove it. The doctrine principle of Remove Bias and Duplication is a strategic look at YAGNI. We want to share maps, collating them and looking for both duplication and bias – specifically around gameplays that donâ€™t match the evolutionary lifecycle. For example, if something is a commodity, we likely shouldnâ€™t be building it – though as Cat Swetel says, sometimes that can be an advantage and we should be very clear that weâ€™re diverging from the norm and be prepared to defend why. Using Appropriate Methods is perhaps one of the most powerful statements in its simplicity. While weâ€™ve seen a big shift over the past 15 years towards agile methods being the norm, that doesnâ€™t always mean we should approach it that way. In a Genesis phase, rapid discovery doesnâ€™t fit well into Scrum like models, though it can be a good container for discovery if the cycles are short enough. On the other hand, when we have an implementation of a utility component, itâ€™s likely that a sequential process will work very well, and what weâ€™re looking for are more Six Sigma ideas of waste and delay reduction. There is no magic solution, and you should understand what youâ€™re trying to accomplish. And when we talk about what weâ€™re trying to accomplish, we run into our next doctrine principle – Focus on the Outcome – Not a Contract. This fits in to the Agile Manifesto notion of Customer Collaboration over Contract Negotiation. We should look for ways to work towards delivery valuable things that mean the needs of the user value weâ€™re discovering. We should be open – on both sides – to finding better ways of working together, knowing that contracts arenâ€™t necessarily evil – if we find the ones that fit what weâ€™re trying to deliver. When we are trying to deliver, we want to Be Pragmatic. If we can leverage off-the-shelf components, we should do that. Know what your core competencies and wins are – and focus on them. As Simon says, â€œAlways challenge when you depart from using something that already existsâ€. Along with being pragmatic, we should Use Standards Where Appropriate. If we have components we can build on top of, we should build on top of them. If thereâ€™s a standard, we should try to use and improve it, or weâ€™ll run into the notion of just adding to the standards and getting bogged down in supporting things which donâ€™t further our goals. Finally, we want to Use Appropriate Tools. This means looking at our situation and ensuring we have the right level of awareness. If weâ€™re making a financial bet, we should have financial models. If we think weâ€™re outplaying our competitors, we should be able to show the map of the landscape validating that decision. Thereâ€™s no reason to just start driving and hope you get there – even in a brand new startup you have customer discovery and validation youâ€™re driving towards, and you should focus on getting those hypotheses answered. So as you go to develop this week, start asking yourself how your doing. Do you know what your users need? Are you thinking in small increments that can move quickly? Are you using the right method for the agility you need? And are you making the most of your investment in time by removing bias, duplication and adopting standards? Thereâ€™s always more we can do, and it doesnâ€™t have to be big! Iâ€™m excited to hear how you all make it happen. And if you have questions, need help, or want to let me know how itâ€™s going reach out on Twitter at @cory_foy or via email at hello at coryfoy dot com. Until next week, letâ€™s build something great!