Review of: The Phoenix Project 

5170sr05QALTitle

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

Author

Gene Kim, Kevin Behr and George Spafford

It is not often that you hear of a novel which is part of some ethereal ‘required reading’ list for IT professionals. This is apparently one of those rare beasts. I was dubious. I mean who reads a NOVEL about DevOps and software?! Putting aside my cynicism, I downloaded it onto my Audible.

While obviously a somewhat caricatured scenario (well… in most cases…) this book does a remarkable job of putting the software delivery life-cycle under the spotlight while actually remaining readable, engaging and entertaining.

The story revolves around a newly promoted Operations Manager, a failing company, and its flagship ‘super-project’ all set against the familiar backdrop of a highly competitive market. Hampered by disassociated business, project and IT teams, single points of failure, a chronic blame culture, and significant technical debt, the ‘heroic’ Operations Manager and his team embark upon a journey of Agile and DevOps self discovery under the (slightly bizarre) tutelage of a ‘IT whizz’ who seems a strange cross between ‘Master Shifu’ and a rich, aging hipster.

It turns out I enjoyed this book. I found I was identifying with the protagonist; cringing at the situations I recognised (countless!), laughing at the jokes and nodding sagely at the thought processes (and occasional absolute confusion) of the main character. Everyone who has ever worked in or alongside IT Delivery would recognise these characters; everyone knows someone a bit like Brent, or Sarah or John.

If you can suspend your disbelief at the apparent ease of new process adoption in this company (only ONE team actively trying to get around the rules?… yeah right!), the astonishing lack of panicked attempts to backtrack on the new processes when the going gets tough, and a somewhat exaggerated ‘mentor’ – this is valuable book. It takes the idea of ‘telling a story’ to its ultimate endpoint – a full novel. Instead of a pseudo-rule-book of buzzwords tied together with dry examples of a finished product, this book takes you on a journey to show how you could get there… and even more importantly, WHY you should.

As someone whose entire role revolves around one of those ‘bottleneck workstations’ so accurately described in the book, I found the authors managed to succinctly put their fingers right onto about 80% of my daily challenges. I also found myself giving mental high-fives when I identified initiatives that I have introduced or been part of in my own career, and rubbing my chin thoughtfully over possible future opportunities.

This book touches on most of the main challenges and drivers of modern day software life-cycle management, alongside practical descriptions of various Agile, Lean, Devops, Continuous Delivery, Kanban, Continuous Improvement, and a whole host of other practices in between. It identifies the common misconceptions between IT and the business, and it demonstrates -albeit in a somewhat exaggerated way – the benefits to the whole business if everyone starts working as part of a cohesive system.

I thoroughly recommend this book for anyone that works as part of – or relies upon – business IT as part of their job. Ir might explain a lot and it could have some useful ideas for your own practice.

An oasis of calm in a sea of noise

Gardening runs in my family.  

My mother and sister both grow all variety of edibles, my grandmother is a plantswoman of whose skill I can only hope to emulate and going further back, my family has grown orchards and tended farmland; getting back to the earth is something that runs pretty deep.

Being a ex-designer (and a sucker for creating order in a chaotic world), I prefer architectural gardening; unusual plants, hard landscaping, distinctive shapes and smells.

Recent research by the King’s Fund for UK Department of Culture, Media and Health (2015) indicate that after the age of 25, gardening activity sharply rises to more than 40% for 25-44 year olds, over 60% in the 45-64 age bracket and over 70% for the over 65s. I wonder if there is a any correlation that could be drawn between between age, career progression / complexity and the need to get out into green space – or whether its just people eventually realising that most of the programmes on television are pretty rubbish during the day…

Gardens and gardening are my ‘mental clearance spaces’; the places I gravitate towards when I have been posed a particularly thorny technical problem, or I have multiple work demands on my time that are beginning to push me towards the edge of what I can handle in one go. Being in, walking through, or being actively engaged in creating or maintaining gardens quiets the mind, allows me to relax, and gives me time to sift through and make sense of what is actually going on. It is one of my more reliable methods of accessing my ‘systems thinking’ brain; tuning out all the useless information, the endless meetings and the extraneous ‘noise’ of a issue or problem and chasing down the roots of the issue.

Gardens have no judgement, no hurried thinking, no changing demands bar what you put on yourself.. Freud said:

