Tag: DevOps

Scrum Is Not Enough!

~ Adam ~ Leave a comment

Let me start by saying I’m a big advocate of scrum (despite some of my posts in which I challenge it over and over again). Having said that it has it’s weaknesses (like any process), one I’m going to highlight in this post is the insular nature of some scrum teams.

The best way to explain this is to describe my own experience. When I started in the Scrum Master role I was very keen on continuous delivery and wanted the development team to produce a build every two weeks which could be supplied to the business to decide whether to deploy it or not.

We had a lot of projects on at the time and we were working very hard to meet the commitments my predecessor had signed us up to and get features out the door on time.

This went on for a month or two, we hit every deadline in the calendar and provided the builds to the deployment teams on the dates we’d agreed. So what happened? Nothing…

What I’d failed to realise was that despite our hard work over the last few months we’d failed to release a single new feature to a customer. The deployment teams had struggled to install our software into UAT and without any contingency (except when it was carefully planned for) we had no capacity to assist them or pick up any issues – until the next planning session of course (where usually the next feature was the most urgent due to “customer commitments”).

Development kept on working, features continued to be produced and deadlines were hit. But the customers were sat waiting, UATs couldn’t be completed (or in some cases even installed), and the business because frustrated with us because we weren’t available to help them get the product out the door.

So what went wrong?

This is where you may have to forgive my sleight of hand in the title. I don’t believe the problem was with the scrum methodology as such, merely the most common implementations of it. The first oversight was the handover, the second was the goals of the team. Let me explain…

Firstly the handover, the issue wasn’t that it was sloppy or that it we didn’t have consistent priorities across the business (although that certainly didn’t help). The issue was that we had one… A scrum team should contain all the skills and knowledge required to get a feature from concept to customer. Rather than handing builds over to the business to deploy we should have had someone from the deployment team working in the scrum team who would actually do the implementation. The team itself would then support the new feature through it’s UAT phases and out into the customer’s live environment.

The second failing I mentioned was the team goals. I have already alluded to this but the goal of the team was to “write this feature” whereas it should have been “deliver this feature to the customer”. Only once that goal has been met should they move onto the next one.

This continuity and accountability is a very powerful thing. Projects fail when departments don’t communicate with each other or their priorities are not aligned. Systems slow when there’s too much Work in Process (for example incomplete UATs) clogging up the pipeline and generating unplanned work. If you want to break out of this cycle you need to stop thinking about departments and handovers. Stop thinking of scrum teams as groups of developers delivering feature after feature and start thinking of projects being created and delivered by teams of people from all the disciplines you need.

If you can do that, then you can make your scrum team work for the business and not only for it’s own productivity.

Measuring Sprint Velocity is Useless Unless You Ship!

~ Adam ~ Leave a comment

I’ve recently been reading The Goal by Eli Goldratt, in it Alex Rogo (the Plant Manager) boasts to an old teacher of his that the new robots they’ve installed have greatly increased their efficiency. The Yodaesque Jonah then promptly proves his data worthless and sets Alex on the path to enlightenment.

What struck me however was how clearly this mirrors the software industry. The Goal has been the go-to book for managers for years but only with the relatively recent release of books like The Phoenix Projext have the applications to software industries been recognised.

It’s a well established idea to model a software development team like a factory. Time and money goes in, features and fixes come out. In the story Alex was delighted that his robots had given him an increased efficiency for making a particular part of the process, it was only when Jonah pointed out that the robots did not result in any increase in sales that he saw the problem in his logic.

So, let’s imagine that our software business is Alex’s factory. We’ve brought in a robot to do the work of the Development Team and Sprint Velocity has gone up from 100 Story Points to 300. As the Development Manager you get to pat yourself on the back, celebrate your success, and go home at the end of the day.

But what happens to your release at the end of your Sprint? Is your product stacked up on your factory floor awaiting the next machine (perhaps your deployment or infrastructure team)? Or have you sold it and added value to your business?

This may seem like false measurement, your numbers are telling you that you’re delivering but the reality is very different. The truth however is even worse, unshipped features are the software equivalent of Work in Progress, they’re the half finished products sat on your factory floor taking up time and space. Until your business can deliver them they’ll continue to come back and haunt you, injecting unplanned work into your Sprints and sucking time out of your Development Team.

So, If your Sprint Velocity measurements only take into account the work pushed through your Development Team then you’re not measuring the value you’re adding to the business, you’re making the same mistake as Rogo and only considering one part of the system. You may be getting great results, but are you helping achieve the goal!?

