Team Tips – 12 {Lean, mean, machine}

One part of my consulting and training life deals with IT Service Management. Those are the principles and practices associated with the view that an IT department is a provider of services to its business counterparts which improve the value and potential of business outcomes. Usually good IT Service Management is achieved by adopting best practices from a framework such as CobiT or the IT Infrastructure Library (ITIL).

In fact it was the need for teams of IT staff to adopt and adopt ITIL Service Management processes for their own use that made me realize that what I thought I knew about team building and team work was truly inadequate.

Let's get a group of people, toss them in a boardroom, and call them our process development team.  -Great idea! 

Let's use all the classic organizational methods to facilitate their working together, making decisions, building trust, becoming productive.  -Yes!

Except it very rarely works.

Similarly the Agile software development methods and Scrum in particular depend upon “self-organizing teams”. But the question remains: HOW do we build a self-organizing team?

Hold that thought.

A key element of the ITIL Framework is the principle of continual improvement drawing on W. Edward Deming's work which was foundational to the entire Quality Management world. In that context you might have heard of the Toyota Motor Corporation?

Toyota's focus on continuous improvement breaks down into three basic principles:¹

• Challenge: Having a long term vision of the challenges one needs to face to realize one's ambition (what we need to learn rather than what we want to do and then having the spirit to face that challenge). To do so, we have to challenge ourselves every day to see if we are achieving our goals.
• Kaizen: Good enough never is, no process can ever be thought perfect, so operations must be improved continuously, striving for innovation and evolution.
• Genchi Genbutsu: Going to the source to see the facts for oneself and make the right decisions, create consensus, and make sure goals are attained at the best possible speed.

Respect For People is less known outside of Toyota, and essentially involves two defining principles:²

• Respect: Taking every stakeholders' problems seriously, and making every effort to build mutual trust. Taking responsibility for other people reaching their objectives.
• Teamwork: This is about developing individuals through team problem-solving. The idea is to develop and engage people through their contribution to team performance. Shop floor teams, the whole site as team, and team Toyota at the outset.

Another call for team building and effective team work.

Hold that thought, too. Please.

The last thread in this tangle (for this post) is the growing interest in applying “Lean Manufacturing” principles (from companies such as Toyota) to IT organizations. This prompts IT groups to look at and study Six Sigma concepts, and “Lean IT” all of which centers around measuring defects in service delivery and reducing waste (muda).

Again from Wikipedia re: Lean Manufacturing, the original seven muda are:

• Transport (moving products that are not actually required to perform the processing)
• Inventory (all components, work in process and finished product not being processed)
• Motion (people or equipment moving or walking more than is required to perform the processing)
• Waiting (waiting for the next production step)
• Overproduction (production ahead of demand)
• Over Processing (resulting from poor tool or product design creating activity)
• Defects (the effort involved in inspecting for and fixing defects)

• Later an eighth waste was defined by Womack et al. (2003); it was described as manufacturing goods or services that do not meet customer demand or specifications. Many others have added the "waste of unused human talent" to the original seven wastes.

Anyone with any experience in an IT operation of any size will recognize most, if not all, of these problems occurring in managing the IT infrastructure, in group interaction, with programming bugs, and poor communication with the business customers. So I get asked if I can help here too.

Now what?

Behind the first door we have the need for self-organizing teams. Behind the second door the requirement to be continually improving. Behind the third, the quest to reduce waste in our organizations.

What if we could address all three of these issues? What if we could open all these doors and not get eaten by the tiger?

Nah! Can't be done! Rubbish!

Well ...

Check out the Core Protocols as a means to building self-organizing teams, dealing with all the questions of waste, and continually improving your results and satisfaction. And more.

When people start to notice your results with these simple rules and tools, and you become famous because your team is a Lean, Mean, Machine, just tell them you're a genius ... because you were smart enough to try the Core Protocols.

1 From: http://en.wikipedia.org/wiki/Lean_manufacturing

2 Also from: http://en.wikipedia.org/wiki/Lean_manufacturing

ITIL in The Cloud - 3

ITIL in The Cloud (part 3)

In this series I have been discussing the usefulness of the ITIL Framework when dealing with the model of computing referred to as “the Cloud”. (Definition provided in part 2).


