Serverless Craic from The Serverless Edge

Serverless Craic Ep45 Bringing Mapping to your Org

Bringing mapping to your org.

We are doing a wee series on Wardley Mapping, with some practical items. The last two episodes were: 'Wardley Mapping 101' and 'Can Wardley Maps Predict the Future?'. So I thought it would be good to answer a common question: 'That's a cool technique, but how would I do that in my work?'. If you follow Simon Wardley, on Twitter, and you've started experimenting with Wardley Mapping, we tell you how you to bring Wardley Mapping to your place of work.

We talk about using the Northstar exercise to facilitate mapping. And about finding like-minded people to sit and practice with. There is a way of talking about mapping. You're better to start with the outcomes. And then see if people are interested to get back into the map, as a way of sensemaking complicated areas. It's great to make sense of something and share that thinking with peers. And once you get into that language, you open up a common way of thinking and the idea of evolution to access things you want to talk about it.

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge

Serverless Craic Ep44 Can Wardley Maps predict the future?

Can Wardley Maps predict the future, is our topic this week.

In our last episode, we talked about Wardley Mapping. We did a 101 last time, explaining the basics.

One of the things that we say is that Wardley Mapping is a superpower that helps you predict the future. What do we mean by that? It's like a fortune teller. But it doesn't tell you when exactly something's going to happen. It's the state of mind that it puts you in. We run through a couple of examples, to demonstrate how we've done it in the past.

1. Conversational Programming
2. Generative AI
3. Well-Architected
4. Serverless
5. CDK (Cloud Development Kit)

If you have good situational awareness, you can wait until the appropriate time. You don't have to go off and waste energy, cycles and money trying custom build something. Wait three months and you'll get what you're trying to achieve.

When you map this stuff out, you can start to think about how your sensing engine can get intel on whether these things are going to happen or not. There are lots of different ways you can do that. Like following Twitter feeds and looking at blogs. And looking at who they're hiring and following the industry experts. They're points of information that can help you see how things will evolve. To predict the way things are going to go. There are multiple levels of maturity in your map and how you think it's going move and where the evolution is going to happen.

Wardley Mapping can be used to predict the future but it's not going to give you an exact date. What it can do is give you an example of this is what it will look like if it happens. So you prepare yourself for when it does. And then when the press release comes out, you're like, boom, we're ready. We saw that coming. So it's the no 'surprise approach' to building situational awareness. 

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge

Serverless Craic Ep43 Wardley Mapping 101

Wardley Mapping is a core part of our book: 'The Value Flywheel Effect'. And it's a topic that people always ask about it. It's a difficult thing to learn. We've spent many years thinking about it, stumbling around, and then practicing. So we figured we would do a quick series on Wardley Mapping.

We have spent almost 10 years mapping, give or take. For me, it has been an absolute game-changer. One thing that's come along recently is the Wardley Mapping canvas by Ben Mosior @hiredthought. It's a nice canvas with six steps on how to map. Before I started using the canvas, I used to find that maps could get big and go off in 60 different directions.

Purpose and scope are the first two steps. And then the third one is users. The fourth one is user needs. And then the fifth step is the value chain. It can be difficult to keep things abstract. And not go too deep. But it is good to be as abstract and high-level as possible, even just to start to get something down.

Once you have the value chain of the user, a need, and a couple of dependencies, that's when you then bring it across to the map. And I would usually put them in the middle of the map. Drop them all into Product, to get you started. So you've got them all in a vertical line on your map and canvas. You start moving different components from left to right. And you might work out that one of the dependencies is Commodity or Custom. And you can see how that interaction goes. That's when you start to add in dependencies because you've got more room in the map.

This is where the conversation really starts to kick into gear. And this is where people start to challenge each other's context and think about where that component belongs or what's missing from the map. So it makes for a very collaborative exercise.

If you are planning a mapping session, you need to be a good facilitator. If a participant feels something is in the wrong place. Don't say no, you're wrong. It's in the right place. You want the individual to explain why they think so. If it is something that's blatantly just them for raising the challenge. The last thing you want is an unsafe environment where nobody wants to speak.

