Knowledge Bird

Create. Curate. Collaborate.

April 2, 2015
by Aprill Allen
0 comments

From customer experience to employee engagement

Recently, I was lucky enough to be a voluntary participant for a customer experience study at a cafe. (The things one can do when one is between contracts.)

I hadn’t been to a STREAT cafe before, so I was the ultimate “potential customer”—able to play the role of the person who was walking in for the first time. STREAT want their customers to understand how every mouthful helps youth homelessness and disadvantage, but they also want their customers to keep coming back and to know about their other services. As a first-time customer, there’s a lot of information STREAT would like me to take in—the difference I could make to a young person’s life by buying my coffee there, the locations of other stores, where the food is sourced, how the program works, how I can contribute more, catering services, the cook book I could buy, and the menu.

The customer experience team had a small group of us consider two different scenarios and talk about the customer journey from the street, to the counter, to the table, and back out again. Where would the opportunities be to show customers what they need to know? What changes could be made to improve turnover for the management team? And how would any of these changes improve the experience of the trainees the program actually benefits?

It’s the kind of journey we don’t often, if ever, take in the corporate world and it’s impacting employee engagement.

Next time you feel like doing a little management-oriented research, walk out of your building and go and get your coffee, (from STREAT, if there’s one nearby. ;) ) Then, retrace your steps with open eyes and a fresh perspective. What does it feel like to walk in the front door—is it welcoming or intimidating? If you’re the hiring manager, do you make sure you’re there to show your new team member around? After all, your face will be familiar from the interview. What’s your process for explaining the logistics of a role to new staff—is the information all in one place and easy to find and navigate? Do you have buddies/mentors/senseis to smooth out that awkward new employee phase? Do all your employees feel connected to the purpose of your organisation? Because if they don’t, they’ll move on.

March 9, 2015
by Aprill Allen
0 comments

205 year old organisation meets the future head-on

Coming up this week in Melbourne is the Innovating IT Service conference. The final interview in this series is with Cameron Gough, General Manager of Australia Post’s Digital Delivery Centre. Cameron will be appearing on the discussion panel and delivering one of the opening keynotes on Wednesday. He’s been with AusPost since 2012 and brings extensive experience with agile and lean methodologies to an organisation under pressure to find new ways of providing value.

 

1. As the General Manager of the Digital Delivery Centre for Australia Post, can you describe what your typical day looks like and the kinds of projects you’re involved in?

Someone recently told me that they saw my role simply as food, water and alignment.  I was at first a little offended but when I thought it through, it kind of made sense.  Most of my time is about ensuring our teams in the DDC are set up to be successful.  This means ensuring funding is in place, a healthy backlog of work exists, we have the right staff and our operating model is working smoothly.  I guess this is the food and water part.  We are heavily focused on enabling our teams to become more and more autonomous over time.  But this can be dangerous if multiple teams are misaligned in their overall purpose. So the alignment bit is about driving our strategic direction in digital and sharing this with teams to ensure we are all aligned and working to a common purpose.

On the question of projects – we’re steadily moving away from the traditional project model where we have a start, middle and an end and deliver a defined piece of scope.  The market and our customers are simply moving too fast for this model – especially in digital. Over the past couple of years we’ve been shifting to a model where we identify opportunities and allocate delivery capacity (and funding) to chase those opportunities.  The teams work in an iterative manner, deploying as often as they can, learning through customer feedback and research and adjusting course based on this.  I haven’t checked our recent mix but late last year around 75% of our work was done using some form of this model.

The work we do is surprisingly varied and quite exciting.  Around 50% of our desktop and mobile traffic relates to parcel tracking so we are always looking to improve that experience. An example is our recent roll out of MyPost Deliveries – a free service that provides more convenient parcel delivery options through parcel lockers and Post Office pickup.  This is just the start with many planned enhancements coming in the next few months.  Beyond that, we are continuing to invest in our digital mailbox, travel related products, a cool postcards mobile app, our developer centre, a parcel lodgement capability for merchants, new consumer and business portals and much more.

2. Australia Post’s traditional business model has been significantly disrupted by technology and the online economy. What are some of the unexpected opportunities that have come from that, and how are you changing the way people manage mail and interact with other Australia Post services?

Digital disruption has had a profound impact on our core letters business which has been in decline since 2008.  However digital has also been a key driver of growth in other parts of our business – especially our parcels business which has grown well off the back of a booming online economy.