It's always interesting to see a tidal wave of articles about a phenomenon where the terminology or jargon is readily waved about, positions are staked out, bets placed, opinions posited before we even come to terms with what the topic actually is about.


For example:


From “CIOs lack adequate cloud computing knowledge"
http://www.itworldcanada.com/news/cios-lack-adequate-cloud-computing-knowledge/143661?sub=390801&utm_source=390801&utm_medium=dailyitwire&utm_campaign=enews
By:  Stephanie Overby    -   02 Aug 2011

A survey of cloud providers and outsourcers returns some embarrassing scores on the cloud skills of IT executives. 

Traditional IT outsourcing customers are struggling with cloud computing, according to IT service providers and outsourcing advisors surveyed by KPMG Sourcing Advisory. IT service providers and advisors rated their IT executive customers' facility with various aspects of cloud computing on a scale of one to five, where one represented "very unskilled" and five represented "very skilled." IT executives earned embarrassing scores from their providers and advisors: None garnered even a middling score of three. 

When it comes to managing and governing cloud initiatives, IT leaders earned their lowest scores from respondents: 1.69 from advisors and 2.19 from providers.

(Note the precision in the scores of two places of decimal – very scientific indeed! Unfortunately we aren't given the sample size or information on the demographics.)


The article continues to point out that it is the pace of technology change, including the development of the Cloud environment, that is a big difficulty, and that the IT management skills required need to be learned and practiced more.


Hmmm. Smells like a framework of best practices in this area could be helpful.


A framework like, say, ITIL (Information Technology Infrastructure Library)?


And how could that learning and increased used of the best practices help?


According to the National Institute of Standards and Technology in the U.S. the Cloud has

• five essential characteristics (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured Service)
• three service models (Cloud Software as a Service (SaaS), Cloud Platform as a Service (PaaS), Cloud Infrastructure as a Service (IaaS))
• and, four deployment models (Private cloud, Community cloud, Public cloud, Hybrid cloud)
• key enabling technologies include: (1) fast wide-area networks, (2) powerful, inexpensive server computers, and (3) high-performance virtualization for commodity hardware

Compared to that list of essential characteristics, ITIL practices can be applied

• in understanding the customer demand for self-service, profiling the IT Service Provider's resources and capabilities to meet that demand, managing the customer & supplier interface
• in determining the network access policies, procedures, security requirements, contingency planning
• in managing capacity and availability not just of the technical infrastructure but of all the resources and capabilities of the organization
• in ensuring changing customer requirements are well managed through responsive change management and deployment
• in determining and monitoring service levels and performance to those targets

With respect to Service models, ITIL is all about IT Services – understanding all the customer's interests and requirements, and the corresponding capabilities of the IT Service Provider.


Finally, ITIL doesn't speak to enabling technology choices because the IT Service Management thinking isn't altered by the choice of technology.

And all of the ITIL practices apply to whichever side of the Cloud edge one is on – Customer buying Cloud services or Cloud Provider delivering services. We just have to sort out who does what for whom in the steps of each process. Which is pretty darn important in any business deal whatever model one uses.


So if your score was in the 1.69 range, don't despair. Help is available!


For more about ITIL and IT Leadership please contact me via http://www.BusinessImprovementResults.com

ITIL in The Cloud - 2

ITIL in The Cloud (part 2)

In part one I introduced the notion that taking advantage of good business practice in all its forms like ITIL just makes sense, and even more so as one considers operating in, or with, the Cloud.


But when we talk about “the Cloud” what the heck do we mean?


How about this definition from the National Institute of Standards and Technology in the U.S.:
“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.”


Aha! We are talking about a model for the use of computing resources.


How does that fit with the Information Technology Infrastructure Library (ITIL)? Well, on a scale of 1 to 5 where 5 is best probably about a 10.


Why so high?

• ITIL is indifferent to the device technology used because it is concerned with the strategic, design, transition, operations, and improvement levels or layers working above the technology. ITIL deals with the thinking, organizing, and procedural aspects of running the IT business.
• It recognizes the most critical resource left out of the above definition – the people involved, as both a resource and a source of capability.
• Rapid provision of services depends on strong design, controlled transition, sound operations, continual improvement (particularly keeping in mind that fewer lifecycle errors leads to higher overall speed of provision).
• Being able to release with minimal management effort / service provider interaction hinges on sound, well executed process as encouraged by ITIL.
• And, availability (as well as the other warranty areas of capacity, contingency, and security) are well covered in the ITIL practices

In general, the more complicated the situation, the more benefit can be derived from other's experiences and best practices. Why make all their mistakes – again?


So then if an organization has a solid foundation of ITIL practices and processes, their various roles and responsibilities across the organization figured out, their IT Services catalogued, change and deployment activities under control, etc. then everything is perfect?


“Perfect” is a stretch (unless I am their Advisor). :-)