It doesn't need to be too fancy. You might map for an hour. And if you're facilitating, five or 10 minutes off the hour, you take a couple of notes, If someone says we should move that component from x to y that's an observation, You're not committing to do it but just taking a few observations. Always just keep it simple.

So here are a couple of really good links. We talked about Ben Mosier @hiredthought. He's got a brilliant site called LearnWardleyMapping.com. Ben created the Wardley Mapping Canvas, which is on Creative Commons Open Source.

Simon's also got a couple of links. There's a site on GitHub called Awesome Wardley Maps. It is by John Grant on List.WardleyMaps.com. Simon's original book is on medium.com/wardleymaps. Simon's content is great but deep. 

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge

Serverless Craic Ep42 ServerlessDays Belfast

ServerlessDays Belfast was on the 28th of February. It's a volunteer, community, and not-for-profit event.

We had a bunch of sponsors: AWS, Bazaarvoice, EverQuote, G-P, Instil and LibertyIT.

Our organizers are me, Gillian Armstrong, Garth Gilmour, Peter Farrell, Julie Sherlock, and Treasa Anderson. We had 12 speakers, and over 260 attendees from over 40 companies. But most excitingly we had it at the Game of Thrones Studios Tour.

The theme was 'The Reality and Fantasy of Serverless, Building Serverless Teams and Making it Real'.

Phil Le-Brun, who is the Director of the Enterprise Strategy Team for AWS launched the event. And give us a perspective of what he sees when he is speaking to the leaders of the industry.

IT Revolution was very generous to sponsor and provide 250 of 'The Value Flyweel Effect' books.

Julian Wood gave the Keynote. Even though he works for AWS as a Serverless Developer Advocate, he gave his opinion on where he sees the industry. I thought that paired really nicely with Mattie Wilson from Instil. He gave a brilliant talk on an engineering team going through the journey from a cloud application to a serverless application.

Sheen Brisals from The LEGO Group, as ever, gave an absolutely brilliant talk about Lego's journey. Going Serverless to EDA and the team topologies of an event-driven organisation. Sheen is an absolute master.

Jonah Andersson did a talk on the .NET stack. And Conall Bennett and Roger Moore did a talk on CME Group's move to a Google tech stack. Craig McCarter talked about large-scale serverless. And I took comfort from hearing about a team that's doing something financially significant at a massive scale. And they're pushing those limits.

I really enjoyed the talk by Anna Carlin and Emma Patton from Aflac Northern Ireland. They called their talk: 'A rookie journey of discovery and learning'. So they came in as grads and basically built a serverless system. And Chintan Parmar's Dunelm story was really interesting about Dunelm's e-commerce site because it's quite an unknown story. Most people had no idea that they had a whole big serverless ecommerce site.

Ben Ellerby from Aleios closed out with his Serverless Staircase Framework. I've been a fan of Ben's for many years. He's an AWS Hero. He's brilliant and very experienced. And he's worked on a lot of serverless projects. That is what his company does. So he's got lots of war stories from doing this with real customers.

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge

Serverless Craic Ep41 Serverless Espresso

We've been talking about AWS re:Invent over the last few episodes. But one thing that we haven't talked about is Serverless Espresso.

Serverless Espresso is a pop up coffee shop that allows you to order coffee from your phone. In the Expo Hall at the AWS Summit, they have a Barista setup. And you walk up to a QR code with a screen in the background. So you scan the QR code and enter in your email address. And up pops a menu. If you select an americano, espresso or other type of coffee, it kicks off an event driven flow. It uses an event driven service under the hood and pops up in the screen as a number. And then the Barista takes the number makes your coffee and gives it to you.

But what's happening in the background is a whole load of orchestration and choreography run events. And as they've been using it as a way to explain serverless event driven architecture. Event driven architecture can be hard for people to conceptually wrap their heads around. So making it real through ordering coffee. And showing how to tie a coffee process and an event driven coffee ordering system makes it real. It demystifies it a little bit and removes some of the thinking that event driven architecture sounds really hard. This makes it more approachable.