The Phoenix Project Book Review

~ Adam ~ 12 Comments

I recently read The Phoenix Project, the definitive and often referenced DevOps Business Novel by Gene Kim, Kevin Behr, and George Spafford.

I have to admit I’ve been putting off reading this book, perhaps I had some misgivings about replacing Scrum techniques with the new craze of DevOps. Having decided that I was going to invest my time I was tested once again when I realised that Bill, the book’s main protagonist is an infrastructure guy… I’m a Development Manager, I want to know what DevOps can do for do for me not what I can do for the other guys!

That however was the last time I paused before devouring the remaining 370 pages.

Bill’s first few days after his promotion are littered with disasters. He has a project to deliver, infrastructure problems to resolve, and political ambushes to endure. In other words, he’s in the situation we’ve all experienced when teams aren’t communicating and colleagues are so stacked up with their own projects and priorities that they simply can’t assist each other.

With the timely arrival of Eric, the new potential board member Bill slowly equips himself with the tools he needs to resolve his infrastructure headaches and get the Phoenix Project back on track. Eric, acting as a kind of DevOps Yoda helps Bill gain an understanding of the four different types of work, the Theory of Constraints, Systems Thinking and see the value of Automated Deployments.

There’s a nice appendix at the end which helps consolidate the ideas and explains some of the ideas away from the story. There are also some mind blowing statistics about how some of the big web companies such as Amazon, Google, and Netflix.

So would I recommend this book to others? Absolutely! In fact I have, repeatedly to friends and colleagues! Whether you’re a developer, infrastructure guru or IT manager this book will introduce you to several new ways of thinking about workload management and IT processes.

DDDNorth 2016

~ Adam ~ 3 Comments

I was very excited when I saw the announcement of DDDNorth earlier this year. I’ve attended the conference several times before and to see it was once again in Leeds really gave me no excuse not to attend!

Despite having a rather late night the previous evening I was one of the first there, in fact I think I accidentally tailgated a speaker inside and sat quietly in the corner until the masses arrived.

For those of you who don’t know the DDD events are free, one day conferences focused at .NET developers. They’re held around the country and have a very high standard of speakers. DDDNorth is our annual event and usually circulates between the Universities of Leeds, Sunderland and Bradford.

The first session I attended was “Machine Learning for Muggles” by Martin Kearn and it was one of the best geeky talks I have ever attended.

Martin demonstrated how to use the Azure Machine Learning API to upload your own data for analysis. He then took a photo of the audience and used facial recognition and text analysis to ask questions like “show me the happiest person”. Before today I’d always assumed machine learning was only for the likes of Google, before the first coffee break I was already wondering whether I could use the APIs in our own products.

The second session I attended was “10 More Things You Need to do to Succeed as a Tech Lead” by Joel Hammond-Turner. I’d attended one of his talks before (entitled 10 Things You Need to do to Succeed as a Tech Lead) and with my recent change in role I felt it was a wise choice session.

I was right. Joel gave us a good list. It contained tips on requirements, instrumentation, and team training. I was particularly impressed by his thoughts on managing and measuring technical debt!

The last session of the morning was “You read The Phoenix Project and you loved it! Now What?” by Matteo Emili. Having recently bought and demolished TPP while on holiday this was the session I was perhaps most excited about. Matteo argued for pragmatism, he told us that in order to sell process changes the value must be determined. He quoted the common phrase “you can’t manage what you can’t measure” and discussed in depth how you should use the Build-Measure-Learn. There were even a few tips and ticks towards the end to help us get our automation deployments going!

It was lunchtime, which meant sandwiches and GROC talks (I have always been curious to know what that stands for).

I arrived in time to see a few interesting mini-talks. The first was on using the C# interactive window in Visual Studio, the second was around ARM templates for Azure, and the final one was entitled “What’s the Point of Microsoft?” and was a tongue in cheek presentation about how the big tech players compete in today’s software and hardware world.

I’d love to continue, I’d love to tell you about the Microsoft BOT API talks I had lined up for the afternoon. Alas it was not to be, it was around this time that the office called to tell me that several hundred members were having issues with their accounts. No rest for the wicked!

I’d like to take the time to thank the DDDNorth team for putting together yet another fantastic event. The speakers this year were superb and if I get the chance I fully intend to catch the sessions I missed elsewhere in the country at a later date. See you next year!