‘ Flowers are restful to look at. They have neither emotions nor conflict,’

– something that I think all of us could probably benefit from in today’s modern, connected and hyper-politicized world.

And on that note I am going to go and attack a particularly pernicious weed that has decided to inveigle its way into my flower bed.

Take-away thoughts for DevOps / Agile practices

I attended the Computing DevOps Summit last Wednesday in London. It was a rather polished affair at the Grosvenor Square Marriott in Mayfair; well attended, well presented and with a broad lineup of Keynotes all roundly advocating DevOps.

It was a valuable day overall, but one speaker in particular resonated with me, as his choice of topic – ‘Unicorns and Elephants’ – is something quite familiar. The speaker, Rick Allan, Head of Delivery Capability at Zurich Insurance, spent his time waxing lyrical on the myriad challenges encountered by complex, multi-faceted organisations that have gone through significant organic growth. and the unexpected barriers this can create when adopting agile practices.

This is a scenario that I have seen in several organisations over the years – where do you even start when you have a estate that is riddled with legacy infrastructure and applications that have, over time, been ‘bolted’ onto each other, integrated with third parties and heavily customised. Automation in this landscape is a veritable minefield of problems.

My main take-aways from the event were:

  • Know what you actually have got, what it does, and what it communicates with.
  • Agree a vision with the business – implementing the changes needed to achieve that vision could have some serious cost and usability implications and so their buy-in and support is critical.
  • Pick off simpler applications first. Chipping small, tactical chunks from the monolith is going to be easier at first than trying to brute force it. Prove your method works.
  • Move away from project and start thinking by product and value stream (again – something the business really needs to get on-board with to enable this to work as this has budgeting implications.) This helps to break down velocity-sapping silos and move away from a transaction based culture.
  • Stand firm in the face of large, expensive programmes of change – they need to follow the rules too.
  • Implement a default tool-bench – a set of approved tools that are authorised and licensed for use. Migrate services over to them and shut off unauthorised tools behind you. Make sure your developers and engineers actually know about them, know what they are for and how to use them.
  • Use metrics to understand and prove where bottlenecks exist. This information can then be leveraged to determine a strategy to overcome the problem. Whatever the final option, the business case will need to be proven, and those metrics can help to establish that mandate.

In order to enable true continuous delivery, the ultimate goal needs to be consistent, converged and scalable architectures, ideally managed by smart software – and that is a long, and probably quite expensive, path for organisations with significant amounts of legacy applications and architecture. This type of change requires buy-in from the very top, and the investment, time and willpower to carry it through. Good intentions can only go so far.

Thoughts on Deep Work: Rules for Focused Success in a Distracted World

I have recently been listening to a new book on Audible – Deep Work: Rules for Focused Success in a Distracted World by Cal Newport, a MIT computer science professor and popular blogger.

I will admit this isn’t my usual reading material, but I stumbled upon mention of it on this blog and this blog, gave it a bit of research, read some really positive reviews of the book (New York Times, Associates Mind),  and given the impending start of my Masters degree, I thought it might be worth a quick look.

It would be a fair assessment to say that I have found it to be a fascinating book with some really strong concepts and a clear narrative style

The authors primary argument is that today’s knowledge-worker has a lifestyle that is so disrupted and fractured it becomes almost impossible to be able to focus on anything particularly complex. It’s easy to confuse ‘busyness’ with ‘productivity’ and if we don’t watch ourselves, we end up filling our days with shallow tasks instead of the mentally-intensive stuff it takes to truly get ahead.

The ‘Deep Work’ method advocates taking time away from interruption and actively blocking off potential sources of distraction; no phones (gasp), no social media (bigger gasp) and no email (…faint!).  The concept is explained more succinctly in the following equation:

High Quality Work Produced = (Time Spent) x (Intensity of Focus).

The author proposes several ways to achieve a personal ‘Deep Work’ approach ranging from completely locking yourself away, to setting up a schedule, to simply getting the most out of short bursts of available time, and he provides insight into what you need to do to be able to focus intensively on complex topics.

From experience, deliberately leaving your phone behind, or turning off your email is psychologically a pretty big deal. In today’s hyper-connected world choosing to disconnect can almost feel like sacrilege and that’s something you need to train yourself out of in order to embark on’Deep Work.’