It stitches together a lot of stuff that we've been advocating for, in a way that makes sense. By using AWS Step Functions, EventBridge, Lambda, API Gateway, S3, DynamoDB and Cognito. It brings to bare a lot of great technology that we are advocating for in a way that's practical and easily consumable. And the Serverless Espresso workshop is very good for walking you through the steps about why you're doing what you're doing. And how do you do that, set up rules and set up everything. It's a great way to get hands on with event driven architectures and serverless in a practical way.

There are two myths in this space that AWS are trying to dispel. We first started talking about event driven architecture 13 years ago. We had the idea of doing something but back then it was really difficult, because we didn't have a lot of support. So we had hard problems to solve technically, because the foundations weren't there. That is the first myth of being a hard thing to do.

The second myth is that people think of serverless as just writing code and functions. It's actually more like an event driven architecture. It's events firing off activity and not a call stack. So it's a lot easier to build full event of architecture than it would have been years ago. The technical challenge is not as bad as you think it is.

What I like about Serverless Espresso is the simple interactions. You order, it goes to the barista who makes the coffee, and he gives it back to you. There's one interaction. Normally when ordering a coffee, you talk to a waiter, the waiter talks to the barista, and the barista talks to someone about milk etc. There can be six or seven people in that flow. It causes confusion. In a company, if a business process is owned by six or seven teams, even across two or three departments, it gets messy. If a single team builds for the customer directly and there's no one else, it's usually pretty clean. Because you can see everything needs to happen. It gets complicated if the business processes is split over several teams and departments.

Serverless Espresso Lab is good, because the opinions are out there and you add on your bit, which is your business process flow. It goes back to our book The Value Flywheel Effect. And the first phase of the value flywheel which is clarity of purpose. Who is the customer and what is the business flow that we're trying to build? And let's have a good debate on how we are going to do that.

When you get to the technical side, that opinion is already there. And you can focus on getting the orchestration correct. Because you know that a lot of that underlying stuff is pretty much solved apart from making it behave.

Look at the Serverless Espresso Lab on workshop.serverlesscoffee.com. Or search for Serverless Espresso. And big kudos to the AWS Serverless Developer Advocate team. They're mostly on serverlessland.com. Thanks for listening.

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge

 

Serverless Craic Ep40 AWS, What’s New?

AWS, What's New?

We are post AWS re:Invent. To sum up, it was about the next generation of cloud focused on delivering value quickly by removing barriers to business adoption and enablement. This year there was a solution focus. Previously there was a focus on migration.

On Day 1 SiliconAngle published an article called "AWS chief Adam Selipsky hints at the next-gen cloud". He looks at classic cloud versus next-gen cloud. Classic cloud is infrastructure as a service and the platform of the cloud. And next-gen is looking at ISVs and true cloud. It's about using the cloud to power you business journey. Which is exactly what we talk about in The Value Flywheel Effect!

AWS are market leading for low level cloud primitives. If you want compute, get it from AWS. It has been this way for the last 15 years. But next generation cloud is about business capability. When you do Wardley mapping correctly, cloud primitives are pushed to the right to become commodities. You then look for the business capability you need. That's exactly what the value flywheel effect is. You look at your business strategy and decide what you need to use versus what you need to build. You use technical strategy to build the right thing. And you're not stuck using something that someone else is going to expose as a SAS.

AWS are consolidating core primitives and opening up the solution space to help customers do interesting things with them. And you can see that with the partnerships they are setting up with other big companies like Mongo and CloudFlare. It's becoming an ecosystem. There has been a lot of criticism of AWS in previous years with regards to their developer experience. Code catalyst is a big move from AWS to try to make that more seamless. It stitches together a number of things that have evolved over the last while. But it's really about enabling product teams to rapidly deliver value in a way that doesn't blow up three months down the road. It's an accelerator for teams coming on to the cloud or into serverless. And it is frictionless developer experience. In our book, it's the next best action phase of the value flywheel.

Well architected featured heavily at AWS re:Invent. AWS are continuing to develop well architected and build it into things. And they are continuing to develop patterns, blueprints and accelerators.