I think one of the profound shifts we will start to see is a move to delivering to people rather than addresses.  This means building services and capability to deliver to the place and time that is most convenient to customers.  Smartphones and other technology leaps have started to open up many opportunities in this area.

It is hard to predict all the ways that digital will help our future business and customers and in many ways we don’t want to lock ourselves into a few narrow bets.  We are therefore taking a platform path where we expose capability through APIs and then free teams up to reimagine the experiences we can offer.  This is extending now to third parties and customers who can explore our available APIs through our Developer Centre (developers.auspost.com.au).

We’re also exploring some interesting opportunities where digital can enhance the physical experience.  For example, a more integrated in-store experience through use of iBeacons and using smartphones to streamline access to Parcel Lockers.

3. You are known as an advocate for the Scaled Agile Framework (SAFe). How does that differ from the Agile methods some of us may already be familiar with?

To me, Agile methods work well at a team level.  They provide a great way for a business to iteratively evolve a solution and arrive at an outcome that is a better match to customer needs than more traditional methods.  I think the mistake many of us made was to then believe we could simply scale the team model to work at a broader organisational level. The better path was to get back to the underlying principles of Lean and Agile – principles of flow, small batch sizes, iterative evolution of solutions, delivery cadence, multi-functional teams, etc – and then see how these could be applied at an organisational level. SAFe does a really good job of describing a cohesive model that aims to do just that. Using an industry framework has provided us with a common model, language and consistent base to work off.

Most large organisations are complex and achieving organisational agility spans well beyond delivery teams. There is often a desire for some level of structure and process around any new way of working before it is accepted.  Simply saying you are going to “scale agile” won’t get far as it doesn’t satisfy this need and can be a high risk approach. The structure and discipline that SAFe outlines is a powerful way to communicate a different way of working that covers how work is organised, funded and governed. It actually provides direct line of sight from portfolio planning through to the features teams are working on that will be delivered to customers. Having said that, we couldn’t say we follow SAFe to the letter. For us it is more a reference model that we have used to guide us but we are really carving our own path.

4. Gartner calls for enterprises to embrace a Bimodal approach to IT services. This combination of slow and fast development, (also called 2-speed IT), can be a challenge for large organisations. How is Australia Post managing it?

I haven’t delved into this deeply but am familiar with the idea.  I guess the starting point is to work out whether your organisation is pursuing 2 speed IT as a strategy, or whether it is a stage you go through as you change to a more nimble IT organisation.  I’m keen on the latter approach.  It is easier to speed up things in Digital relative to other parts of the IT organisation. We have invested in “cloudifying” our digital applications, automating integration and deployment capability, and building a highly adaptive and flexible delivery model.  This is paying significant dividends now in terms of delivery speed, flexibility and customer outcomes.  Moving beyond digital, our recent enterprise investments in new data centres, networks, cloud, automation and orchestration capabilities, are now supporting significant improvements in other areas as well.  We have also been working successfully to a model called “Differentiated Delivery” that provides a way to bring digital and backend teams together to deliver software in an iterative manner with all the benefits that provides.

5. Andrew Walduck, your CIO, has talked a lot about digital disruption and how this is fundamentally changing Australia Post’s business and the relationship it has with its customers.  How does the Digital Delivery Centre fit into this picture and the longer-term vision for the organisation?

Digital disruption is continuing to drive rapid changes in customer behaviour and Australia Post’s challenge is to evolve our 205 year old organisation to meet the needs of today whilst ensuring it drives sustainable growth in new products and services.  Improving the way the organisation creates and executes new ideas, whether that is from our front-line customer facing staff or our staff based in headquarters, is an important area of focus.

This results in improvements in how we serve and enable our customers and communities. One area is through our customer connect platform which is a suite of API’s and a support community that enables our customers and third parties to explore and innovate around new products, services and customer experiences. Our digital teams have been at the heart of these changes and continue to work hard to bring these and many other solutions to life.

6. If you could say one thing to prepare IT managers and CIOs for the changing paradigm, what would that be?

Disruption is happening at an ever increasing pace and it is no longer enough for organisations to respond by simply reorganising around the next set of profitable products and services.  Successful organisations will be those where innovation and adaptation are an inherent part of their culture and way of working.  IT needs to be part of this.  So if there was one thing I’d leave with IT managers and CIOs, it would be this: “build a culture and environment where the creative capacity of your staff and organisation can be set free”.

 