But I think the question boils down to:
Would you like to take advantage of the terminology, common understanding, thoroughness of checklists and process steps, clarity of roles and responsibilities, and structure of the lifecycle perspective that the best practices from ITIL have to offer, or be mediocre on purpose?


And that can be the difference between seeing the sun above the Cloud or getting rained on.


For more about ITIL and IT Leadership please contact me via http://www.BusinessImprovementResults.com

ITIL in The Cloud - 1

ITIL in The Cloud (part 1)

At the risk of sounding like one of the Four Yorkshiremen in the Monty Python sketch talking about how rough their childhoods were...


When I was a lad I had to get up before going to bed, walk barefoot through ten foot snowdrifts, and write Assembler code and such for mainframes such as the IBM 360, DEC PDP-10, and Xerox Data Systems Sigma 7. (Yes; Xerox Corporation was briefly in the mainframe business after buying Scientific Data Systems. And their research facility really did inaugurate desktop networked Personal Computers etc. long before anyone else. All fascinating stories for another time.)


And in those days of mainframes closeted in well protected data centres we had to play by the rules – for access, usage privileges, changes, etc. - because the strict governance of these million dollar babies was crucial to the owning organization, and careers.


Today we have, ta-da, the Cloud.


So as we begin to operate “in the Cloud” should we toss away everything we learned fifty years ago, including solid business practice for managing computing resources and services such as the Information Technology Infrastructure Library (ITIL)?


A business associate, Will Shook, writes as he starts up another information technology and services company [Accelerence, LLC]:

The issue at hand for me is this:  we built a model around computing many years ago and very good practices were developed in the glass house.  Then we went to client / server computing and everybody forgot everything about controls and processes.   Skip forward to the cloud and it seems everyone has forgot about good governance once again as they get focused on the technology, but not predictable results from the technology.  Good governance is more important than ever now, given the sharing of workloads, the mixed model of asset ownership and operation, and the preponderance of devices, data, and access methods.  ITIL should be a huge win in the world of the cloud.

Absolutely should be!


As the technology gets more complicated, and the management of it gets more complicated, and the difficulty of understanding what is done for whom, by whom, and under what circumstances increases, doesn't it make sense to take advantage of good business practice?


In fact, for those organizations who have developed thorough IT Service Management processes with ARCI tables, Service Portfolios and Catalogues, strong Operating Level Agreements and Service Level Agreements (just to note a few) moving to the use of Cloud services is easier.  At least they know what services they are talking about, can plug in new roles and responsibilities readily, and pinpoint service level requirements and dependencies.


If you are about to change some or all of your computing model isn't it nice to know in detail what you do today, how you do it, and have insightful and directed questions for your new Cloud suppliers?


Beats walking barefoot through ten foot snowdrifts!


For more about ITIL and IT Leadership please contact me via http://www.BusinessImprovementResults.com

Agile vs. ITIL

A little while ago an associate in the Agile Coaching community, Yves Hanoulle, asked me about the contention often raised that Agile software development practices don't mesh with the ITIL Framework.

On the surface, Agile practices are a solution to provide faster speed of software delivery than alternative development techniques, and the ITIL Framework with its focus on process appears to slow things down.

For example: Yves had a conversation on Twitter where someone said that continuous deployment is not possible with ITIL. Yves wrote me to say that he thinks that is “horsefeathers” [my word] because they don't understand ITIL. He continued: “I think a lot of ITIL people are using it as a prescriptive way of working. And I don't think it has to be like that.”

I agree.