Security also featured with verified permissions. It's out in pilot at the moment but it has potential to make a big impact on managing fine grained permissions and doing identity authorization properly, especially if you have a custom app. Most companies of a certain scale have their own custom built version of this. So they have spent a lot of time and effort. But you need to acknowledge that you are ahead of the curve. And have the courage to delete your custom built solution. Deleting code is a good idea!

There's a bunch of step function stuff out. I particularly like SnapStart which gives you the ability to drop large java applications into lambda. And performance time is through the roof. You can draw up an average Spring Boot application into lambda and you will get similar performance but it's way cheaper to run. It's not just java, there will be other languages as well. It's snapshotting a virtual machine and making it available on demand, which is a big deal. There are some caveats to it. But it's addressing the myths around cold starts and using lambda for high performance workloads. It's also interesting from the perspective of having large framework oriented services and leveraging those for femoral compute.

At AWS re:Invent, the message I was hearing loud and clear is that enterprises and large companies have moved to the Cloud but need help doing the next piece. They need help creating their value flywheel. They've done the move and now need to go to the next stage of modernization or next-gen. So that is good news for our book 'the Value Flywheel Effect'. Because we tell you what to do. I spoke to a lot of people who were trying to do a serverless transformation. And trying to create their value flywheel. There's definitely a lot of demand for more advice and guidance. And stories of how companies have done this.

The ecosystem has never been better for applying the value flywheel effect now. A lot of the challenges we had in the past have started being addressed. So it should be easier for people who are adopting it now to make progress. In the past, when we promoted being well architected and serverless first, people looked at us a little funny! But it's starting to permeate throughout AWS. It's an accepted term and people understand what it means. There's a lot less inertia going well architected and serverless first. Compared with what we experience six years ago. Serverless first is not scary anymore.

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge

Serverless Craic Ep39 AWS reInvent announcements

AWS reInvent announcements

In this episode we are talking about what we would like to see at AWS re:Invent. The AWS internal teams work towards re:Invent to make their big announcements. Sometimes they have announcements beforehand. But the big announcements will be on stage.

What would you like to see?

Serverless Services

An increase to the enhancement and evolution of service development capabilities and the ecosystem in general. So more serverless services coming online for items that aren't serverless and iterating to be more serverless. There's a bunch of things that people are almost afraid of like observability, deployment patterns and some of the frameworks. So make those a bit easier.

API Gateways

In service development, Private API gateways are interesting, but they could be more developer friendly, in terms of setting up, naming and managing. The edge around the environment needs to be tightened up. I don't think they have nailed the data options yet. We are seeing more enhancements around eventing capability like SNS filtering, SQS and X ray. These are things that make the serverless experience more rich and all encompassing.

Developer Enablement

That leads on to developer enablement. You need to think about developer enablement and time to value. Can you get a developer up and running with a productive IDE in the cloud? And can they start delivering value rapidly? We're seeing steps around Cloud IDE starting to emerge. I want to see what AWS does around their Cloud9 offering. So that you can go from idea to something deployed and running within minutes.

Well Architected

We are big advocates of the well architected framework. Over the last year, we've seen good announcements on well architected capabilities, systems and services coming online within AWS. I want to see a continued evolution of that. And more well architected thinking and characteristics baked into everything AWS are doing. All the way from developer advocates to patterns and code samples. Well architected needs to be better known.

A lot of people still don't know what well architected means. There is still work to do to get people to understand what well architected is and what it isn't. And have it present in the tools and not a separate thing that you need to go and do. It should just be there in your job. And there's a second thing. Some of the basic primitives are moving up a level to something more like a pattern.

Developer advocates are great at this with Serverless Land. It would be great to see some consistency in those higher level primitives. It's about fast feedback and dare I say the value flywheel. Can we get more feedback faster on our well architected status? Can the pipeline's tell us how well architected the chains that we made are. And can our IDE tell us how well architected we are? Stitching that together in a compelling way with fast feedback for the developers would raise the bar on what developers deliver into production.