Cameron, thanks so much for taking the time!

February 8, 2015
by Aprill Allen
0 comments

Can IT rise from the ashes of a bad reputation?

I’m delighted, this week, to bring you an interview with Gene Kim. Gene will be presenting one of the opening keynotes at the Innovating IT Service conference, and a workshop. He has been a founder, CTO, and author. Gene loves finding and fixing bottlenecks which impede and frustrate the entire organization, enabling management from each tribe to achieve the greater organizational goals.

1. Your keynote for the upcoming conference asserts that everyone needs DevOps. How do you explain what DevOps is to an IT manager working in a traditional enterprise IT environment?


My definition of DevOps is the following: it is the set of cultural norms and technical practices that enable organizations to have a fast flow of work from Development through Test and deployment, while preserving world-class reliability, availability, and security.

These norms and practices are what enable organizations to do hundreds, thousands, or even tens of thousands of deployments per day. This used to be associated with “unicorn” organizations such as Amazon, Netflix, Google, and so forth. But increasingly, large, complex organizations such as Nordstrom, Macy’s, GE, Raytheon, and even the US Department of Homeland Security are adopting these practices and replicating the unicorn-like outcomes.

Many of us, especially in the service management community, believed very deeply that you couldn’t be agile and reliable at the same time. And yet what we found in our benchmarking of over 14,000 organizations, is that not only is this possible, the only way that you can have high reliability is to be doing smaller deployments, far more frequently.

