I recently read Waltzing With Bears by Tom DeMarco and Timothy Lister, these are the same guys who wrote Peopleware so I was curious to give it a read as I found Peopleware useful, if a little dry.
Waltzing with Bears is all about managing software risk. Specifically the risk that something will not be delivered on time. The example the pair give early in the book is an airport which couldn’t open because the software to operate the baggage carousel wasn’t working. A late software delivery had huge financial impact.
In the book the authors talk about different ways to identify, represent, and manage risk. Like their other book Peopleware Waltzing with Bears is very comprehensive walk through of software risk covering a lot of the basics as well as some really interesting topics such as how to show delivery dates in a graph format to show the earliest possible, most likely, and worst case delivery dates. Thereby giving far more context than a best guess (which as we all know has a bad habit of being communicated to clients and becoming a deadline).
The authors made a very nice point about the bold being the ones who start projects early, not the ones who set ambitious deadlines and expect people to hit them.
However, I couldn’t help feeling like the authors were missing a big piece. The entire book (which I admit isn’t a long one) is based around delivery date risk. There’s no mention of many of the other risks which software teams face including usability, tech debt, and the ever present security risks. I would have liked to have seen more (well, any) pages dedicated to risks which aren’t about the due date. I felt like we were given a comprehensive introduction, but at the expnense of a breadth of knowledge of how to manage other risks.
Overall a good book which is well worth a read to anyone getting started in project planning and wants to understand how to manage the risk deliveries will run late. However, only a 4* read for me.
What do you think? Have you read Waltzing with Bears? Post your comments below!
Over the last year I’ve invested time in trialing and adopting apps which help my productivity. In this post I’m going to share them and explain why I believe they’re invaluable.
Todoist
Todoist is an easy to use and intuitive TODO list application which supports projects, due dates, reminders, tags, and filters. It’s easy to use and syncs effortlessly across devices. I use it for everything from management work projects to keeping track of shopping lists and birthday presents.
The premium version unlocks additional features and it is well worth the money.
However, be aware downloading Todoist is enough to organise yourself. No tool can do that if you don’t have a system in place. I strongly recommend having a look at
Forest
Forest is an app which encourages you to put down your phone. I’ve written about it before and continue to use it. You can set how much time you’d like to “lock” your phone for and if you pick up before then your tree will die. Planning trees leads to gold which you can use to purchase more tree designs in the store or even plant trees in real life!
Braintoss
I started using this app this week and I’m really impressed. The premise is incredibly simple, the app records a quick message and then emails the text to the email address of your choice. Install on your watch and configure to the email of your Todoist inbox for a really effective way to record notes wherever you are and drop them right into your digital in tray!
Audible
Again, Audible shouldn’t be a surpise to anyone who’s read some of my recent blog posts. Listen to audiobooks while you’re driving or doing housework for a really effective way to consume books you wouldn’t ordinary have time to read. Especially if you practice building up your speed until you can listen in hamster mode!
And A Setting for Luck
Chances are your phone has a time limiter built in already, configure this to limit access to those time sync apps to 30 minutes each day. Being asked if you really want to spend your fourth hour on Facebook (or social network of choice) really is a great way to get you off your phone!
What are your favourite productivity apps? Do you use any which aren’t on my list?
This is a question I hear a lot, people have heard of (or may follow) Scrum and often have read about DevOps. They want to know whether DevOps is a replacement for Scrum or if it’s something they should be doing as well. Others believe that Scrum and DevOps are incompatible, in this post I want to talk about what both of these are how (because spoilers – they can) they should be used together.
What Is Scrum?
Lets start with the obvious question, if we’re going to discuss how DevOps and Scrum interact we need to define what exactly what we mean.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
The Scrum Guide
The Scrum Guide is an extremely concise and valuable guide to Scrum. If you haven’t read it I strongly recommend you do. However, for the purpose of this post I’m going to to highlight a few points.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
Various Sections of The Scrum Guide 2020
When many people think of Scrum they discuss the Scrum Events, these include Sprints, Retros, Planning Sessions, and Sprint Reviews. However, equal importance should be given to the underlying theory of empiricism and incremental nature.
Each Scrum Team should deliver at least one increment of work each Sprint, this increment should be potentially releasable, and meet the Definition of Done. They will then meet in a Sprint Review meeting and discuss what they should do next to deliver maximum value.
What Is DevOps?
DevOps is, at it’s core an effort to reduce the divide between development and operational teams. Literally, Dev-Ops there are many practices and ways of doing this from the cultural to the technological however what has most likely led you to this post are the ideas of Continuous Integration, Continuous Delivery, and Continuous Deployment. Again, DevOps has many valuable lessons, I’m focusing on these three not to devalue the other concepts, but simply because they are some of the key concepts we need to understand for this article.
Continuous Integration requires that each developer merges their code into the master branch every day and if the master build breaks it is resolved or rolled back within ten minutes.
Continuous Delivery is a promise that any code which is the master branch is always in a potentially deployable state. Untested and unverified code is never merged in.
Continuous Deployment is an automation mechanism which pushes whatever is in the master branch into environments (often production) without any manual steps.
As you can see these are cumulative, so teams may practice Continuous Integration but may not practice Continuous Delivery or Continuous Deployment. It is also nearly impossible to practice Continuous Deployment unless you also follow Continuous Delivery and Continuous Integration.
It’s also worth mentioning the “3 Ways of DevOps” these were popularised by the highly successful book The Phoenix Project. The 3 Ways are:
Flow/Systems Thinking
Amplify Feedback Loops
Culture of Continual Experimentation and Learning
Using Scrum and DevOps Together
Now that we’ve talked about what Scrum and DevOps are (or at least highlighted some of the relevant and key parts of each) I want to discuss whether these concepts can work in harmony together.
The first aspect to address is the Scrum concept of an increment. The Scrum Guide says that each team should produce at least one increment of “Done” software which is potentially releasable to production each sprint. I believe that the three concepts of Continuous Integration, Continuous Delivery, and Continuous Deployment are not only compatible, they are the natural evolution of this requirement.
If an engineering team is following CI, CD, and the other CD then each day (or less) a piece of work should be added to master. This means that a typical team of 7 engineers working a standard two week sprint could easily produce seventy or more increments in a single sprint. They key here is that by breaking down the Scrum Product Backlog Items down into single pieces of work which can be individually developed with a single day and then tested in isolation. This is not easy, however with practice and strong story splitting skills it can be done.
It’s also worth mentioning the Definition of Done. The Scrum Guide states that each increment must meet the Defintion of Done. Continuous Delivery states that the master branch should be always be in a deployable state. What a high performing Scrum/DevOps team should do is write automated tests which execute against incoming pull requests into their master branch to confirm that it always meets the agreed Definition of Done. This not only reduces the amount of repetitive testing work expected of the team but it highlights immediately when a proposed increment does not meet the team’s Definition of Done. If it doesn’t, it’s not merged in.
Maybe DevOps and Scrum aren’t incompatible after all? Photo by Blue Bird on Pexels.com
Before wrapping up I also want to consider the 3 Ways of DevOps I discussed above.
By building the Definition of Done into the Deployment Pipeline of the product we support the 1st Way by ensuring that the requirements of the team are baked into the pipeline.
The 2nd Way is to shorten feedback loops. Scrum emphasises the value of engaging with stakeholders frequently to ensure that they are involved and know the current state of the product. Scrum is also based on empirism, the belief that only we can only make estimates by looking at real data, by valuing the 2nd Way and shortening those feedback loops wherever possible this gives us a more accurate picture of what impact our changes have had. Simply put, this more accurate view provides the transparency we need to inspect and adapt. These are the three pillars of empirism.
Scrum also defines an event, the Retrospective where team members should meet to discuss ways to improve the quality and effectiveness of the team. This fosters the experimentation and innovation expected of the 3rd Way. These ideas aren’t working against each other. Scrum is providing events to ensure that the DevOps approaches are being honoured.
Conclusion
DevOps is often seen as a Scrum upgrade or perhaps a replacement to the agile framework. However it shouldn’t be. I believe that many of the automation and development strategies of DevOps are the natural evolution of Scrum principles and fit very neatly into any team already using the process.
With automated tests continuously testing each increment to guarantee that it meets the team’s Definition of Done increments can become smaller and a continuous flow of high value work can be delivered with shorter lead times and higher quality.
I recently finished Algorithms To Live By, a book by Brian Christian and Tom Griffiths. I’ve been putting off this book for a while (I’m not sure why) but after reading a few positive reviews I fired up Audible and listened to it.
The book opened extremely well. I wasn’t entirely sure what optimised stopping was. What the authors do incredibly well is take computer science concepts and apply them to real life problems. In that case when to offer a candidate a position or when to say no and hope for someone better (the secretary problem) or when to opt for the empty parking space and when to carry on and hope for one closer to your destination.
There were interesting chapters on sorting and searching (football games league and organising books), Game Theory (employees at companies with unlimited holidays), and scheduling.
While extremely interesting what it lacked was… how do I say this… a lot of of take away value. I felt there was so much interesting stuff in there, but I’d have loved to have some really clearly spelled out takeaways. I think there’s still a jump to be able to take what the authors talked about and apply it to day to day life in any more than the lightest way. A great read, but perhaps not as paradigm shifting as I’d hoped.
One of the initiatives I sponsor at work which I’m most proud of are our weekly tech talks. The company had a long history of doing them, a small group of people would volunteer to talk about something for about an hour on a Friday afternoon. But the prep was hard work and there was no consistency. We could have talk three months in a row and then nothing for the next six. Worse still the same people always felt pressured into talking which seemed very fair on them.
Back in 2019 I went to the Leeds Test Atelier and attended a talk by Sophie Weston. She discussed what her company had done with tech talks and I was really impressed. She argued that the key requirements for any sustainable tech talks were:
Duration should be 20-30 minutes
The same time/location every week
DO NOT MISS A WEEK
Food
Inspired by this I went back to work and set about seeing if we could pull off something similar. Sophie had explained how important it was to keep the schedule going week after week. If you start missing weeks those odd weeks develop into hiatuses and then the entire thing stops. She also strongly advised bacon sandwiches but I didn’t have a budget so we relied on BYOB (Bring your Own Buttie) instead.
Over the next few weeks I set about pitching my idea and recruiting speakers. I wanted twelve. I figured that if I could find twelve people willing to give a talk and get them on a weekly schedule then it would be worth doing and I might stand a chance of the talks becoming a sustainable weekly occurrence. I got fifteen.
The Mic Drops began to take off. Photo by Christina Morillo on Pexels.com
We booked a meeting room and opened up Skype for anyone who wanted to dial in. We also made sure we recorded all the sessions so if someone couldn’t attend they could watch it at a later date.
At the time of writing we’ve had:
60 consecutive mic drops pausing only for holidays
Over 20 different speakers
20+ hours of recorded videos
1700+ attendees
Even the global pandemic didn’t slow us down, we simply moved to 100% online!
So here are my steps for starting up your own weekly tech talks:
Plan out your first three months in advance to make sure you have sustainability
Hold your talks at the same time and place every week
Unless for a specific reasons the talk and questions should take less than 30 minutes
Record them
Don’t limit to “Tech Talks” some of our best talks have been on sleep, agile, management practices, books, and communication skills. Encourage variety!
Always have a back up speaker, try to have two
Survey your department to find out what talks people are interested in
I recently listened to the audiobook version of Matt Skelton and Manuel Pais’ book Team Topologies. It was so good I bought the kindle version while I was still halfway so I could make notes and highlight the good bits (most of the book it turns out).
Team Topologies
The book takes several principals such as Conway’s Law and really applies them to business teams. This is something I’ve seen first hand. When several teams work on one large product the codebase becomes decoupled if the teams are given ownership of particular components. However, if teams are expected to work across the codebase the solution becomes monolith and the teams become a super squad.
In the book the authors argue that there are actually a very limited number of team types in a modern organisation. I don’t want to list them because I’d strongly recommend you to buy the book and read the descriptions for yourself. However, if the various types it was the concept of platform team which intrigued me the most.
I actually think Matt and Manuel underplay the huge value of a platform team. They discuss brilliant ideas about consumable APIs and documentation for product teams which consume them. However, a data driven business like mine I believe we should run far more platform teams and far fewer product teams. If we want our Product Owners to be able to innovate and prove the value of ideas quickly we need our data sources and components to be as plug and play as possible. This allows any product or concept to be built and tested very quickly. If all these services were owned and managed by platform teams, instead of falling down the gaps between product teams the solutions would be more robust and the lead times far lower.
If you’ve never given any thought to how teams are created and assigned areas of ownership then this is a brilliant book to read. If you’re not sure how your teams communicate and share information then this book is essential.
In total it took about 18 months to write Code Black, my recently published technical parable story. I’d originally had the idea in the summer of 2018 but it took a little time to properly outline the story.
Code Black
Instead of using a common format like The Hero’s Journey I used the various stages a team would progress through as they developed and refined their DevOps journey.
Whenever I write the first thing I do is try to outline where I want to go. This involved Mike being approached by his friend Bob (who was called Robert) at that point. Obviously he had to join the company and walk into chaos, I tried to describe a bad day we could all relate to.
As the team learns they begin to invest in more frequent releases. I wanted to explain as many of the good reasons why this was as good an idea as possible. The reduced technical risk, the reduced delivery risks, and the increased ability. I also wanted to discuss some of the common objections. Before moving onto discussing Continuous Delivery and Continuous Deployments and how using these techniques makes it less likely your sprints will fail and makes it easier to help your customer with your resorting to release branching strategies.
Once I’d outlined the story and had a basic idea of the characters it was time to sit down and write. In reality it only took a couple of months to create a first draft. Knowing where I am going always makes it a lot easier to put words in a page.
Once I’d finished writing I printed everything off and put it on a shelf for a few months. I wanted to forget as much as I could before I started proof reading so I could spot as many errors as possible.
Many of my colleagues found me over this period sat throughout lunchtime with a stack of paper and a highlighter pen. Believe me, I found a lot of things which didn’t make sense.
Once I’d corrected as much as I could it was time to publish. I’d already created my LeanPub account and in true agile style I decided it was best not to procrastinate and to start gathering feedback. The great thing about LeanPub is that it’s very easy to update your book in response to suggestions.
So that’s the story, I’ve now sold a handful of copies and so far the feedback has been very positive. I probably shouldn’t but I’m already thinking about what I should write next!
If you’re interested in picking up a copy of Code Black it’s on LeanPub now.
When I first heard about The Unicorn Project I have to admit I was disappointed, I’ve long been a evangelist for Gene Kim’s book The Phoenix Project but I’d just spent months working on my own development DevOps book, Code Black.
I shouldn’t have worried, I really enjoyed The Unicorn Project and we’d gone down different angles. Where I’d focused more on the Continuous Deployment journey Kim’s book focuses much more on developer empowerment and continuous experimentation.
The Unicorn Project
The story follows Maxine, the developer who caused the now legendary payroll outage at Parts Unlimited towards the start of The Phoenix Project. Exiled to the documentation team as punishment she’s instructed to support the Phoenix rollout but quickly realised how woefully under supported the engineering teams are. As the business piles on more and more pressure, expects more features, and has less and less appreciation for the technical debt they’re wracking up they continue. Until, as we know the entire project explodes.
Working with some familiar characters such as Bill, Brent, Erik, and Maggie and a few new ones including Cranky Dave and Kurt our heroine works to make life better for the entire company. These are the engineers, the red-shirts, not the bridge crew. They’re the ones who actually do the work and they’ve got a lot of it to do!
What did I like best? Kim put lots of emphasis on testing and improving the entire system not just a small part of it, he focuses on collaboration and the importance of making it easy to onboard developers and share knowledge, and really drives the need to innovate and out experiment the competition. He also emphasis the importance of treating engineering tools as important systems and draws distinctions between the IT products we build, and the miscellaneous ones which just keep the lights on.
What wasn’t so good? Within a few chapters I was absolutely sick of Erik’s use of the word “sensei”… seriously can’t some of the people he quotes simply be experts, evangelists, or even gurus!?
On a more practical point the book spends a lot of time evangelising functional programming and scalability technologies. Which is great, they’re very powerful tools. But one of the things I liked so much about The Phoenix Project was how it was clear the team were struggling the same tech debt we all are. It made it more relatable and I worry in this book Kim’s “rip it out and use the latest and greatest” will overpower his more generic messages of continuous incremental improvement. Perhaps it’s personal preference but I like my DevOps books technology agnostic.
So, would I recommend this book? Absolutely without question! I believe that The Unicorn Project will take its place alongside its elder sister on the bookshelves of developers, testers, managers, product owners, and operational engineers for the next decade. If you haven’t already go and buy it, any while you’re at it not get a copy of Code Black too!? 🤣
I’m sure every developer out there would love to have a single code base with builds which are automatically tested and pushed out to customers. However, let’s assume for a moment that you’ve not got a full CI system with triggered builds, automated testing, and thousands of automated deployments a day.
For the sake argument let’s say you’ve got some of these pieces in place. Perhaps you have nightly builds? Maybe even some unit tests! But if you’re like most of the companies I’ve worked with you still run manual signoff scripts and have a couple of guys who do the deployments, know every config setting by heart and can get your application to run in all kinds of new and innovative ways.
Despite what The Phoenix Project tells us deployments to customers are still a big deal and version management (finding a way to release bug fixes but not new features) is a fact of life.
If your customers are anything like mine they’ll be incredibly nervous about taking new features. They want lengthy UAT phases and opportunities to train their staff on new functionality. This may seem like Waterfall to us, but remember many of our clients have stakeholders in some very big business. In my industry (Health and Leisure) for example we have code freezes over the January period while New Years Resolutioners and marketing campaigns are at their peak. Very few businesses would open themselves up to the risk of IT failures during these critical times.
And yet support contracts and maintenance doesn’t stop. The busy times are when the software is really put to the test and we must be able to respond to any issue which may arise.
This is why we use maintenance branches.
Our job as developers and IT professionals is to deliver a good service to our customers. We need tools and processes to do this. Agile and Continuous Integration are two of those tools but if they don’t help us meet business needs then we should seek others which do.
My customers tell me that they want to be able to take patches quickly if required. That they want to be able to access fixes without the need to test and learn new functionality.
Techniques such as feature toggles help but in my view the only way to truly meet this need is to cut a release branch after each feature (or for convenience block of features) is completed. We usually use a minor version to represent this. Using this model we can support customers without surprising them with new functionality and continue to develop knowing that we can put out maintenance releases of older version at any time.
Controversial? Perhaps, practically over purity… I hope so. What are your views or release branches and support customers with on premise installations?
I was lucky enough to get tickets to see Mike Taulty talk about Microsoft HoloLens at Leeds Sharp last week. I didn’t really know anything about augmentated reality or virtual reality but in the interests of Staying Technical I was definitely interested to find out a little more.
Wow!
It turns out that the HoloLens is a Windows 10 PC designed to be worn rather than sat at. It runs apps from the windows store without modification (although Mike did stress that typing furiously in midair is somewhat less precise than using a keyboard). Instead of sitting on a screen the windows floats in front of you, hovers on a wall, or rests on a table.
3D apps can be build using Unity 3D (in fact Mike showed us how). I was really impressed how easy it was to work out what the user was looking out and listen to what they were saying (although I imagine Microsoft Cognitive Services could be used very effectively here).
Can I imagine us all walking around with these things strapped our head? Probably not… at nearly £3000 for the developer version these are likely to be out of the consumer budget (although Microsoft are working with partners at the moment to develop other models). But in a commercial environment? For architects, engineers, surgeons or even as a stepping stone onto the next generation devices which may weigh little more than regular sunglasses? I could see that!
Am I rushing out to buy a HoloLens? Probably not, it would I seriously consider an Acer or Asus model for a couple of hundred pounds… that’s a much harder question to answer! I can imagine little spaceships flying around my living room or a huge troll sat on my sofa playing chess with me – the sky really could be the limit with these devices!
dotdotdev.com 