That's effectively platform heuristics. I remember back in the IBM mainframe days, it was a mature platform. And you knew it so well, that they started to bake in heuristics. When you start to analyse your code there would be a heuristics to say this might be wrong. Here's what you need to do to fix it.

We're starting to see some of these elements emerge already with Security Hub, Reliability Hub and Fault Injection Simulator. It's about stitching those together like factory mode for workloads in your accounts. Tell me we're not well architected, and tell me how to fix it. There's probably an extension to that. As we enable developers I'm seeing good industry examples from new tools that have been launched. In other words here's a new feature and here's how it applies to your particular industry.

Sustainability

Sustainability is a topic close to our hearts. I haven't heard much about it this last while. More fine grained analysis of carbon scores would be useful when teams are designing and building their workloads. And getting faster feedback on a particular service and how much it is going to cost you in carbon.

What's the wacky stuff you would like to see?

I'd love to see work on APA management and API gateways. Factory mode for your accounts. How well architected are you would be really good. Instead of us having to do the reviews and do it manually. The gateways are due an uplift or enhancement. What about documentation? And how you consume information about services. We are seeing an explosion of services on the console. Is there going to be a cut down console just for your layer? Cost is always a big one. FinOps is a massive growth area with a lot of good tools out in the market. The only other one I can think about is Identity. It will be interesting to see if anything comes out with Cognito.

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge

Serverless Craic Ep38 It began with the forging of the Great Maps and Simon Wardley

It began with the forging of the Great Maps and Simon Wardley

We've been talking this week about Wardley mapping. Simon Wardley features in our book 'The Value Flywheel Effect'.

Where did you first hear about Wardley Mapping? 

I first heard Simon Wardley talking at cloud conferences about early cloud. I remember an open source conference and a 20 minute video. Simon was really funny, which actually helped. When he presented it came across as common sense. Like, why would you do anything else?

The bigger question is why were we looking for this type of stuff? Or why did it resonate with us? I think we were at a certain point in our careers. We had been engineers for a while. And we thought there's got to be a bigger picture here that we're not quite grasping. Simon Wardley started writing his book in 2016. I went to Lean Agile Scotland in October 2016. And he did the talk in person. I had seen his talk a couple of times, but it didn't really click until I sat and watched it in real life.

I've always liked the idea of a group of people drawing a diagram to understand something. I think that is really powerful. Remember, there was a time when we said we need to stop using PowerPoint! We need to get people into rooms to have conversations and working sessions.

I refined and improved my ability to do Wardley Maps through teaching. There were people who hadn't experienced mapping. Or if we had visitors or customers in the building, you'd get them into the end room with the big white wall and just start talking. You would try to teach them what a map was. And what each position meant. Or even just have a conversation.

There's another important step. You move from doing it yourself to doing it in a group environment. When you are looking at a map you are figuring it out. When you do it in a group environment, the group will ask about this and that. And that's when it really starts to click. For me, the two big things are:

1. Start with a customer need. I remember a team were stuck for six months because they didn't know who the customer was.

2. The four phases of evolution or access (Genesis, Custom Built, Product, Commodity). Get your head around that concept.

One of the other pitfalls we fell into was mapping too much detail. We went too low level. And then someone came along and zoomed us out, by saying 'you don't need those five components. Here's just one!'.

Practice, practice, practice is the big lesson here. We knew we were starting to get good when we were able to roll it out across multiple teams to map out the tech stack. They were getting value and getting excited about doing it. And we were getting lots of feedback on what did or didn't work. We were in offices and I would draw maps on the board. It was all very collaborative. But now we have the emergence of good online collaboration tools like Miro etc.

Another important lesson is that senior people just want to hear what you are going to do. They don't want to know how you figured it out. If they say why are you doing that? You can go through the map in your head and say that you've thought about it. If you say this is what we are going to do and here's the outcome, you don't need to show them all your work.

When we started mapping there wasn't much about apart from the odd presentation. Now there's lots of material out there. The community is growing. You can google and look up YouTube. And there's online conferences as well like Map Camp. Those videos are available soon as well. A lot of Simon Wardley's maps are readily available on GitHub.

