A blog about software delivery, Agile & DevOps by Mirco Hering

Monthly Archives: December 2015

If you are like me you believed since early days in your life, that the military is the example for command and control. I personally have never experienced the military by myself, but frequently I heard phrases like “We are not as strict with our command and control as the military”. Only recently after hearing from Don Reinertsen and Mark Horstman about their experiences in the military did I come to question my understanding.

“No plan survives the contact with the enemy” – from Helmuth von Moltke the Elder

So in my head I had this organisation where everything is well planned and if anything I would have associated it with the “waterfall” mentality more than an “agile” mentality. But let’s look a bit closer. In any real combat situation the enemy will behave differently to what you expect and it is very unreasonable to account for all possible details in the field. The above quote from von Moltke the Elder demonstrates that. So clearly the planning in detail and then just executing the plan approach will not work in such cases. So how does the military then operate?

The military makes sure that the soldiers understand what the goal of the mission is. Planning is being done on a high level (which mountain to take or what strategic points to take) which then breaks down into more detailed plans and not just for one scenarios. When practicing some variables get changed so that the soldiers learn to improvise and replan as more information about the situation becomes available. Does this sound familiar? It sounds exactly like the behaviour of an Agile team (with the difference that Agile teams don’t get the chance to practice their projects many times before doing it for real).

What this allows is a high-speed of decision while still adhering to a high level plan. It is possible because the organisation is aligned on the goals and high level plan. Imagine soldiers always had to wait in the field until the “project plan” is updated before they can proceed with changes to the plan. That would take way too long, so they are empowered to change as required within certain well-known parameters. By pushing decisions down to the lowest level the speed of decisions improves. And with clear parameters of what they can decide and what not, the risk of these decision is adjustable. When the lower level decisions aggregate to changes to the overall plan, then there are people at this level who can make those decisions as well (the product owners and release train engineers I guess).

I certainly think differently about the military now after hearing stories and examples that show how inherently agile they have to be. It makes for a good organisational example of combining high level plans and goals with agility and how to achieve positive results.

Here is a slide from Don’s talk with a few additional points:

I am no expert in the military so I am looking forward to your thoughts and I will surely learn from the discussion.

If you are like me, you get hundreds of emails each day and more often than not you think that you would be more productive at work without the most frequently used communication method these days. Over the years I have tuned my processes and have adopted them with functionality becoming available in Outlook (my mail client of choice). I want to share my system with the rest of the world as it works reasonably well for me and perhaps can benefit others as well.

Turn off notifications

The most important thing about emails is that they should not distract from any work you are doing. So do yourself a favor and go into outlook and turn off the notifications – and I mean all notifications: The sound, the little pop-up and the tray notifications. Any of those will cause you to get curious and quickly check the email and you will be immediately distracted. Same counts for your phone, set the phone to fetch and not push, so that your phone is not alerting you to new emails constantly by vibrating in your pocket or worse making a noise. On a regular basis when you have a break between other tasks you can check on your emails and you should put regular times in your calendar to go through your emails in one batch.

Use Rules to direct the traffic

The inflow of traffic in your inbox can be overwhelming, especially if you get notifications from automated systems (like production monitoring). So the next important step in my system is to setup rules that automatically direct emails into different folders. I have setup a whole long list of rules, but a few core rules are the following: Emails that you are CC’d on (because they are of lower priority), Emails from your boss(es) (because they are of higher priority), Newsletters (of lowest priority), emails from family (highest priority), system generated notifications (for reference only usually), meeting invites and responses. For each of these folders you can change the setting to see how many items are in the folder which gives you a good view of the unprocessed emails in each.

Filing system

Create a filing system that makes it easy to do two things: Identify your work baskets (the emails you need to do something with) and to find emails again later (some do this in one big reference folder, others prefer a more sophisticated folder structure). I will not talk about the reference folders as personal preference prevails for those, but want to share my work baskets with you. For each folder I have set it so that I see how many items are in the folder, not just the ones marked new as each item in these folders represents a backlog item whether I have seen the email or not.

Unprocessed emails (which the rules from step 2 above sort for me)

Inbox (everything rules didn’t catch)

Family

Boss

Meetings

CC’d

Newsletters

Notifications

Prioritised emails:

Immediate (items that come up within the day and need to be responded to in less than 24 hours)

Today (items I planned for today)

Tomorrow (items I am considering for tomorrow)

Soon/Backlog (items that require my action but are not time critical)

Eventually (items that I will do when I get some time)

Follow-up (items that don’t require my action, but I want to keep tracking like actions someone else is meant to do)

Use Quick Steps to file emails away

Outlook provides some very handy functions that allow you create short cuts called “Quick Steps”. For some of the main folders from the filing system (like the today, tomorrow, soon folders), you can create shortcuts which means with 1 click the email gets filed correctly. This speeds up the processing of emails up significantly.

Daily processing of emails

Now to the key three processes of dealing with emails:

Cleaning out the unprocessed emails
At least once a day, you should set time aside to go through all the unprocessed emails and process them by priority (in case you don’t get through them all). You want to clean out the folders by sorting them according to urgency. By default you want to put them into your backlog (the folder “Backlog/Soon” from earlier). If it is more urgent you put them in the folder “tomorrow” and you don’t put anything in the folder “today” for reasons I will explain below. If an email requires less than 24 hours turn around put them in the immediate folder which shows you urgent emergency emails. And of course the stuff that is not even backlog worthy goes in the “eventually” folder.

Planning for the next day
At the end of a day or in the morning of a day you go through a planning exercise. You want to go through your folders and move the items to the today folder that you want to get done within the next 24 hours. This to-do list is a closed list which you only add to during this planning session. This is what protects you from losing focus and being driven by your inbox. Once the “today” folder is empty and there is still time in the day you can go hunting for other items in your work baskets. Every day in your plan you want to go through the “tomorrow” folder at least, and then in less frequent intervals you want to cover all the other folders as well, so that you replan your overall backlog on a regular basis.

Getting things done
During the day, whenever you plan for email based work, you go through your “today” folder and get things done from that list. Remember that you should not action anything in your unprocessed folder as tempting as it might be – get the planned work done first. The only exception is the “immediate” folder that requires your attention for action.

If you follow these 3 simple steps I think you will see the burden of emails weighing less on you each day. You still pretty much have a 24 hour turn-around time for emails that are somewhat time critical but you will never feel out of control of your inbox anymore and worry about items that might be in there and are urgent and important but you failed to see them.

Archiving

The last step is archiving the emails, which is only really necessary because the size of your folders does impact the performance of outlook. I go for the easiest possible way of doing this, which is by date. Every 6 months or so I create an archive and move all emails that are older than 6 months into an archive and name it after the time period. That way I can always open it up when required. Here is where having a more sophisticated reference folder structure helps as I keep all the .pst files closed until I need them. Opening up a large .pst and waiting until search is working takes too long for me, so I prefer to be able to browse through folders where I have pre-sorted my emails by topic.

First 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!

For 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.