Here’s what we found in the benchmarking (citation: http://www.slideshare.net/realgenekim/2014-state-of-devops-findings-velocity-conference):

 

* Agility metrics

* 30x more frequent code deployments

* 8,000x faster code deployment lead time

* Reliability metrics

* 2x the change success rate

* 12x faster MTTR

* Organizational performance metrics

* 2x more likely to exceed productivity, market share, and profitability goals

* 50% higher market capitalization growth over three years

DevOps transforms how we work, whether we are in Development, Test, Operations, or even Information Security.

I’ve been studying high-performing technology organizations since 1999, and there is no doubt in my mind that DevOps is something genuinely transformative.

 

2. In The Phoenix Project, Bill Palmer and John Pesche are representative of the ongoing struggle between rapid deployment and security management. What kind of work do organisations need to do to make that partnership work?


This is a great question, Aprill. There are two chronic struggles that we tried to portray in The Phoenix Project: the first was the constant battle between Development and IT Operations, where Development would always want to go faster, but would often cause chaos and destruction downstream. The natural reaction, of course, is that Bill (the VP of IT Operations) wants to slow down the rate of change. Now you have Development and IT Operations at odds with each other.

The other chronic struggle is between the entire organization and Information Security, as embodied by John (the Chief Information Security Officer). John believes, often rightly so, that everybody is more worried about their own work, and never properly integrates security requirements or testing into daily work. Unfortunately, the outcome is that John is always viewed as being in the way, trying to slow everybody down, creating meaningless bureaucracies that sucked the will to live out of everybody in their path.

We all laugh at these situations, but I think for many of us, these situations are all too real and all too commonplace.

The reason why I’m so excited about DevOps is that it allows everybody to achieve goals and outcomes that we didn’t think possible—even five years ago.

3. Speaking of John Pesche, what thoughts did you have to explain his reappearing clean-shaven and helpful after going so far off the rails?

Haha! I’ve actually gotten some e-mails from people who scold me for putting Information Security in such an unflattering light. A friend of mine actually even wrote, “How dare you humiliate our profession. Whether you like it or not, Gene, you are still in information security practitioner.”

In actuality, John is my favorite character. A friend of mine, Jez Humble, said the real “phoenix” in The Phoenix Project is John. He transforms, seemingly overnight, from a shrill, hysterical, bottom-up controls person, to a person who seems to be willing to take risks that the rest of the organization is too scared to make.

For example, John proposes to outsource all of their cafeteria point-of-sale systems, so that there will be no cardholder data for them to protect. He actually reduces the number of security controls, because he realizes that there are downstream manual controls that can achieve the control objectives.

Frankly, I love the fact that John has such a dramatic visual transformation, as well.

 

4. You talk about the need for various IT teams within an enterprise to come together and build “super-tribes” to maximise throughput. To quote Seth Godin, “A tribe is a group of people connected to one another, connected to a leader, and connected to an idea… A group needs only two things to be a tribe: a shared interest and a way to communicate.” What is it about our workplaces that can make these two ingredients so hard to find, and is that a problem limited to IT?

Especially in IT Operations, we tend to have a very functional orientation—departments and silos to concentrate our specialties. For example, we may have a database team, a storage team, a networking team, a server team. And whenever we want to do significant work, like a code deployment, we may have to do 50 different handoffs. Functional orientation is typically done to “optimize for cost.”

The opposite is what we call “market orientation,” that allows us to “optimized for speed.” These organizations tend to be flat and composed of multiple, cross-functional disciplines (e.g., marketing, engineering, etc.), which often leads to potential redundancies but allows us to respond quickly to customer needs. This is how many DevOps organizations operate. In extreme examples, each service team is simultaneously responsible for feature delivery and service support.

You can see the DevOps bias towards “market orientation” in these pithy quotes from two friends of mine:

“The root of most DevOps problems comes from silos: siloed groups, siloed thinking, siloed culture, siloed tools.” — Damon Edwards

“DevOps means caring about your job enough to not pass the buck, wanting to learn all the parts as a whole, and not just your little world. Developers need to understand the infrastructure, Operations people need to understand code, people need to actually work with each other and not just occupy space next to each other.” — John Vincent

 

5. When I talk to devs and ITIL comes up, they roll their eyes and speak of the bureaucratic bottleneck of change management. Is there a good place for ITIL in these conversations or is it time to move on?

Ha! For over a decade, I’ve been a fan of ITIL (IT Infrastructure Library). It describes extremely well the underpinning processes we all need to deliver reliable service. But we all know people who will take ITIL very literally, and put in all sorts of bureaucracies that burdened everybody, just like John the CISO.

Although many people view DevOps as backlash to ITIL or ITSM (IT Service Management), I take a different view. ITIL and ITSM still are best codifications of the business processes that underpin IT Operations, and they actually describe many of the capabilities needed into order for IT Operations to support a DevOps-style work stream.

Agile and continuous integration and release are the outputs of Development, which are the inputs into IT Operations. In order to accommodate the faster release cadence associated with DevOps, many areas of the ITIL processes require automation, specifically around the change, configuration, and release processes.

The goal of DevOps is not just to increase the rate of change, but to successfully deploy features into production without causing chaos and disrupting other services, while quickly detecting and correcting incidents when they occur. This brings in the ITIL disciplines of service design and incident and problem management.

Think of DevOps as the service managers dream: releases are almost completely automated, there is rigorous automated testing that gives us confidence that errors will be caught long before it gets into production, and when errors do occur, we can detect and correct for them quickly.

Moreover, our configuration management database (CMDB) is created for every application and service automatically, and it is always up-to-date, and Development and Operations are working together to fix known errors and pay down technical debt.

My advice: Let’s not get hung up on literal definitions. Let’s figure out how to get fast flow and painless and successful releases.

 

6. How do you recommend organisations transitioning into a DevOps environment keep their support teams up to date on deploys?

All too often in software development projects, Development will use up all the time in the schedule on feature development. This leaves insufficient time to adequately address IT Operations issues. Shortcuts are then taken in defining, creating, testing—everything that the code relies upon, which includes the databases, operating systems, network, virtualization….

This is certainly one of the primary causes for perpetual tension and suboptimal outcomes between Development and IT Operations. The consequences of this are well known: inadequately defined and specified environments, no repeatable procedures to deploy them, incompatibilities between deployed code and the environment, and so forth.

In this pattern, we will make environments early in the Development process, and enforce a policy that the code and environment be tested together. When Development is using an Agile process, we can do something very simple and elegant.

According to Agile, we’re supposed to have working, shippable code at the end of each sprint interval (typically every two weeks). We will modify the Agile sprint policy so that instead of having at the end of each sprint just shippable viable code, you also have to have the environment that it deploys into—at the earliest sprint, so we’re talking sprint 0 and sprint 1.

Instead of having IT Operations responsible for creating the specifications of the production environment, they will build an automated environment creation process. This mechanism will create the production environment, but also the environments for Dev and QA.

By making environments (and the tools that create them) available early, perhaps even before the software project begins, developers and QA can run and test their code in consistent and stable environments, with controlled variance from the production environment.

Furthermore, by keeping variance between the different stages (e.g, Development, QA, Integration Test, Production) as small as possible, we will find and fix interoperability issues between the code and environment long before production deployment.

 

Thank you, Gene!