A lot of the work in UK.Gov carried out by Liam Maxwell and others still stands the test of time. If you look at the UK government's digital footprint, it's still in there on freely available materials. Their work is permeated with thinking about user needs, understanding value chains and situational awareness and mapping.

For resources look at Simon Wardley on Twitter @swardley and his pinned tweet. Simon has a book: 'Wardley mapping'. He is on Medium at 'wardleymaps'. There's a whole bunch of stuff including free articles. They're fairly meaty but they're good.

John Grant keeps a list of maps on GitHub, which is list.wardleymaps.com.

Ben from @hiredthought is also at learnwardleymapping.com. And of course, our book, 'The Value Flywheel Effect' is coming to a store near you soon.

Serverless Craic from The Serverless Edge

Check out our book The Value Flywheel Effect book

Follow us on Twitter @ServerlessEdge

Transcribed by https://otter.ai

Serverless Craic Ep37 What is Engineering Excellence?

What is Engineering Excellence?

We are chatting about two things that I think are quite interesting: engineering excellence and well architected. They are two phrases we kick about a lot. And they're heavily featured in the book, The Value Flywheel Effect coming out soon.

Few companies will say they don't want good engineering. And we are happy with bad engineering. But they don't define what good looks like. And then the second thing is that engineers are expected to write lots of code. For me, engineering excellence is not writing loads of code. It's about getting into code reliability, feedback loops and how well engineering is functioning. And how your team is performing and meeting bigger goals.

I love to say 'slow is smooth and smooth is fast'. So how do we set ourselves up for that? At the beginning, I like to go slowly to look at our process. To define engineering excellence, we use Dan Pink's motivation factors of autonomy, mastery, and purpose. We translate those motivation factors to technical excellence, autonomy, and customer focus.

Well architected is better defined than engineering excellence. But I find that a lot of people haven't heard the term well architected and they think you've just made it up! There's a body of evidence, supporting material, videos, tutorials, workshops and labs to support well architected. People can google well architected, whether they're talking about AWS, Azure or Google. And they're going to get a fairly consistent response. They self serve and self learn.

I remember years ago, when you talked to architects, they said that good architecture is a non functional requirement. It's performability, scalability, extendibility and every stupid word ending in 'ility'. Now the fact is that it is well documented, understood and you can rhyme them off as SCORPS makes it easier. If you want to move fast, you've got to be empowered and know what good architecture looks like. When you have guidance or patterns that are implemented in a well architected fashion, that sets you up for rapid delivery, moving with speed, and in an engineering excellence way. It's fast flow aimed to facilitate you moving fast, getting things out quicker and being more competitive.

Teams are rapidly delivering product value multiple times a day. And they have a trail of evidence that they're going the right way because of these practices. They have dashboards, logs, alarms, alerts and the run books and the playbooks. And the key business indicators (KPIs) at their fingertips. So any stakeholder can challenge them on what they are doing, how they are operating or what they are deploying. I

f you arrive in an area that isn't well architected, you've got to spend three months trying to understand what went on before or trying to understand the decision making. Or you've got 12 months of technical debt that should have been taken on board before you moved there. That very difficult from a personal perspective.

There's a whole bunch of advantages. One is a problem prevention culture. But I don't think it exists in a lot of organisations. It hasn't really cut through. They're still on the feature, factory, server mindset. Deliver, deliver deliver. Feature, feature feature. And then they have a tipping point where everything grinds to a halt for months or maybe years. And it may never recover.

But if you have a continuous improvement mindset and you are investing in fraud prevention, well architected, engineering excellence and continuous learning. And you are enabling and applying this to your teams, you get ahead of problems before they become problems. You're investing in performance, security, resilience, high availability, every day and every week. And those things compound on each other. It's like compound interest!

From a problem prevention perspective, do you want to spend all your time babysitting a non well architected workload and dealing with all of that? You want your teams moving, adding value and moving on to the next thing. That's not possible if your build lacks quality, is always down or if you're having to constantly upgrade. With well architected and engineering excellence, we can build things that run and increase in value. And there's less work over the long term, while your teams move on to what the business needs. I don't think a lot of orgs think in that way. By the time they do get thinking that way, they're already experiencing a lot of problems.

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect book
Follow us on Twitter @ServerlessEdge

