Impressions from YOW15

Leave a reply

YOWFirst of all, this was my first YOW conference and I have to say that I was impressed. I have not been to a conference with such a high density of great talks. I think the reason this is the case is that this conference covers a wide variety of topics while other more narrow conference like an Agile or DevOps conference have it much harder to avoid a level of repetition.

Rather than talking about a theme let me dive into the talks I attended and my takeaways from each:

Don Reinertsen on Options Theory and Agile
I will be honest I bought a ticket to YOW15 because I wanted to see Don Reinertsen talk – you might have seen my previous blog post about how impactful his ideas are for me. And this talk did not disappoint – I have at least material for four blog posts from it; things I need to rewatch, explore further and build on in my head. But here are a few glimpses of what you can learn from this talk:
How options theory explains the benefit of Agile, Why speed is so important now and becomes ever more important, how the military org-culture is misunderstood Military and how it’s not the command and control we keep hearing about.

Keynote by Adrian Cockcroft
Every talk I hear from Adrian reminds of all the important things we still have to do to build corporate cultures that truly support employees to deal with complexity. And I loved the anecdote about kids believing that the TV is broken because you cannot swipe them like an iPhone. His point that Netflix is not that much better because it has better developer but rather that those same developers used to work in other organisation where they couldn’t thrive should make us all pause and reflect on whether we really do the right things to support our employees.

Randy Shoup on Microservices
I have sat in many microservices talks, but Randy’s has been the most practical. When his slides are available I will use them as reference. Absolutely great. Clear guidance on when and where to use microservices in a very practical environment. For many of us we will likely not re-architect our applications, but find areas where they can benefit us. Look out for his slides and the recording.

Craig Smith on Agile methods
Fantastic overview of all kinds of Agile methods. I think everyone in Agile should watch this once a year to remind himself of the methods out there and how what we now consider to be in the canon of Agile has come from many different forefathers.

James Lewis on Microservices
If Randy’s talk was about the when and where, James spoke about the how. He reiterated how important it is for microservices to have mature development practices in Continuous Delivery otherwise you will fail. He made a case to remove some of the layers of testing by architecting the service right and do the final validation in production. Very interesting thought. And as far as architectural guidance go the Discworld anecdote about the family axe is a great way to explain to architects how microservices need to be constructed to replace all elements eventually and repeatedly.
The Diskworld anecdote: “This, milord, is my family’s axe. We have owned it for almost nine hundred years, see. Of course, sometimes it needed a new blade. And sometimes it has required a new handle, new designs on the metalwork, a little refreshing of the ornamentation . . . but is this not the nine hundred-year-old axe of my family? And because it has changed gently over time, it is still a pretty good axe, y’know. Pretty good.”

Jon Williams on Virtual teams
Working in complete virtual teams is not something we usually do. Jon defined what it means and how you can make it work. While I don’t think I will be in a real virtual team soon, I will surely look up the virtual team building tools he mentioned after I get a chance to watch the replay and write down the names.

Kathleen Fisher on Security
A perspective of security and how insecure our systems are. You keep hearing about vulnerabilities here and there but she brought it to life. I used to work with model checkers back in university and have not used it since. I am glad to hear they are making a real impact these days and might be one piece of the answer to an ever more complex world as the internet of things grows into our lifes.

Dan North on Organisational structure
Perhaps not the most practical talk yet – Dan mentioned he still working on it and some of the ideas require adaption advice. His skills register is however immediately useful to use someone’s self assessment and aspiration to guide the allocation to project teams. Very interesting. Challenging the common principle of persistent teams was another aspect that I need to think about a bit more to see whether I agree or not. I guess I will watch this one on replay as well. And he put one more piece in my puzzle – the adjustment of the return on investment adjusted by risk. Here is a way to try to quantify benefits of Agile and DevOps.

Dave Thomas on Agile is dead
Dave used a controversial title “Agile is dead” to reflect on the state of the industry and how we use the noun “Agile” often to sell something, while we should really use the adjective “agile” to learn how to incrementally do things better. As a consultant myself I am always torn between the ideal principle that Dave describes and which I really like and the reality I see where clients require some more concrete help. Nevertheless listening to him was a great reflection point to challenge myself on some of my beliefs.

Matt Callanan on the Wotif DevOps transformation
This was a great showcase of a DevOps transformation. Of course the practices are known and the complexities of any DevOps journey are contextual but his presentation sparked some ideas in my head that I will explore more going forward. His simple model of getting agreement across the organisation on standards and principles and then making it easy to follow them was something I really like. The automation of standards was another aspect that I hadn’t thought about before and I also liked the use of semantic versioning for the standards.

What a great conference, I will surely be back next year. Thanks goes out to the team behind the conference! Absolutely brilliant work!

DevOps Leadership Culture – Staying Cool When it is Getting Tough

1 Reply

LeadershipFor many organizations, the move to DevOps is more complicated than simply putting Agile methodologies, tools, and techniques into practice—it requires a cultural shift. This is especially true when running into the inevitable roadblocks that occur along the path to disruption. This is when IT leaders must stay the course and have faith in their DevOps vision.

In this post, I would like to talk about how IT leaders can create a culture to enable DevOps to thrive, and what the future of IT organisations might look like if they successfully stay the course.