I cannot recommend this book highly enough – it is great food for thought. All too often I have found myself being amazingly busy, but not feeling like I have achieved anything meaningful – and this book really gives voice to why I feel like that. I will certainly be training myself towards aspects of this approach when I start my impending Masters study sessions and, as far as possible, to get more productive hours out of my time at work.

Review of: Agile Project Management for Dummies

513ihYBwBfL._SX397_BO1,204,203,200_

Title

Agile Project Management for Dummies

Author

Mark C. Layton, MBA, CST, PMP, SCPM,

Format I read it in

Audible on Amazon. Narrated by Sean Pratt

What is this book for? 

While there are many companies out there that have a well-trodden Agile path, there are even more that have not made the plunge yet and are still solidly trudging along the Waterfall route to delivery. Sometimes that is the right thing to do – but in many cases there is plenty of evidence to indicate that a well-thought out and business-supported Agile approach will improve speed of delivery.

Like most ‘for Dummies’ books there is a implicit suggestion that the reader may not know a lot about the subject and is looking to expand their actionable knowledge on the topic.

What did I like?

The book covers all the stages of Agile delivery in a methodical way; lots of bullet points and lists and reminders of what to do. There is a good explanation of the Agile manifesto at the start and the author goes to some effort to provide background on the origins of Agile as a framework.

The final chapter has some really good pointers for finding other Agile resources and communities on the web.

I also liked the fact that this book has been converted to Audible. I find it easier to listen to technical information from these types of books as opposed to read them page by page. Generally I tend to listen to these on my morning commute as I find it fires my braincells up and the new information is more likely to stick than at any other time of the day.

What did I dislike?

This book should be renamed ‘Mostly SCRUM with a brief mention of other frameworks for Dummies.’ Given that there is a SCRUM for Dummies written by the same author I would have hoped to see a more rounded approach; more detail about LEAN and XP would have been nice.

The book is extremely rote (which I find a slight irony given the subject matter). There is a lot of slightly evangelistic preaching which strongly comes across as  ‘thou shalt’ and ‘thou shalt not’ commandments  – this turns me off somewhat as I do not think that delivery frameworks  can be absolute in this manner.. Additionally I found the content to be extremely repetitive if read from cover-to-cover – but if used as reference material then this approach is far more logical as it will serve as more of a aide memoire to dip into from time to time.

As a Environment Manager I was a little disappointed that there was next to no mention of management practices in this area – beyond the standard ethos of ‘automate it and your problems go away.’

Overall impression

As someone who is unfamiliar with SCRUM, this book provided some solid indication of how work flows through Delivery and the roles vital for the job. I do wonder if the actual SCRUM for Dummies book would have been a better read if that was what I was specifically interested in however.

I would have liked to see a LOT more case studies and real word examples as I think this would have lent weight to the ‘rules’ and given a more nuanced view of how different businesses have interpreted and applied the methods.

I probably wouldn’t choose to buy this book as I do not find this method (rote bullet points and lists) the easiest to get to grips with – but I would borrow it if it was in a work library. If you prefer to work within a very structured set of guidelines then this is a good book for a starter. It would also be a useful resource for teams moving to SCRUM as the lists and bullet points can be easily pulled out and used as visual reminders for best practice

What does Environments Management and a spiderweb have in common?

There is a look that you learn to identify in the early stages of taking on an Environments Management role. It’s somewhere between bashful, hopeful and slightly desperate. Occasionally it is preceded by a slightly nervous cough. And without fail it means a project has underestimated their requirements and they need you to magic something up… ideally within the next hour. Tomorrow will do.

One of the biggest challenges facing Environment Managers today is the speed that project environment requirements change. As projects become more agile, so the assumption is, should the environments that support them. However, no cash-conscious IT department will run extra environments ‘just in case’ – it doesn’t matter whether the applications are based on-premise, in the cloud or a hybrid of the two – this is just burning money. Also not every type of environment can be spun up at the drop of a hat – those with multiple integrations and specific connectivity requirements will take time if they are not part of a standard automated rig. At any given time an Environment Manager has to run the leanest ship possible, but remain flexible enough to deal with a certain ‘unspecified amount of changing requirements.’

So what is the best way I have found to handle this?

I will use the analogy of a  spiders web. In order to use the web to best effect the spider has to sit in a place where it can feel any single string vibrating at any time. The same goes for an Environment Manager. Except in our case the strings are radiating lines of communication.