We have always believed there is no discrepancy between Agile and ITIL. In every conversation with Project Managers and Agile folks about how Agile is not “waterfall development” and therefore doesn't fit with ITIL processes, we have shown them that this makes no difference.

Consider the questions of automation or traceability.

Both the Design and Operations books in version 3 of the ITIL Framework are very clear on the interdependency of Design & Development and Operations, in terms of:

• the design meeting specifications,
• that all of this can be confirmed by tests,
• and that Operations staff need to be able to provide input to Design to ensure the systems are operable, robust, and maintainable.

It is much more than the question of automation or traceability - it is a mindset / mental perspective of the integration of knowledge - and finally teamwork.

Let's break this down into more detail:

1. continuous deployment is of course possible, even if one, incorrectly, took ITIL as prescriptive.
2. even the so called "ITIL experts" argue about "implementing" ITIL word for word from the book which is not the intent
3. ITIL recommends using - adopting - the best practices, as they suit the organization and its needs. Again it is not law, it is a Framework. One uses the best practices as they make sense, just as you do in Agile. And where an ITIL practice can make an improvement one should use it, just as in Agile.
4. it all boils down to keeping the Great Teams commitment to not do anything dumb

Often people believe that rapid deployment / continuous deployment / daily builds etc. can't work in a an environment that is highly process oriented, where rules and process have to be followed. (Usually they just don't like someone else's rules.)

Well, the process is there to ensure consistency, responsibility, accountability, communication, traceability, etc. and of course it CAN be designed to be a hinderance. It. alternatively, CAN be designed to allow quick passage of releases. People blaming process or ITIL are just being immature. They may as well blame the weather.

The meaningful question in such environments is: What has caused the development of process controls to ensure such an approach for the management of risk?

• are the controls in place to reduce the error rate?
• was the previous situation causing buggy software to be released which impeded the business?
• has someone mis-interpreted the intent of the ITIL Framework and used it as law?

I'd be delighted for someone to find me an example of how ITIL recommends that the process gets in their way. So far in these conversations I find the combatant has yet to read the ITIL books.*

How does Agile play with other frameworks in your experience?

*By the way: I haven't read books on Agile either. However, the Core Protocols include the Intentional Development Protocol (an Agile foundation stone), and I am informed by Agile coaches such as Christophe Thibaut, Gino Marckx, Yves Hanoulle, and Esther Derby who recently posted STILL NO SILVER BULLETS (http://www.estherderby.com/2011/03/still-no-silver-bullets.html) on Agile methods.

HSD 1

So you know how you can come home from a course all pumped up with new learning, new insights, energy from the participants, new connections, etc., etc.?

That's me!

And then you have to deal with “reality” back home, and the questions of how to share the new learning with friends, associates, loved ones, etc., etc. and it all starts to slide downhill, leak away through your fingers?

That's NOT me!

When I came home from the certification course in Human System Dynamics last week, I had the joy of continuing to learn, gain insights, get energy because my sweetheart, and business partner, had attended with me (or more precisely, I with her, since it was her idea in the first place). And we have continued our great discussions about the intersection of the consulting / training work that we do with the concepts of HSD. [www.hsdinstitute.org]

Did I mention that she is also my business coach? [www.adaptivecoach.com]

So we have been rockin'! – bouncing ideas around, reviewing past experiences and work, playing with new “what if's” in the context of “patterns”, “containers”, “differences”, “exchanges”, etc., etc. [“patterns, containers, differences, exchanges” are all part of the HSD lexicon]

Yeah; I know – kids with new toys.

• AND, our work is our play (Work = Play)
• AND, we've got all these great case studies of previous and current consulting engagements we've shared
• AND, we're seeing connections expand exponentially between the areas in which we work: IT Service Management best practices, Teamwork best practices, business Coaching, and Leadership behaviours
• AND, the science of Human Systems Dynamics is explaining to us how

1. some best practice adoptions go well / don't go well / do both
2. the teamwork retreat “BootCamp” accomplishes so much in just a week [www.liveingreatness.com]
3. some organizations are open to new ideas & practices / some aren't / are both
4. and so on...

Just in case you are thinking that HSD is only for organizations, consultants, change agents, folks who like new mental toys, ... keep in mind that the first word is “Human” and that, hopefully, applies to all of us. :-)

More to come...