How DevOps and Agile have evolved over the years

I find that the industry seems to have moved along the same phases of focus as myself (but perhaps that is a case of confirmation bias). Let me describe what I mean. Coming from some form of waterfall development and in a time when the best answer to productivity improvement was going offshore or using packaged software, Agile provided an alternative way to deliver projects successfully. The initial focus was on small teams of highly focused individuals and the success of those teams showed what is possible. Early successes meant that many more organizations wanted to adopt Agile and so it was adopted for larger and more complex environments.

At this stage, Agile projects got into trouble as the relatively simple recipes and the tendency toward offshoring and packaged software worked against the ideal of small, co-located teams for Agile delivery. This is where I saw the next two trends picking up: Scaled Agile Frameworks (like SAFe) and DevOps with its cultural and technical aspects. While there is a lot more to be done in this space, I can already see the broader organizational change as the next frontier. Otherwise successful Agile/DevOps teams run into problems with the funding cycles and other organizational practices at the moment. While Agile and DevOps was used in small pockets of organizations, it was easy to fly under the radar; with mainstream adoption we will now have to solve these other, more complex problems in the organization and do so while shifting the overall organizational culture.

Cultural transformation needed to become truly Agile and adopt DevOps: What IT leaders need to do

Over time I came to realize that methodology and technical practices can only get you so far. Staying the course in tough times is not easy and reality is that it’s likely going to get worse before it gets better. Leaders need to believe in their mission and support the team in times when it does not look like there will be quick wins.

There is this story about Toyota and how they introduced a cord in their factories overseas. This cord is pulled whenever there is a problem with the production system. Of course this is disruptive at first and some factories stopped using the cord because of the disruption. The ones who used it had a negative impact on productivity initially while the others continued to produce the same results as before. Management could have easily given up on the cord, but they stuck with it and over time improved their production system so much that they outperformed the other factories significantly. There was no chance for the other factories to catch up afterwards as the improvements were systematic and not just focused on fixing defects as they appeared as the other factories had done. To me this serves as a worthwhile example for management who adopts DevOps. Management needs to find ways to measure progress of the improvements and need to stay the course of systematic improvements even when productivity takes an initial hit. I have seen many transformational efforts that start well and then get stuck when disruption is necessary, which might mean some steps backwards in some regards. Here is where management can show what it means to support a vision and to stay the course. The ones who do and have the right vision will win this race.

Let me share one more piece of personal advice on cultural change. I subscribe to Dan Pink’s sources of motivation at work: autonomy, mastery and purpose. Management should look for opportunities to create a workspace where each team member can increase their satisfaction along those three dimensions. We are all knowledgeable workers in IT, and the best way to get the best out of us is for us to be highly motivated and work in line with the company vision. From talking to people in the IT industry, I often find that we have optimized work in a way that has not considered the relevant characteristics of knowledge workers, and this is likely to be the next area that will increase productivity significantly if addressed correctly.

A look at the Lean Enterprise of the future

Honestly, I think Agile and DevOps will be part of every organization in the next few years. So far, very few have really transformed their whole organization to become as lean as possible. After all, Agile and DevOps are both ways to become leaner. I think that Agile and DevOps practitioners and change agents will join forces with organizational change management practitioners to examine organizational processes. While I don’t know how the end-state looks like in detail, I have a few things in mind that I hope to see in organizations over the next few years, and I will hopefully play my part in some of those transformations. Here is what the organization of the future looks like to me:

  • HR practices have been transformed to recognize the team-based nature of work and that outcomes of the organization matter the most.
  • Financial governance has found a way to decouple funding cycles so that Agile teams can continue working as long as certain organizational results (financial and otherwise) are achieved by teams.
  • Project-based teams are a thing of the past. Teams exist as persistent entities with stable members that transcend traditional role definitions and even organizational boundaries where vendors and system integrators are involved.
  • Stakeholders across the organization have access to real-time information from both business and IT systems to steer the organization.

This post has been adopted from an interview I gave “The Enterprisers” project in the lead up to the DevOps Enterprise Summit 2015 – you can find the full interview here: https://enterprisersproject.com/article/2015/10/creating-culture-devops-thrive

Picture: Leadership vs management by Olivier Carré-Delisle
Taken from Flickr under Creative Commons license

Let’s burn the software factory to the ground – and from their ashes software studios shall rise

8 Replies

torchInspired by recent events I thought it is time to revisit the premise of my private blog (“Not a Factory Anymore”). I have recently heard of the first delivery centers being called studios and as you can imagine I was happy to hear the word studio rather than factory (Link). So I thought it’s time for an update on my pet peeve by adding supporting arguments.