Communication is probably the single biggest asset in an Environment Managers predictive arsenal. If you can build solid working relationships with people at every stage of a Release lifecycle – from the Business Analyst that shapes the projects, to the Project Managers that will run them, to the Technical resources that build them, the Testers that check them and to the Release team that puts the whole package live, you will have a far better chance of hearing or seeing about new or changing requirements before they are formally asked for. Nothing ever comes completely out of the blue.

It does take time to  build up your spiderweb (and you may get some odd looks at first from people who have never even heard of a Environment Manager, let alone spoken to one)- but I assure you -its worth it. The only downside is that after a while you will probably get a bit of a reputation with your Project teams for predicting the future.

Networking and Wallflower-itis

Social Networking is difficult.

Well it is for me.

Back in the mists of time – before I even knew that Environments Management was A Thing – I worked as a Website and Brand Designer (yes… I have a Arts degree…don’t bother asking how I got here – its very convoluted). I did this as a job for just over 3 years. One of my responsibilities was to go out to new clients and pitch, and I’ll be honest, this experience pretty much put me off direct networking. I have always found online networking far easier to get to grips with.

Continue reading

Technical Debt – having a vision of what should be

Technical debt is a problem for most IT divisions that have been running for a while. The drive for quick delivery to market forces projects to run as fast as possible in order to meet business expectations – and unless a company is very disciplined from the start- this can sometimes come at a cost of shortcuts or ‘acceptable’ defects being introduced.

On a project by project basis this probably isn’t a huge problem – so long as you are within risk tolerance, some projects can go live with known defects or workarounds – but when you start thinking that a lot of major enterprises will be running hundreds of potential projects in a year, and some applications may be several years old, you could see how this could add up if a strategy isn’t in place to handle it.

One of the sanest ways to combat this is to move to a methodology that bakes quality into the process; agile methodologies are very keen on this. However for those companies that are transitioning to agile methodologies this means they could be facing a mountain of technical debt before they even start.

Where do you even start with something like that?

I read a very entertaining blog by Jergen Moons which makes some solid suggestions about tangible ways to approach handling technical code debt. The biggest take away I got from it is to start small and make consolidated targeted improvements as part of a long term vision that works alongside future development. I recommend having a look.

Personal Development: The gift of time

I read an interesting article this morning in the Harvard Business Review.  It is a few years old now – but I think its just as true today as it was when it was published. The premise is that while leaders strongly advocate personal development and learning, they do not really allow any time for their employees to actually do any.

In a results driven environment, the long-term gains of credible personal learning are overshadowed by the short-term needs of constant delivery.

Continue reading

My take on 3rd Annual DevOps Virtual Summit #dovs17

I have never attended a virtual summit before. It was an interesting experience – like a more impressive webinar – but it is probably not a format for the easily distracted. I am on GMT and the event was EDT – so it is in the evening for me (childrens dinnertime + software methodologies = a mess!)

Other than the sweetcorn on the floor though, I was pleasantly surprised.

I stumbled across a invitation for this event on Twitter about a week ago – it is hosted by CA Technologies. It was free to sign up, and they had some interesting keynotes from businesses that have trodden the path of moving from Waterfall to Agile and beyond United Airlines, CNN, GM Financial and a few other (the full list is on the CA website here.)

The most interesting keynote for me was GM Financial as this one showed a real work in progress transformation – quite unusual for this sort of event – in my experience delegates would only see the polished final article and not the journey to get there.

The best speaker of the event was Silvia Prickel, Managing Director at United Airlines. She brought a refreshing no-nonsense, senior business stakeholder attitude to the table – again a really useful insight into how differently senior managers think to the developers and testers for a IT project of this size.

Delegates that signed up came away with some useful whitepapers and a copy of a DevOps book that I have yet to have a really good look at (so I cannot really comment on it yet). 

Here is the link to the recorded sessions if you want to check them out yourself.

Would I attend another one? Yes… I probably would so long as I could could guarantee some quiet time to do so. You don’t get the Networking experience that you would with a ‘in-person’ event – you don’t really see or hear from other ‘attendees’ bar the Q&A chat box, but if you can give it your undivided attention I think you can focus more on the information being given by the keynotes. 

That and standing on sweetcorn in socks is just nasty.