Serverless Craic Ep36 The Value Flywheel Effect Book Launch

We are just back from The Value Flywheel Effect book launch at DevOps Enterprise Summit organised by IT Revolution with Gene Kim and crew. We had a great week doing our book launch. It was great to see the buzz and the content. But getting handed the first copy of The Value Flywheel Effect book made it very real! There was a shelf full of IT Revolution books in chronological order. Like DevOps, Enterprise Handbook, Accelerate, Team Topologies and all the Mark Schwartz and Dominica DeGrandis books. And The Unicorn Project and The Phoenix Project. It was unbelievable to see our book sitting alongside all of those books.

Learning Sprint

The first thing I did was a learning sprint. I did an hour on creating a cloud strategy with Wardley mapping, which I thought was interesting. I used Ben Mosior's Wardley map canvas from LearnWardleyMapping.com. And it was great taking people through that. Once people start connecting the elements of the value chain, they can start to ask why is that over there and not over here? Then you're into a nice conversation. Once they get beyond the terminology, notation and syntax, they are asking interesting, challenging questions. The canvas is a great way to get people thinking quickly. They start gaining insights and seeing what they may not have before using the canvas or map. And you can give them tips. People deliberate over who is the exact customer. Or the actual customer and their needs.

People can get very micro at the start. And you say just pick one and keep moving. Just keep pushing through, because you can always add more later. You are getting people to move quickly. And you are giving people a couple of steers. But the first 20 minutes is complete confusion. What are we doing here? And then once you draw the map out, people go 'Ah right!'. And then when you start to plot movement and inertia, that's when people get really excited. And it becomes crystal clear.

Creating the Value Flywheel Effect Talk

I deliberated on what to do for my talk because I wanted to do something different. So I decided on 'Creating the Value Flywheel Effect' looking at how came up with this stuff. So I did an intro to the book. And then I told the story through maps, similar to our Map Camp talk.

I started with one of the drawings we had done five or six years ago. Which was a scribbled messy drawing of a map. And I contrasted with the map in the book to show the evolution of the map. So it was a nice mechanism to tell the story. Some people think that maps come out fully formed. But they never do. There is lots of variation and challenge. We always challenge each other. And we revisit, rub stuff out and draw it again. When we validate certain things we always go back to the map. It's not the map. It's the communication! And the interactions. The maps are always wrong at the start. People try to go out of their way to create the perfect map. But that's not the point of the exercise.

The Value Flywheel Effect Book Signing

I did the book signing in the main theatre. There were 4 different book signings. So you hope to see people queue up because you don't want to end up standing on your own. But there was a huge queue and I was there for two hours signing 200 books. People were really nice and they were really excited. And lots of other speakers queued up as well. Propelo sponsored our book signing and they were great. So now the book is in the wild with 200 plus people! So we're starting to get feedback from people who weren't in the early previews.

It was fantastic to see Dominica DeGrandis' comments on LinkedIn. She wrote the book: 'Making Work Visible'. It is a brilliant book about visualising flow. She has a couple of posts about our book: 'The Value Flywheel Effect'. And she popped up a maps from her LinkedIn called 'Mapping Psychological Safety'. It was the name of the post on her blog: DDeGrandis.com. And she said that it had never occurred to her to map psychological safety. I thought that was insightful. We would map stuff like that all the time. There's no boundaries to what we map. Psychological safety is usually the base or foundation of the map. Mapping, safety or challenge are things that are quite hard to see. But they are the most important thing for everything that comes above it. The thing at the very top, which is the need, is usually the least important because it is the end product.

It's built into the flywheel. You need an environment where it's safe to challenge. And having safety to challenge requires psychological safety. It's cool that it's resonating with people and they're starting to zero in on those sorts of things.

DevOps Enterprise Summit was a great event. Look up the slides on GitHub. All the videos are on videos.itrevolution.com.

Serverless Craic from The Serverless Edge

Check out our book The Value Flywheel Effect 

Follow us on Twitter @ServerlessEdge