First of all, before you continue reading you should read Don Reinertsen’s HBR article (https://hbr.org/2012/05/six-myths-of-product-development ) who makes a brilliant case on why manufacturing is the wrong analogy for product development (and IT development ultimately is product development). He calls out that the misconception of product development as being similar to manufacturing causes a lot of problems for organisations. I will provide my thoughts on some aspects of his article where I feel I can add value, but if you only have a few minutes and have to choose, then read his article and not my blog post (no seriously – go read his article!) – his article blew me away when I first read it and I am sharing it with every IT executive I come across.

“Product development is profoundly different to manufacturing” – Don Reinertsen

There is so much to say about this article, I could write for hours about it, but I will focus on two aspects that I want to point your attention towards because the application to IT might not be as straight forward. Both having to do with batch sizes (and batch sizes is the secret ingredient to any Agile or DevOps adoption):

Firstly the optimal batch size is determined by the holding cost (driving smaller batch sizes) and transaction costs (driving larger batch sizes). In IT the holding costs are a combination of the increasing cost of fixing a problem later in the lifecycle and the missed benefit of functionality ready but not in production. These two factors don’t change much with DevOps. What changes are the transaction costs. Deployments, Testing efforts and migration to production are all aspects that DevOps has made cheaper through automation and through using the “minimum viable process” for governance. This means that the new batch size is much smaller than before. The relationship between DevOps maturity and batch size is something that I hope people start to appreciate more.

 “DevOps is not about making IT efficient, it’s about making business effective through IT.” – Mark Rendell

The second fantastic point that Don makes, which I want to elaborate on, is about effectiveness and efficiency in the context of quality – the smaller batch sizes at fast speed might cause more defects, but these are fixed faster and the learning from it leads to a better overall outcome. As I said in many other places defects are not a bad thing as long as you find them as early as possible and use them to learn. Driving down defects is not an outcome its a side effect of better DevOps practices. With the words of a colleague of mine: “DevOps is not about making IT efficient, it’s about making business effective through IT.”

The second publication that filled me with optimism that we can bury the factory analogy soon is Gary Gruver’s “Leading the Transformation” (http://itrevolution.com/books/leading-the-transformation/ ). He also calls out that executives have to accept the fundamental difference in complexity between IT work and manufacturing. Assuming that you can plan up-front and manage IT with the same tools as manufacturing leads to inappropriate behaviors. Especially his guidance on embarking on DevOps transformations is very valuable and provides a realistic experience.

“Executives need to understand that managing software and the planning process in the same way that they manage everything else in their organization is not the most effective approach. (…) First, each new software project is new and unique, so there is a higher degree of uncertainty in the planning.” – Gary Gruver

After reading Don’s article and Gary’s book – can any executive still argue that the principles of manufacturing still applies? Do we need more evidence? Cultural change is hard and takes a long time. But hopefully the IT industry will soon be filled with application studios full of skilled, creative and motivated knowledge workers and not with factories where each developer and tester is just a cog in the machine…thank you Don and Gary for putting a satisfied smile on my face while reading your publications. I have the torch in my hands and you have given me fire – lets burn those factories down… (in a figurative sense of course)

Picture: Hawaii – by Dan Tentler (Creative Commons License)

Is the DevOps the new black?

1 Reply

(This article was first published in the JAXmagazine)

jaxenterDevOps is everywhere: you can buy DevOps tools from vendors that used to sell ALM tools, you can buy DevOps from cloud vendors who used to sell you virtual infrastructure and you can buy DevOps from consulting companies who used to sell you IT strategies… How come that on close inspection a lot of the DevOps practices and tools look eerily familiar to those earlier products they tried to sell you?

I have been working in what used to be called Development Architecture for all my career – developing IDE extension and compilers in the beginning and later on setting up tooling solutions to support delivery. Reality is that tooling and methodology will only ever be part of the answer. The hard truth is that engineering skills are important in both your DevOps team (yes I dare call the team by this name, but feel free to call it tools team, platform team, technical service team, system team or by any other name you feel is most appropriate and will offend the least people) and your development and operations teams.

DevOps is both the best and worst thing that could have happened to people who work in this space. On the one side all of sudden the work we do has become sexy. For a long time looking for labour arbitrage through offshoring or investing in proprietary or commercial off the shelf products was the answer to increasing complexity and cost pressure in projects. Good old engineering practices and supporting developers with the right tools was not sexy. Now DevOps is the new black and people want to talk to me about supporting high performance delivery through engineering practices and the right tooling to support developers. Making this important aspect of IT delivery more visible was certainly great.

But… there is the dangerous flipside. All of sudden everyone is doing it. In my consulting role I spend quite a bit of time performing assessments for clients. And I come across the Dunning-Kruger effect way more often than I expected. For those of you who don’t know about Dunning-Kruger, check it out on Wikipedia (https://en.wikipedia.org/wiki/Dunning–Kruger_effect) – in short it is the common pattern that people who don’t know much about a certain area believe to be better at it than they really are. In my case the most common symptom of Dunning-Kruger involves Continuous Integration. I walk into an organisation and start working through my assessment framework and I ask the following question: “Do you practice Continuous Integration?” And the answer is “yes we do”. Here I could move on, tick the box for continuous integration and ask for the next practice. In my experience Continuous Integration is actually quite difficult, so I dig a bit deeper “How do you know you are doing Continuous Integration?” the answer “We have Jenkins as our Continuous Integration server.” Okay they use a common tool for CI. One more question I feel will not hurt: “What do you do with Jenkins and how often does it run?” and here Dunning-Kruger hits me “We run it weekly for our development branch”. Ah yes – here we are again I think. My assessment turns into an education exercise. Truth be told, I think this is actually what good assessments do, they are an educational tool. For some it is a tool for self reflection, for others it serves as a helpful guide to have these external discussions with a coach. But all too often exactly the described contradiction of self-perception “We practice Continuous Integration” and reality “We have a Jenkins server and run it occassionally” leads to people, teams or organisations saying that they are doing DevOps.

Of course I am not free of blame. Using the term DevOps is often a handy shortcut for the large set of practices that underpin DevOps as well as the cultural shift required for it. And when are you allowed to say you are doing DevOps anyway? For me the best way to deal with this is to say that we are on the DevOps journey. And we all are. Everyone who is involved in the delivery of IT solutions is on the DevOps journey. Its hardly ever a straight line, often people wander off the path or are lost on the way and get further and further away from the goal, but we are all on the DevOps journey to improve IT delivery. Because after all that is what DevOps is all about. And yes I don’t mind it being the new black and I take the negatives that come from the hype if it means we can have the discussion on improving delivery; not just because it matters to our businesses and clients. Because it makes IT delivery a more humane place to be, it removes stress from people’s life, it makes you enjoy work more than it used to and it provides all of us in society with better solutions for all our problems from the mundane (how to better post pictures on Facebook for example) to the impactful (how to support families in disaster areas with better information through crowdsourcing for example.)

Join me on the journey, it might be a long one, but one that is worth taking the next step on…

Impressions from DevOps Enterprise Summit 2015

Leave a reply

2015-10-21 15.13.19The theme of conference was so nicely summarised by Jody Mulkey from TicketMaster “DevOps is not a technology problem” already in the morning of Day 1.  Most talks covered the cultural aspects of DevOps and what good looks like and what it takes to transform the organisational culture. Some of my takeaways to try at home to shift culture are:

  • Blameless Culture
  • Value Stream mapping
  • Minimal Viable process
  • “Red Tape Removal teams”
  • Internal Conferences/Hack Days and other avenues for informal learning
  • ChatOps as communication channel

The other topic that came up again and again was: Metrics. Everyone is looking for ways to measure progress and justify improvement investment. This certainly validated the efforts of a working group before the conference. The working group put together a paper on measuring DevOps which you can get access to here http://devopsenterprise.io/media/DOES_forum_metrics_102015.pdf I was part of the team and have to thank everyone involved for a great experience and amazing support from the team at IT Revolution.

As part of the Unconference there was a very lively discussion about metrics. I think there was some level of consensus about a few points:

  • There is not one measure to rule them all, you need multiple dimensions for steerage
  • The metrics in focus shift over time
  • You should use the scientific method and drive improvements through hypothesis and validation

There was consensus that DevOps is not a goal – “are we there yet?” is not a valid question. Jason Cox summarised it nicely in his talk: “Keep moving forward with curiosity”. That is the spirit of the conference and the overall DevOps movement.

Technology wise – I think the practice/tool that stuck with me most was ChatOps. This seems to have broken into many organisations and is a tool to change culture and the way collaboration works.

Some highlight talks for me were – and there were so many more (!):

Jason Cox – Disney: Okay as a geek it would always be hard to trump a talk that is full of Star Wars references and shows the latest trailer. But besides this he is just great in giving insights into the Disney org and how to leverage the unique company culture for the DevOps movement.

Adrian Cockcroft – Battery Ventures: A fantastic talk about systems thinking applied to organisations. Fascinating insights into the cultures of companies like Netflix. So many ideas in the talk that it requires hearing it a few times to catch it all.

Damon Edwards – DTO solutions: This talk brought everything together what we heard throughout the conference. The summary slide shows the learning organisation, the measures, the idea of a journey not a goal to reach:devops-kaizen-practical-steps-to-start-sustain-a-transformation-42-638

Jez Humble: This talk one of the most interesting metrics for DevOps progress and success: Number of manhours required outside of business hours for a production deployment – the goal needs to be 0. Overall great talk about the architecture concerns for DevOps. Its an unsung truth that architecture plays a huge role in DevOps and is difficult to change.

Steve Spear – High Velocity Edge: About leading a learning organisation. He demonstrate with examples very well that leaders have to have the courage to lead from the front in regards to learning and acknowledging that they don’t know everything. The other takeaway was the rigorous adoption of the scientific method in all aspects of the organisation and the example of Toyota showcased how such an organisation destroys the competition.

Josh Corman & John Willis: An insightful talk about vulnerabilities in software and the importance of taking this serious, not just to save money, but to save lifes!

Topo Pal – Capital One: Topo’s point of Capital One contributing their tools to open source for the community was a powerful statement. We can all benefit from being more open and sharing more with the community. Thank you Topo.

Rosalind Radcliff – IBM: Educating us on what is possible with Mainframe. One of the few talks about “legacy” and really insightful that modern delivery methods are absolutely possible with the mainframe.

Mark Rendell – Accenture: Talking about the role platform applications play in solving the organisational structure challenge of scaling DevOps.

What did I get most value out of you wonder?

100% the discussions with people in the hallway, with fellow speakers, with all the people who are on the journey with me. Looking forward to make the next steps together and share our stories again next year.

Favourite Quotes:

  • “Motion != Work” Jason Cox & Jez Humble
  • “We cant copy Netflix because it has all those superstar engineers, we don’t have the people” Fortune 100 CTO —- “We hired them from you, and got out of their way” Adrian Cockcroft
  • You are either building a learning organization…or you are losing to someone who is – Andrew Clay Shafer requoted in USPTO session
  • “We are open sourcing our tools because it is the right thing to do.” Topo Pal, Capital One
  • “Buoys, not boundaries.” Ralph Loura, HP Enterprise
  • “Too much planning means you miss out on opportunities to learn and adjust.” Gary Gruver, co-author, “Leading the Transformation”
  • “We have horrible hygiene in our software supply chain” – Josh Corman, Sonatype
  • “I am in this (DevOps) to save lives” – Josh Corman, Sonatype
  • “We had Schroedinger releases – until it was in production we didn’t know whether it was dead or not” – Elisabeth Hendrickson
  • “Project based teams accrue technical debt, product or platform based teams pay it down” – Adrian Cockcroft

What I want to see more of next year:

  • People talking about managing vendors and systems integrators
  • Experiences with learning cultures and how the experiments went
  • Even more discussion on bridging the chasm to the organisational majority

Cultural references/Running Gags:

  • Lots of Star Wars references – aren’t we all looking forward to Christmas? How fitting we had Jason speak again.
  • Volkswagen gags were also popular

DevOps for Systems of Record – A new hope (Preview of DOES talk)

2 Replies

(This post first appeared on DevOps.com – Link)

I am speaking at the DevOps Enterprise Summit later this week and thought I give people a teaser of what I am going to talk about, so that you know what to expect. I am looking forward to share my story – a story of adversity but also of hope – with many of you. ( A recording of it is available here)

So we have all heard about the DevOps and Continuous Delivery stories from our favorite Web companies (Google, NetFlix,…). It is much harder to come across successful case studies with Enterprise-grade Systems of Record. While I cannot provide the 50 times a day deployments for SAP (yet ;-)), I wanted to share my story so far and what I have learned in the journey (both in regards to solve and unsolved issues).

Hopefully this contribution to the discussion helps some of those out there who are looking for a first step. But why should we even deal with COTS and other systems of record? Ultimately for me this comes back to the two gear analogy that I keep using. If you can just ditch your “legacy” applications completely, then congratulations you don’t have to deal with this and can probably stop reading this blog post. For all of you out there that cannot do that, you will be confronted with the reality that even though your digital and custom applications can deliver at amazing speed you are still somehow constraint by your “legacy” applications. Hence speeding up those will help you achieve the ultimate terminal velocity of your delivery organisation. So how do I approach Systems of Record and the DevOps adoption of it

3 Key steps:
1. Look under the hood to find the ingredients
2. Recreate the IKEA manual
3. Understand the path to production

DOES1

  1. Initial Discovery – Let’s open the hood

DOES2Ultimately the two things that I am always looking for are the moving parts of the application and the processes to build and deploy the application. Sounds easy, right? Well it often isn’t as especially COTS application try to abstract those processes away. Look at SAP where you make configuration changes in one environment that then somehow get transported to other environments, but you have little visibility into the underlying process (Ok – my SAP experience is 10 years old, so it might have changed, but you get the gist).

Why do we look for moving parts? Well we want to use the common software engineering practices as much as we can and don’t necessarily want to trust the inbuild features for version control for example. So we look for ways to find the source code files or ways to extract the relevant information in text format (well SQL, XML, etc count as text in my world view), this is sometimes relatively easy (Siebel .sif files are just a type of XML for example) and sometimes it is pretty difficult or impossible. These underlying files is what we will store in source control to make sure we understand at each point in time the configuration of the application.

Once you have found the source code, you will have 3 things to do:
a) Get it out of the proprietary solution
b) Integrate it with your IDE
c) Solve for Merges
(I will explore this further in another blog post later)

Part 2. Recreate the IKEA manual
DOES3Once you have all the moving parts, you need to understand how it all fits together. Custom Application usually require explicit instructions which makes it much easier to define and automate the instruction set. For systems of record packaging and deployment is often done through UIs and there is usually more than one way of doing it. Experienced operators have found their own short cuts and the reliability of the system depends on having the right guy in the operating centre (I have some stories to tell about not having the right guy on go-live weekend).

Your goal needs to be an “Ikea Manual” that creates the system from the moving parts we identified earlier without requiring complex interactions or decisions from human operators. Ideally all instructions work from the commandline or some programming API, but when all else fails a UI driver like Selenium can solve the really tricky parts of creating and automating the manual. Every black-box step should be drilled open so that you understand what is happening within the system and so that you understand the variations that could cause you trouble down the path.

Part 3. Understand the Path to production
does4Speaking of paths…Of course for systems of record the same rules apply as for any other system. You should practice the exact things that you will do to establish the system in production in all previous environments and minimise the difference between configurations. The challenge for systems of records is often the cost associated with production like environments So you might have to look for creative ways to minimise the difference and to parameterise configurations so that you can at least automate for the differences.

So all is good in Mirco’s land of the systems of Record?
Unfortunately not, there are still many challenges that I am working on. The progress we have made so far, allowed for a step change in velocity and reliability, but there are still areas that I want to find better solutions for:

  • Unit test automation
  • Unsupported activities or no API
  • Performance
  • Configuration Management skills – the curse of the configurators
  • Common Objects
  • Operations – the last mile…

I will speak at much more detail about my experiences at the DevOps Enterprise Summit, if you are attending, come say Hi. I am always happy to show you the scars of working with Systems of records and share war stories.

And for two “legacy” technology stacks that I have done extensive work for (Siebel and Mainframe ) I promise to write more in-depth blog posts in the future.

The Testing Centre of Excellence is dead, Long Live the Centre of Quality Engineering

1 Reply

“Big, centralised Test Centres of Excellence are a thing of the past” – Forrester 2013

Agile clearly took the IT industry by storm. In my early days trying to bring Agile to projects a few years back I had to explain even what Agile means. Nowadays pretty much all my clients are using some kind of Agile somewhere in their organisation. Now we see the challenges of hot to support delivery in an Agile fashion and how to optimise for speed to market. One common obstacle is duration and effort for testing. Too many organisations are still relying on large scale manual inspection instead of having an optimised and automated approach to testing. Of course in most cases not everything can be automated, but it is far more common to see too little automation than to see too much automation.

“Quality comes not from inspection, but from improvement of the production process.“ – Dr W. Edward Deming

TCOE1The above picture illustrates the shift that is required to really support speed to market. Quality needs to be built into the development process from the beginning and every opportunity for early feedback should be used to avoid the late detection from manual inspection. There is so much good evidence showing that the temporal delay for finding defects is very costly. People don’t necessarily still remember what exactly they were thinking when they made a specific change a few weeks ago. Or worse the fix might even be given to someone completely different who first has to understand the context of the piece of code that he is trying to fix.

For many organisation this provides a challenge as most testing is organised centrally from a Testing Center of Excellence. This needs to change.

TCOE2Rather than having this large group of testers who are centrally organised, we need people with quality focus embedded in our Agile teams. The manual tester who just executes test scripts is a thing of the past mostly. The new roles require people who understand the business context and can come up with test strategies that minimise the risk in our application. Those test experts are the kind of people who look both ways on a one way street, they just think differently to other people and hence have a very specific mindset that we need.

“Good testers are the kind of people who look both ways before crossing a one-way street”

Besides creating test strategies they will also look after exploratory testing which finds things outside of the usual boundaries. And then we need the test automation developers who should also be embedded in the Agile teams. This decentralising of quality experts does not mean that there is no need for a central function. Test Automation requires a technical framework that should be owned by the central function. Additionally the central function should make sure that lessons learned and other experiences are being shared and that the profession of Automation Developers and Test strategists and Exploratory Testers continue to evolve. Providing networking opportunities, knowledge sharing session and more formal guidance on how to embed quality as early as possible in the development process should be the new focus. This also means to collaborate with the development and engineering teams on coding standards, on the way static code analysis is being used and what can be covered by automated unit testing. On the most basic level it is a shift from testing to quality engineering.

The nature of the central function will shift from a Testing Center of Excellence to a Center of Quality Engineering. Will this be difficult and transformation? Yes it will be and I will leave you with this thought that all TCOE practitioners (and testers for that matter) should take to heart:

“It is not necessary to change. Survival is not mandatory.“ – Dr. W. Edward Deming

A personal DevOps Journey or A Never-Ending Journey to Mastery

1 Reply

I spent the last few days at a technical workshop where I spoke about Agile and DevOps and while preparing my talks I did a bit of reflection. What I realised is that my story towards my current level of understanding might be a good illustration of the challenges and solutions we have come up with so far. Of course everyone’s story differs, but this is mine and sharing it with the community might help some people who are on the journey with me.

As a picture speaks more than a thousand words, here is the visual I will use to describe my journey.
(Note: The Y-axis shows success or as I like to call it the “chance of getting home on time”, the X-axis is the timeline of my career)

Personal Journey

The Waterfall Phase – a.k.a. the Recipe Book

When I joined the workforce from university and after doing some research into compilers, self-driving cars and other fascinating topics that I was allowed to explore in the IBM research labs, I was immediately thrown into project work. And of course as was custom I went to corporate training and learned about our waterfall method and the associated process and templates. I was amazed, project work seemed so simple. I got the methodology, processes and templates and all I have to do was following them. I set out to master this methodology and initial success followed the better I got at it. I had discovered the “recipe book” for success that described exactly how everyone should behave. Clearly I was off to a successful career.

The Agile Phase – a.k.a. A Better Recipe Book

All was well, until I took on a project for which someone else created a project plan that saw the project completed in 12 weeks’ time. I inherited the project plan and Gantt chart and was off to deliver this project. Very quickly it turned out that the requirements were very unclear and that even the customer didn’t know everything that we needed to know to build a successful solution. The initial 4 weeks went by and true to form I communicated 33% completion according to the timeline even though we clearly didn’t make as much progress as we should. Walking out of the status meeting I realised that this could not end well. I setup a more informal catch-up with my stakeholders and told them about the challenge. They agreed and understood the challenge ahead and asked me what to do. Coincidence came to my rescue. On my team we had staffed a contractor who had worked with Agile before and after a series of coffees (and beers for that matter) he had me convinced to try this new methodology. As a German I lived very much up to the stereotype as I found it very hard to let go of my beloved Gantt charts and project plans and the detailed status of percentage complete that I had received from my team every week. Very quickly we got into a rhythm with our stakeholders and delivered increments of the solution every two week. I slowly let go of some of the learned behaviour as waterfall project manager and slowly became a scrum master. The results were incredible, the team culture changed, the client was happier and even though we delivered the complete solution nowhere close to the 12 weeks (in fact it was closer to 12 months), I was convinced that I found a much better “recipe book” than I had before. Clearly if everyone followed this recipe book, project delivery would be much more successful.

The DevOps Phase – a.k.a. the Rediscovery of Tools

And then a bit later another engagement came my way. The client wanted to get faster to market and we had all kind of quality and expectation setting issues. So clearly the Agile “recipe book” would help again. And yes, our first projects were a resounding success and we quickly grew our Agile capability and more and more teams and projects adopted Agile. It however quickly became clear that we could not reduce the time to market as much as we liked and often the Agile “recipe book” created a kind of cargo cult – people stood up in the morning and used post-its and consider themselves successful Agile practitioners. Focusing on the time to market challenge I put a team in place to create the right Agile tooling to support the Agile process through an Agile Lifecycle Management system and introduced DevOps practices (well back then we didn’t call it DevOps yet). The intention was clear, as an engineer I thought we could solve the problem with tools and force people to follow our “recipe book”. Early results were great, we saved a lot of manual effort, tool adoption was going up, and we could derive status from our ALM. In short, my world was fine. I went off to do something different. Then a while later I came back to this project and to my surprise the solution that I put in place earlier had deteriorated. Many of the great things I put in place had disappeared or had changed. I wanted to understand what happened and spent some time investigating. It turned out that the people involved made small decisions along the way that slowly slowly lost sight of the intention of the tooling solution and the methodology we used. No big changes, just a death by a thousand cuts. So how am I going to fix this one…

The Lean Phase – a.k.a. Finally I Understand (or Think I do for Now)

Something that I should have known all along became clearer and clearer to me: Methodology and tools will not change your organisation. They can support it but culture is the important ingredient that was missing. As Drucker says: “Culture eats strategy for breakfast”. It is so very true. But how do you change culture… I am certainly still on this journey and cultural change management is clearly the next frontier for myself. I have quickly learned that I need to teach people the principles behind Agile and DevOps, which includes a elements of Lean, Systems Thinking, Constraint Theory, Product Development Flow and Lean Startup thinking. But how do I really change the culture of an organisation, how do I avoid the old saying that “to change people, you sometimes have to change (read replace) people”. As an engineer I am pretty good with the process, tools and methodology side, but the real challenge seems to lie in the organisational change management and organisational process design. And I wonder whether this is really the last frontier and or will there be a next challenge right after I have mastered this one…

The good news is that many of us are on this journey together, and I am confident that on the back of the great results we achieved with tools and methodology alone, truly great things lie ahead of us still as we master the cultural transformation towards becoming DevOps organisations.

The most Controversial Concept in Agile Delivery – Estimating in Story Points

3 Replies

This blog post is another one of those that I should have written a while ago as the topic of story point based estimation keeps coming up again and again. To really understand why story point based estimation is important for Agile delivery, I think I need to explain the idea behind it.

The purpose of estimates is to get a good idea of how much work needs to be done to achieve a certain outcome. To do that, the estimate should be accurate and reasonably precise. This is where the crux of the problem is: precision. If I’d asked you how long it takes to fly from Sydney to Los Angeles, you would not respond with an estimate that includes minutes and seconds because you know that it is ineffective as it is not precise. The more precise we get in estimates, the more we pretend to be able to do something that we cannot do: work at that level of precision. The other downside of precision is that each level of precision requires more work to be put in the estimation process. I have done many IT projects and can tell you that my estimates for each individual task is off by as much as +/- 100% easily, but in aggregate my estimates are pretty good.

Let’s explore the difference between accuracy and precision a bit further:

accurate vs precise

It should be clear that we care more about accuracy than we care about precision and that is exactly what story points do for me. I am spending just the necessary amount of time estimating to be reasonably accurate without trying to become too precise. The usual Fibonacci sequence (1,2,3,5,8,…) helps to avoid false precision as well. Now, to be honest we could call it 1,2,3,5,8 days and be done with it as that would probably achieve the same outcome as story points. The problem is that for some reason we are a lot more tempted to use the other in between numbers when we talk about days. We are also tempted to equate days of effort with schedule, and most of us can attest that a day of effort is hardly ever done in a day of schedule as we get distracted, multi-task or attend meetings. The story point concept provides us with a nice abstraction that prevents these mental shortcuts and keeps us focused on the relative nature of the estimate.

The other thing that should be obvious is that a day of effort for one person is not the same as a day of effort for another person. More experienced people need less time than more junior people, so any estimate in hours or days is flawed unless you know who will do it. Story points do not suffer from this problem as they are relative to other stories and independent to the person performing the tasks associated with it.

The other nice thing with Agile estimation is that it usually is a lot closer to the often recommended Delphi technique, which asks multiple independent experts to estimate tasks and then aggregate it. Planning poker is a pretty close approximation of the Delphi technique and is therefore much more accurate than estimates done by individuals.

But why do we need a point system at all, why do we not just do relative sizing in t-shirt sizes or something similar. As I have explored in another blogpost (link), teams need a goal line whenever there is a certain outcome to be achieved. The easiest way to do so is by tracking progress on a numerical scale (see Agile reporting post). And if you work in a larger organisation you probably want to have some common currency to be able to measure the throughput (see productivity blog) and be able to swap stories between teams. Here I will go with the guidance that SAFe provides, start with a point being roughly a full day of work and estimate everything else relative to that. On a regular basis bring members of the team together to estimate an example set of stories and use this process to recalibrate the relative understanding of size.

So what if things change? One thing that people are always concerned about is scope creep or inaccurate estimates. For a story by itself I don’t have strong opinions on whether or not you update the size once you realise there is more or less work than expected. However, if you use larger buckets for your initial estimates (e.g. a feature that should roughly take you 100 pts), then I think it is important to measure how many points the stories of that feature actually add up to – if that is different to 100 pts in this case you have some real scope change that will impact your timelines.

To close off, I will provide a few helpful links to other comments/blogs about story points which you can use to learn more about this topic:

http://www.scruminc.com/story-points-why-are-they-better-than/

http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf

http://www.mountaingoatsoftware.com/blog/seeing-how-well-a-teams-story-points-align-from-one-to-eight

https://www.scrum.org/Forums/aft/564

http://www.mlcarey321.com/2013/08/normalized-story-points.html

http://blogs.versionone.com/agile_management/2013/10/14/scalable-agile-estimation-and-normalization-of-story-points-introduction-and-overview-of-the-blog-series-part-1-of-5/

Mirco’s Advice for supervisors – Feedback, the best way to improve your team

3 Replies

adviceAfter discussing one-on-ones in my last blog about tools for supervisors, this blog will focus on feedback. Feedback is your opportunity to improve the performance of your team on a daily basis. Here I am talking about ongoing feedback you can give your team every day, not the kind of feedback you give once a performance year. Before I get to feedback let me remind you that this post is one in a series of six posts on tools for supervisors:

  1. One on Ones (link)
  2. Feedback
  3. Coaching (TBD)
  4. Delegation (TBD)
  5. Principles for success (TBD)
  6. Pitfalls for supervisors (TBD)

While one-on-ones are probably the most important practice given the impact it has on your team, feedback is what moves your team forward. The most important point about feedback is to never give feedback when you are angry. The way you communicate and what you say when you are angry will undermine the overall idea behind feedback – to make your team more effective in the future. There is nothing you can do about the past, move on and provide constructive feedback. You should only give feedback when you are able to smile while doing so. This will make sure that you are in a positive frame of mind.

There is a good reason to be in a positive frame of mind when giving feedback. If you think about it, how often is a mistake made on purpose? – it hardly ever is. So assume good intent. There are very few people who make mistakes on purpose. This of course means that there is no reason to get angry, just try to help your direct-report become more effective by pointing out the ineffective behaviour and discussing alternatives. I will tell you how to do that further below.

Let’s not forget that you should also give positive feedback. Some tend to forget this even though it is so much easier to give positive feedback. For it to really make an impact, make sure to be specific about positive feedback as well. Don’t just praise “Well done”, but rather give specific positive feedback like “When you prepare meeting notes and send them out before I even ask you, it helps everyone stay on top of their assigned tasks. Thank you.”

Purpose: The purpose of feedback is to encourage effective behaviour in the future. There is no “why” in feedback, which means you are not trying to understand why something happened, but instead trying to encourage effective behaviour in the future. This is not a root cause analysis. If you take this purpose to heart you will see that there is little difference between positive and negative feedback, you simply state what your direct-report did, the impact it had and what to do in the future (either continue or change behaviour).

How to Do: Feedback is not easy to give, especially negative feedback. The key here is to focus on the behaviour and not implied traits: e.g. “When you raise your voice and make sarcastic comments” is much better than “When you act like a jerk”. Make sure the person you give feedback to understands the implications, e.g. “When you send me your status on time, it allows me to collate the report quickly and be on time for my report to my boss”.

Don’t argue with your direct-report about either the reason for his behaviour or the validity of your feedback. Remember the purpose of feedback is to influence future behaviour. If he argues with your feedback, walk away, he will either do the same thing again and you can give him the same feedback again (this time with one more piece of evidence) or he won’t do it again (which means your feedback has achieved its purpose). The guys at manager-tools.com refer to this as “shot across the bow” and this piece of insight was eye opening for me and made me avoid so many unnecessary and ineffective discussions with my direct-reports.

There is a specific format that you could use to give feedback: Ask first “Can I give you some feedback?”, then focus on behaviour “When you do x, this is what happens”, and then either thank him and encourage him “Thank you, keep doing this” or ask for an improvement “Can you do this better/different next time?” Timing of feedback is also important, don’t give feedback on things that happened longer than a week ago. Consider feedback like breathing, many supervisors hold their breath and then blast it out after a while (or even just at the end of the year), try to breathe regularly. Small bits of regular feedback will allow you to keep correcting course and not try to turn the whole ship around twice a year.

One last piece of advice: Find a way to encourage yourself to give feedback frequently. Put a reminder in your calendar every day to give feedback, put a comment on your one-on-one tracking sheet to provide feedback, or do what the guys at manager-tools recommend: Put 3 coins in your left pants pocket and every time you give feedback move it to the right pocket. At the end of each day you know whether you gave 3 pieces of feedback and each time you put your hands in your pocket you get a little reminder of how you are tracking.