Download - 5 Minutes to Process Improvement Success

5 Minutes to

Process Improvement Success Leading experts share valuable take-away strategies for achieving process improvement results

Prepared by:

Bill Fox January 26, 2012

Interviews: 23

Web Site: http://5minutespisuccess.com

Blog: http://foxhighperspective.com/blog

http://5minutespisuccess.com/

http://foxhighperspective.com/blog

5 Minutes to Process Improvement Success www.5minutespisuccess.com

of 109

Notices

Copyright © 2011, 2012 by Bill Fox

All rights reserved.

No part of this publication may be reproduced or transmitted in any form or by any means, mechanical or electronic, including photocopying and recording, or by any information storage and retrieval system, without permission in writing from the publisher. Requests for permission or further information should be sent to the publisher at the addresses below.

Published by Bill Fox

42986 Park Creek Drive

Broadlands, VA 20148

(540) 454-6986

Legal

While all attempts have been made to verify information provided in this publication, the Publisher assumes no responsibility for errors, omissions or contrary interpretation of the subject matter.

This publication is not intended for use as a source of legal or accounting advice. The Publisher wants to stress that the information contained herein may be subject to varying state and/or local laws or regulations. All users are advised to retain competent counsel to determine what state and/or local laws or regulations may apply to the user's particular business.

The reader of this publication assumes responsibility for the use of these materials and information. Adherence to all applicable laws and regulations, both federal and state and local, governing professional licensing, business practices, advertising and all other aspects of doing business in the United States or any other jurisdiction is the sole responsibility of the purchaser or reader. The Publisher assume no responsibility or liability whatsoever on the behalf of any reader of these materials.

Any perceived slights of specific people or organizations is unintentional.


of 109

Table of Contents Notices ....................................................................................................................... 2

Table of Contents ...................................................................................................... 3

Introduction................................................................................................................ 4

Karen Base ................................................................................................................ 5

Kevin Schaaff ............................................................................................................. 8

Hillel Glazer .............................................................................................................. 11

Scott Ambler ............................................................................................................ 15

Neil Potter ................................................................................................................ 20

Bob Payne ................................................................................................................ 24

Mike Bonamassa ..................................................................................................... 28

Mario Hyland ............................................................................................................ 35

Jeff Dalton................................................................................................................ 39

Paul E. McMahon ..................................................................................................... 43

Karl Wiegers ............................................................................................................ 48

Mary Lynn Penn........................................................................................................ 53

Ally Gill ..................................................................................................................... 57

Alan Shalloway ......................................................................................................... 61

Tom Cagley .............................................................................................................. 66

George Dinwiddie ..................................................................................................... 70

Bob Schatz ............................................................................................................... 73

Mike Kelly ................................................................................................................ 78

Graham Oakes ......................................................................................................... 83

Jim Benson .............................................................................................................. 88

Dale Emery .............................................................................................................. 93

Guy Wallace ............................................................................................................. 98

David Anderson ...................................................................................................... 105

Next Steps and Acknowledgements ........................................................................ 109


of 109

Introduction

What makes the difference between an organization that is truly successful with process improvement and an organization that tries one flavor du jour after another with little results to show? Almost always, it's visionary leadership and the alignment of strategy and tactics. The good news is that no one organization or individual has cornered the market on process improvement. That's exactly why we created this series of "5-Minute Process Improvement Success" interviews. It's specifically designed to give you a collection of short, but brilliant process improvement strategies and tactics you can reference any time you need inspiration for fresh, new ways to improve your business. In order to do this, we've enlisted a group of experts to share their most effective process improvement ideas with you. We asked each of these professionals just one question:

"What is your best process improvement strategy or tactic that has worked really well for you or your clients?"

Each expert was given 5 minutes to lay out their best idea along with practical steps for applying it. The intent is to give you dense, easily digestible nuggets of process improvement insight you can apply in your situation. So get ready for some of the most unique ideas you’ve ever encountered on process improvement. You're about to discover a collection of powerful strategies and tactics that will become a mainstay of your process improvement library.

Bill Fox, Publisher and Editor

Bill Fox - [email protected]

Bill helps organizations manage challenging projects while acting as a catalyst to introduce process improvements that improve quality and performance.

Progressive organizations striving to gain extraordinary value and results through process improvement value his ability to focus and manage their process improvement

on the right priorities in a way that builds momentum and enthusiasm throughout the organization. Bill presented Managing Process Improvement at the Software Engineering Process Group (SEPG) in 2010.

Bill has over 25 years of experience in software delivery and process improvement as a project manager, analyst, process engineer and developer. Bill holds a BS degree from Penn State University and has ScrumMaster, PMP and Rational Unified Process certifications.

Follow Bill on Twitter or connect with him on LinkedIn to get the latest updates on 5 Minutes to Process Improvement Success. Join the conversation on the new blog at Fox High Perspective.

mailto:[email protected]

http://goo.gl/HqoDn

http://twitter.com/Bi11Fox

http://linkedin.com/in/Bi11Fox




of 109

Karen Base

Establishing Trust and Credibility to Create the Foundation for Success

Bill: Today I’m talking with Karen Base. Karen is president of KLB Solutions, LLC, a company that helps organizations get leaner, faster and better through process improvement.

Karen has a very successful track record helping organizations achieve rapid change and improvement through her unique approach to process improvement. From 2008 to 2009, I had the opportunity to work with Karen on a major process improvement effort and witnessed firsthand her approach and results.

With that background, I’m pleased to have the opportunity to interview Karen today. So Karen, I have one question for you today. What is the single best strategy that’s been responsible for your remarkable track record in process improvement?

Karen: I think that as a process improvement expert, yes, it is about process improvement, but a lot of it is change management and establishing trust with the organization. You need to be sensitive and respectful of the status quo. That sounds really strange, because process improvement is about changing the status quo, but until you establish that trust and prove to people that you understand the status quo, that you are listening, you really can’t establish any platform to speak from. You can say, “Yeah, I have a perfect record of delivery,” but nobody cares.

Bill: They're not going to hear what you say and believe you.

Karen: They're not going to get behind you. I used this tactic successfully with a variety of organizations, and I'm hearing that right now with my current client. People have told me directly, “We think the difference between you and other process experts is that you listen. You’re listening to us and you’re working with us to try to move to the next stage, instead of assuming you know everything and just bulldozing over us.”

So I think just the initial establishment of trust with all the key players—and not just top-level management is critical. One thing that I think is effective is you need to find the right people to endorse the cause, and you need to get a sampling of the top and the bottom and somewhere in between within the organization.

Bill: How do you go about doing that? What is it you do that allows you to achieve the desired results?

Karen: I think that as you’re infused in an environment and you’re observing, a lot of it is just really observing the culture and constraints. You can pretty quickly— and this is where it’s more


of 109

of an art than a science—tell who is the “loud voice.” What I mean by that is not the talkative people that are just rambling for the sake of talking, but people that, when they speak, you can sense the whole room almost revolving around them.

Although it is important to have a strong top-down message saying, “You shall do this”, the message is often taken grudgingly and met with resistance. Usually the workers don’t know these types of people well enough to say, “I would do anything for that guy.” You need to find somebody at the top ranks, perhaps VP level or above, that people are saying that kind of stuff about. “I would do anything for him or her.”

And then you’ve got to find support in the line managers because usually the project and discipline managers are the people who are closest to the troops. These are your project managers, scrum masters, or whoever it is that’s doing the day-to-day caring and feeding of the troops. You’ve got to find people who are popular in that range, that level of staff, and get them on board with you as the change facilitator. If you get the line managers on board— or at least some of them on board, I think that that is another key piece.

Then you really have to reach out to the troops. It’s a grassroots movement at the end of the day because execs could get cycled in and out, but the troops have more staying power— so you have to get a sampling of the organization from top to middle to lowest level practitioner. And then if you get a good sampling of the loud voices of each of those layers, I think you have the beginning of some level of adoption.

The next thing is recruiting the proper people into the process improvement group. If I didn’t have staff whom were already widely respected by others on my team, it would’ve been a nonstarter. If you can get a reputable practitioner on your staff, someone who earns an “Exceeds” rating every year, the news spreads. Everyone starts wondering, “Why does he want to be in that group?” And they go to lunch with him to find out.

But within your group, you still have to—this is where the skill comes into play—know your process improvement techniques! You have to give people something to talk about so that they spread the news of innovative methods and how this is different than previous effort. If done right, the ideas are intriguing, and you start getting that gravitational pull. So you need to be organized, you need to know your goals, and you need to be able to articulate what the vision is and how everyone’s going to march towards it.

You need to have in your toolkit processes, tools and methodologies, and you need to know that stuff cold. This scientific stuff, to me, is the easier part. For example, you should be able to whip out process assets like, a process improvement PMP, and a measurement strategy and so on. When you have your act together in that sense, then you prove to the top performing people that are in your organization or anyone out there that you’re interacting with, that you know your stuff, and it’s not so bad, because this time it’s organized and it’s different than the way it was.


of 109

In the end, the process improvement mechanics are relatively easy. It’s understanding the pulse of the organization and getting your storefront to look good, that requires a keen eye and some creativity to get right.

Bill: Do you put a plan together that calls out all these components and you customize it for each client? How do you size that all up and build a picture and do it?

Karen: I actually honestly do not have a technique that I’ve documented and said, “This is the approach,” because each organization has its unique challenges. But there is an adoption pattern here. You should be able to apply this pattern, but you still need to use a lot of personal judgment too. Personalities come into play. You need to understand and assess the organization… is it a rough around the edges type of organization, or is it more of a genteel type of culture or if it’s somewhere in between, and be able to fit in and apply this pattern appropriately.

This adoption pattern is to get a representation from the primary levels of the organization, and leverage the people to be part of the movement towards change. And don’t be afraid to proactively establish a personal rapport. In fact, go out to lunch with people and do coffee and set aside time to do that. So that’s the pattern, but whether or not you succeed in applying that pattern has to do with how well you understand the corporate culture. Does that make sense?

Bill: Yes, very much so Karen. This was a very interesting perspective and I’d venture to say often overlooked. Thank you for talking with me today.

Karen Base - [email protected] Karen Base is an industry expert on leveraging trust and credibility to build a rock-solid foundation for optimizing systems delivery performance in IT organizations. She is the creator of the KLB Success AssuranceTM infusion program that enforces her proven unique approach of client focus, problem solving, listening skills, and quality delivery practices. She’s a recognized thought leader and was instrumental in bringing forward

this innovative and collaborative 5 Minutes to Process Improvement Success white paper.

She has implemented large process improvement efforts for commercial and not-for-profit organizations, conducting CMMI based appraisals targeting various maturity and capability levels. She has developed and implemented strategies and frameworks for several enterprises, using unique organizational change management techniques and has been recognized for leading exemplary implementations that achieved broad support across the organization and results ahead of schedule.

Karen is the founder and owner of KLB Solutions, L.L.C., a management and technology consulting company offering process improvement and systems quality related services. She is a Certified Scrum Master, PMP, and ITIL certified professional, with 20 years of systems and software experience.


http://www.klbsolutions.com/thought_leadership.html

http://klbsolutions.com/


of 109

Kevin Schaaff

Keys to a Successful Quality Program – A Global Perspective

Bill: Today I’m talking with Kevin Schaaff. Kevin is currently a project manager with Booz Allen Hamilton and formerly a senior member of the technical staff at the SEI with deep experience working with organizations around the globe implementing process improvement.

From 2008 to 2009, I had the opportunity to work with Kevin on a major process improvement effort and his experienced and insightful guidance was pivotal in helping to bring the project to an exemplary finish.

I’m pleased to have the opportunity to interview Kevin today. So Kevin, I have one question for you today. What is your best process improvement strategy or tactic that has worked really well for you or your clients?

Kevin: You know it’s interesting because of my global consulting experience, I’ve noticed that there are certain ideas and themes that translate regardless of culture that keep coming up over and over again. Independent of the technology, the business, the country, or the culture these are areas that if done well have consistently resulted in the success and long term sustainment of any quality program or initiative.

And probably the most important theme is that the Quality Program needs to identify a respected senior executive within the company as the Quality Champion. This must be someone who has earned the respect of the entire organization and is in a senior enough position such that they have the authority to direct resources and resolve issues as they arise. For companies where I have seen this done best this level of commitment usually starts at the CIO, COO level with strong visible support from the CEO. Programs that do not have this level of management support are generally short lived.

Bill: What if a process improvement effort finds itself without this support? Have you ever seen a project get this level of support after the fact or any recommendations on how to get it?

Kevin: I have seen process improvement efforts kick off without this initial level of support, although they still must have some level of senior management support to acquire the initial needed resources. However, long term success still requires the quality program to get this level of support. The business reality is that at the end of the day it’s always about money. Specifically how much does this cost vs. impact to bottom line. If the program does not have this level of support initially to get it, they must explicitly make this linkage and show tangible results. Long term success is dependent on the program’s ability to manage up.


of 109

Bill: That’s a big factor Kevin. What’s next on your list?

Kevin: The quality program must have a direct tangible impact to the bottom line business success of the organization. Whether that is maintaining skills and credentials needed to bid, responding to a customer mandate, or ensuring a consistent level of quality from the customers’ perspective the quality program must be able to demonstrate business impact. The Quality program needs to be able to measure its effect on the product on the projects producing the products. There is an old business saying that says, “You can’t manage what you can’t measure.” I have always found this to be true at some level.

Bill: I often hear organizations say, “We all know we’re doing this to get better but we haven’t focused on exactly what to measure.” What’s your response to that type of thinking?

Kevin: They should ask themselves the question: “Why am I doing this to begin with?” These efforts are always in response to some stimulus whether internal or external. Once you have the answer to that question then go one step further and ask, “How do we define success?” Based on those two questions the answer on what to measure usually appears. The other part of measurement I often see organizations overlook is get some initial measurements on how the organization is performing when the effort starts, regardless of how difficult this might be or suspect the data. The reason is usually about a year into the effort the organization is feeling like progress is being made, and by then has some kind of measurement in place but because they took no initial measurement, they can’t really prove what they know is anecdotally true. The Software Engineering Institute has a very effective Goal Question Measurement approach which directly addresses this issue.

Bill: Ok, great. What else is needed to have a successful quality program?

Kevin: Pick the right people for the job and run it like a project. Unfortunately, all too often in companies I see people get picked to be quality or process improvement professionals because they are not skilled in the other functions that are perceived to be more relevant to the business needs. The program then is only loosely managed with no identified deliverables or timelines. Additionally, because the people chosen do not understand the business or quality, they put a lot of policies and processes in place that add no value to the end product. This is a formula for disaster. After a few years, the senior executives want to know what the Return on Investment is for the effort and these programs have nothing to show for it and generally fail to execute.

Bill: Looking back across process improvement efforts I’ve seen or have been involved with, this one seems key. A good team can fix all the other keys to success, would you agree?

Kevin: I would agree that the right people chosen to do the job can overcome a lot of the technical challenges, but the right senior level champion is still needed for long-term success and sustainability. There are numerous examples across the industry of organizations with renowned quality organizations consisting of highly skilled people that know how to do the job, but if the senior management support wanes the overall effectiveness of the program can suffer. A very


of 109

recent example of this in the news would be the quality issues that Toyota has been dealing with. Many industry analysts believe this was a case of losing the balance between quality and cost.

Bill: That’s a great example Kevin that I’m sure we can all relate to. Have you identified any other key themes to a successful quality program?

Kevin: Finally, the quality program must fix something or solve a problem the business cares about. So often after years of improvement effort I hear senior executives or program managers state that despite all the quality initiatives nothing has gotten better or changed. Too often I see quality programs focused on compliance and not much else, and while compliance is a necessary part of any quality program it is not the only or even the most important part.

Bill: Any thoughts on why organizations get so hung up on compliance? Why doesn’t compliance guarantee success?

Kevin: I believe it is a fundamental lack of understanding of what quality really means in an organization. The organization has an issue, someone hears about a model, methodology, or standard that addresses the issue without knowing what that really means, and then they blindly undertake a dogmatic implementation of it without really understanding the issue in the first place. Quality is a culture and a mindset, not answers on a checklist.

While I have focused these ideas on a successful quality program, if you think about it these are fundamental necessities to any successful initiative

Bill: Agreed Kevin. You make it seem so easy and basic but I’ve seen most of these fundamentals missed everywhere over and over again. Thanks for taking time to talk with me today to share your global perspective.

Kevin Schaaff - [email protected] Kevin Schaaff is a Principal at Booz Allen Hamilton responsible for the system delivery of large scale IT systems. He is also a Visiting Scientist at the Software Engineering Institute. He is a certified High Maturity Lead Appraiser and Instructor, with over 30 years of experience in Systems Engineering and Project Management. His previous experience includes managing a variety of programs ranging from large Navy

R&D efforts to implementing small to medium scale IT Systems. Before joining the SEI, Kevin led other organization’s quality programs to SW-CMM and CMMI Maturity Level 3, CMMI Maturity Level 5 and was responsible for numerous sites being both ISO and AS9100 registered.



of 109

Hillel Glazer

The Key to High Performance Operations: Applying a Visual Systems and Value Perspective

Bill: I’m on the phone today with Hillel Glazer. Hillel is founder, Principal and CEO of Entinex, Inc. I attended one of Hillel’s presentations at SEPG Europe 2010, and found his presentation on Values, Principals and Practices very revealing. In this presentation, Hillel demonstrated that he possesses that rare ability to examine our current assumptions, and reveal new levels of understanding. With that background, Hillel, I have one question to ask you today: what is your best process improvement strategy or tactic that has worked really well for you or your clients?

Hillel: The best strategy that has worked well for me is to start to look at what the organization needs to accomplish from a product, project and services perspective. And by that I mean whatever it is that you get paid to do. And secondly, look at what the organization does as a system.

From a systems perspective, an organization needs to satisfy a lot of often conflicting needs or expectations. For example, there are clients, customers, corporate governance, the need to make money, the need to keep clients and employees happy, the need to satisfy regulatory, statutory and other requirements. All of these are contributing pieces to a single system that must operate together and function as a whole.

Bill: Do you usually help your clients answer those questions to get a systems perspective or do they view it as a system already?

Hillel: Well, they don’t see it that way yet. Very often the clients don’t yet see the situation they’re in as a system. They're too busy—and as a result, they often see each piece of the company, each piece of the operation or the business as though it’s independent of all the other pieces. So they usually only see what they do to deliver out the door that gets them paid. All that other stuff somehow is seen as an interruption to their primary job, or as a necessary evil, or something that is outside of the overall workflow that gets them paid. When in fact they’re not.

Each piece is not necessarily all part of the value add of what it is that they do, but in terms of and as a result, because they don’t actually see the pieces as components of a larger system that either costs them money or helps them make money. They actually try to do the least that they have to do to get to the state of sending something out the door, which turns out to be a lot more disruptive and cost-prohibitive than had they stopped, stood back and looked at everything they need to get done as part of a single system.


of 109

Bill: After you answer those questions, how do you determine what’s the best strategy for addressing them?

Hillel: What often happens is the client doesn’t see all these things as components to a single system that must operate together. So the next best thing is to actually physically lay it out on a whiteboard or a flipchart. It’s very important to visualize and see how these components fit together into a system.

I think that the notion of visualization doesn’t get enough airtime. I think people aren’t giving the idea of visualization the attention it deserves. Visualization is very powerful and it’s a technique that deserves a lot more attention. I don’t know why it’s so frequently overlooked, I can’t explain the psychology behind it, but I can say that I think for some reason people perceive visualization as not real work.

Bill: It almost seems too simple sometimes. But I can’t count the number of times when a simple visual has brought immediate clarity and understanding to a discussion.

Hillel: Yes. And because it is so simple and powerful, I believe it’s one of the contributing factors to why people ignore it. I think there’s no shortage of organizations that are short-sighted when it comes to viewing their organization as a system. Given that there’s no shortage of organizations that are short-sighted, I believe that in some cases the visualization is a threat.

Because once it’s visualized, it’s black and white, it’s right there on the board. Where are our bottlenecks? Where are the things that are costing us money? Where are the things that take too much time or too much rework?

And so I basically apply two overlapping principles. The first principle is systems engineering, looking at everything that they do as a system that must be engineered to solve the needs of the organization. And those needs are the combination of the things we’d mentioned earlier such as making money, keeping clients and employees happy, and meeting regulatory, statutory and other industry requirements.

And if we look at either CMMI or general process improvement, what they’re trying to do is to improve the overall performance of the organization. And until we see the entire organization and everything it does, then we’re not going to know where and how to improve performance or how to most effectively apply the practices of improvement.

Without the systems perspective, we’ll end up with point solutions that sub-optimize their ability to actually see true improvement. And I'm not going to get into the discussion about people that are just doing CMMI, for example, to get the certificate, so to speak, and check the box and move on. We’re not going to go there because that’s just a Pandora’s Box of reality.

So we’re strictly speaking about organizations that are interested in improving their performance. So I think I should probably make that caveat upfront that, assuming an organization wants to actually improve performance and not just check a box, what I said follows.


of 109

Bill: Ok, so that’s very interesting how you apply systems engineering to process improvement. And the second principle is?

Hillel: The second principle is to look at each part of the system, and how it contributes to value. With value you are looking at three different aspects at a minimum: value to the customer, value to the project, and then value to the organization, both near-term and long-term.

To develop them, and then in that perspective, you develop a system so that you are producing things that add value, and that contribute to long-term success, so that when you work the two together, it’s not just creating a system that is functionally capable, but that the system itself is also lean.

With every decision point, you’re asking the question: what value does this add? Or in some cases you do have to realize the question is: what value does this cost? As long as you are aware, and thinking about each thing as a question of value, it raises awareness because you can’t always make the decision on just what is the most value. Sometimes you have to make the decision that is not always the most valuable. But, going through the process of taking a value-focused perspective at least ensures that you are aware of the impact on value of how you are going about things, and will allow an organization to be cognizant of opportunities to improve value when they present themselves because people are quite aware and familiar with what it is that they are doing from a systems perspective, and the value that it’s adding or not to what they are trying to get done.

So those are the two principles, systems engineering and value. And where the lean comes in is when you are making choices that are based on value. You can’t help but become lean and pursue lean, and think of things in terms of lean, value, waste, productivity, efficiency, and effectiveness. It’s almost like raising consciousness at an organizational level towards performance.

Bill: Okay, that’s interesting. Now you raise it up, you can all see it; it’s right in front of them, and they can make choices among various options.

Hillel: Yes, exactly. An organization gives itself alternatives when they pass everything through a value filter. Now you have a choice. A lot of times people feel that they are boxed in, and they’re often feeling like their choices are either limited, or non-existent, do it this one way. But when you put everything through a value filter, not only does the organization itself stand to benefit, but chances are that organization’s customers are open and receptive to having their minds changed. When an organization can go to their client and say, “I know what you asked for, but this is going to be more valuable.” As opposed to when most organizations often run into trouble with convincing their clients of the right thing to do, chances are it’s because they came to them with a technical best thing to do, and didn’t present it as the most valuable thing to do. Whether it’s process or technology, or service or something, they frequently present the cerebral case of, the geek case, where they often forget the emotion or the business case, which is what people get sold on.


of 109

Bill: Hillel, this has been a fascinating introduction to what we can expect in your upcoming book. I know I’m looking forward to its release to see exactly how you combine a system perspective and visualization and apply it to process improvement. Thank you for talking with me today.

Hillel Glazer - [email protected]

Hillel’s the world's leading authority on introducing lean and agile concepts into the regulated world. In particular, he's the "AgileCMMI guy" (agilecmmi.com) and is the SEI's go-to authority on Agile having co-authored their only paper on the topic and contributed the agile content in new CMMI v1.3. He's helped companies of all sizes and locations successfully blend agile with CMMI and achieve performance benefits, not just artifacts and ratings.

Hillel’s book, "High Performance Operations: Turning Compliance into Competitive Advantage" lays out exactly how he does it, beginning with the key idea he discusses in this 5-minute interview.

His Baltimore-based company, Entinex has a global reach that focuses on generating powerful results for high performance organizations among companies motivated to be lean, agile, and achieve world-class levels of operational excellence.


http://agilecmmi.com/

http://www.amazon.com/High-Performance-Operations-Compliance-Competitive/dp/0132779889/ref=sr_1_1?ie=UTF8&qid=1314932382&sr=8-1

http://www.entinex.com/


of 109

Scott Ambler

A Perspective from the Chief Methodologist for Agile/Lean at IBM Rational

Bill: Today I’m talking with Scott Ambler. Scott is Chief Methodologist for Agile/Lean at IBM Rational. I’m familiar with Scott’s work and reputation through my previous work at Number Six Software. Recently I started following Scott on Twitter and a few things caught my attention. First, Scott’s Twitter profile states: “Doing my best to find effective strategies for software development and evolution.” This statement is in strong alignment with my vision for this white paper. And secondly, Scott conducts surveys to gather data to inform his work and decisions. This is ultimately what I’m looking to do in this white paper - find people who are doing things that are moving the performance needle and getting real results based on data. So with that background, Scott, I’d like to start by asking you one question: What is your best process improvement strategy or tactic that has worked really well for you or your clients?

Scott: I think the best one that I use is help people and organizations become aware of what they are actually doing, and be aware of what is working and what’s not. There are usually beliefs that a certain technique, for example, doing a detailed upfront estimate is working really well for them, and that’s just the way they’ve got to work. That’s actually an exceptionally poor strategy. So I’ll ask people how well that actually works for them, “Walk me through that, when you’ve done that, what actually happened?” just to make them aware that things aren’t working so well. Then I start talking about different options, and in particular, tradeoffs. I think that the tradeoff conversation is critical because usually they don’t understand the tradeoffs that they are making. They don’t know that they’ve got options, and they don’t understand that they are making some pretty serious tradeoffs. What I usually find is that people start having intelligent conversations after that. If I had to pick one technique that would probably be it.

Bill: Okay, that’s interesting Scott. How do you begin that conversation with them? Are there particular areas you focus on?

Scott: No, I’ll usually let them start off with conversations around, “What are you doing now? What do you want to achieve? Why do you want to do process improvement at all?” Then that will sort of lead them to identify what they believe their pain points are. Particularly the goals will reflect what their current pain is, and what they are trying to achieve, and then I’ll start going in on the, “What are you currently doing?” and helping them discern what is not working well. Some of the organizations do not understand the implications of the decisions that they are making at a high level. Down in the trenches, the developers, they pretty much know. They might not have the full process improvement picture, but they know what’s not working. They have a few ideas around what could work better. They might not be willing to do the work to


of 109

make it work it better, but at least the will is there. But what I find is at the higher levels, at the senior management level, at the business level, particularly on the business side of things, they typically don’t understand the implications of what they are asking for. They don’t understand the behaviors that certain requests will motivate. It’s always a big surprise that things don’t work out well. I try to help them understand what the implications are of those decisions, the tradeoffs that they are making, helping them to understand, to recognize, whatever they are doing now has not been working for them, has almost no hope of working for them, and they need to get off that treadmill.

Bill: Once you bring that clarity, how do you get them to focus to make an improvement? Is there a way you approach that?

Scott: Yes, after we have the alternatives discussion, then we start trying to identify pilot projects. The proof is always in the pudding. We try to find a realistic pilot project or pilot projects, as the case may be, where it’s medium-level complexity project where it’s real, it’s going to have an impact on the organization, but they are not betting the organization on this one project either. Then we start experimenting because a lot of my message is, “You need to see this work in your own environment.” Every environment is different. At a high-level, the strategy will be the same or there will be some coherent similarity between the strategies, but the nuances will be different in every organization. Every organization is in a different situation. Every team is in a different situation. They need to tailor it to the context that they find themselves in. People learn at different rates and in different ways, so they need to experiment with these techniques that are new to them, and find out what works, what doesn’t work. There will be some things they are going to struggle with, and they will need to focus on, other things will come very easy, and that will be okay too. They need to be prepared to be flexible, and to be in a learning mode, I guess you would say.

Bill: Okay. One thing that occurs to me now is that you are the agile and lean methodologist for IBM Rational. How does that play into it vs. looking at all the other options that are out there, how do you bring agile and lean into the conversation?

Scott: My focus for a long time has been on agile and lean. My title sort of labels me as an agile guy, and what I really try to aim for is, “What is the best strategy for your situation?” I’ve got a background in waterfall, I’ve done that. I’ve done a wide range of things, so I’m always trying to look for the best option, “What is the best strategy for the current environment?” Now that almost always happens to be agile and lean. At the end of the day, all the agile community has really done is identify what works really well in practice. They have identified what doesn’t work so well in practice, and they focus on things that work well, and they try to avoid the things that don’t work well. It’s not rocket science. So what I’m finding is that as organizations start to wake up to the concept that traditional waterfall stuff really doesn’t work so well in practice. It was wonderful theory, but we’ve shown the theory to be wrong now, to be wrong in most situations, I should say, or not the best strategy in most situations. Then they really need to start looking for what actually does work in practice, and that leads them to the agile and lean stuff.


of 109

As a result, and frankly, most of the interesting stuff going on in the process community, whatever that would be, is actually going on in the agile and lean space. All the leading thinkers in the process space are focusing on this right now.

Bill: Scott, I remember you mentioned before we started you’d like to talk about the agile scaling model. Do you want to talk about that or any other final closing comments?

Scott: So yeah, I’ve been focusing on something called the agile scaling model lately. The main message there is to just understand the context that you’re in. It walks through three categories of process. The first one is core agile development - SCRUM is a perfect example of that. Part of my message is that these core agile methods, like SCRUM and XP, and Agile Modeling and Agile Data, and a bunch of other stuff, they are all really good, they are all part of the picture, but none of them are the whole picture.

The first thing you’ve got to do, period, is figure out, “How do I actually develop using agile techniques, or just any technique, from end to end, all the way into releasing the production, and obviously going onto the next release?” You need that full end-to-end picture, which none of the popular agile methods really give you. That is what we call an agile delivery. We bring enterprise awareness to that because you are working in an overall organizational eco-system. You should be reusing stuff and following conventions, all that good sort of stuff. We also talk about governance being built into it too. Somebody is keeping an eye on these projects. Somebody should be leading these projects to success, monitoring them and guiding them, making life easier for them. The agile community doesn’t really like to talk about governance, it’s almost a swear word, and yet all of their projects are being governed in some way, often ineffectively.

In a lot of organizations, I also look at the governance structure because someone is talking about the high-level business and high-level management stuff, that’s mostly governance effort going on, and the governance efforts are almost always dysfunctional from an agile point of view. They are almost always focused on waterfall, and on documentation. They usually don’t work very well, and then problems arise. I try to help with the governance stuff. We built this into this manageable delivery, but then the challenge becomes, that’s mostly geared for small teams that are reasonably co-located, fairly straightforward stuff. But what if that’s not your situation?

The third category in the agile scaling model is Agility at Scale, which is the really interesting stuff. What this category does is it makes explicit all the various scaling factors. Usually what happens is when you talk about scaling is everybody thinks of big teams and distributed teams, which is obviously important, but those are the easy issues to deal with. The not so easy issues to deal with are what happens when you are in regulatory compliance situation, what happens if you have a complex domain that you are trying to address, or a complex technology that you are working with, but you truly want to be enterprise aware and bring the enterprise architecture effort into play, and bring the strategic reuse effort into play, and portfolio management stuff, actually make it effective. This is what Agility at Scale brings in, so from a process improvement

ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14204usen/RAW14204USEN.PDF


of 109

point of view, the challenge to organizations is to not focus on repeatable processes. I think this has been one of the great disasters in the IT industry is just this naïve, this is just the most polite word I can say, this naïve expectation that we could have repeatable processes, and that’s out of control bureaucracy in my mind. What we really need are repeatable results. We need to be delivering solutions in a timely manner, we need to be delivering quality, we need to be delivering systems that meet the actual needs of what people want, not what was specified. This working to a detailed requirement specification is just absolutely crazy, so this is just a completely different mindset. It’s easy to say focus on repeatable results or repeatable practices, or repeatable processes, it’s a very significant difference. The scaling factors bring this out because when you work through the eight scaling factors that we’ve identified, it’s blatantly obvious that different teams are in different situations. As a result, you couldn’t possibly have a repeatable process that met all of these combinations of scaling factors. It’s an infinite combination, actually. So what you really need to do is tailor your process and tailor your tools to reflect the situation that you find yourself in. This requires discipline, it requires skill, it requires knowledge, it requires good governance, and it requires maturity. Unfortunately, maturity seems to be a bad word these days in the IT industry, but it requires a maturity that we don’t see in a lot of organizations.

So this focus on repeatable results is quite a significant difference. From a process improvement point of view, and perhaps this is my most important message, is that context counts. If you don’t tailor your process to meet the context that you face, the process is more than likely going to get in the way, and it’s more than likely going to be ignored. I think we have a very large history in the IT industry of development teams completely and utterly ignoring the process, so that the process engineers need to be aware of this. The source of this problem is really on shoulders of the process engineers. If they’re being ignored, there is probably a very good reason, and they need to start producing something that is attractive and motivational to the project team that can actually help them, as opposed to hinder them. That could be an interesting observation.

Bill: I really appreciate the coverage of the Agile Scaling, Scott. It really speaks to me in my experience introducing agile into a large organization that some of these other areas, factors were not considered, and as you know you’re running into them all the time.

Scott: Exactly, and there’s actually two aspects of scaling. If you look at it from the point of the individual project, are we a big team, are we distributed, are we in a regulatory environment, and so on. But then if you look at the organizational level, it’s the scaling agile across the entire organization, and that brings in some interesting challenges. Usually what happens, and maybe one of the reasons why the agile community has seen such a good success, is that organizations kind of cherry pick the projects. Particularly if you look at the pilot project strategy, the strategy is always, “We’ll, pick an environment where agile is going to work well. Pick your team of open-minded people who are reasonably highly skilled.” So you set yourself up for success, which is obviously a smart thing to do, but when you try to roll it across the entire organization, you can’t cherry pick projects anymore. You can’t cherry pick your teams anymore because


of 109

you’ve got to work with everybody. You’ve got to work with all the projects, or a very large percentage of them, and that’s a much harder change situation. And then, like you said, you bring these groups that you chose to ignore before, you can’t ignore them anymore. You’ve actually got to find ways to work with the data management crowd, and their heads might still be in the 1970s, the operations crowd and so on. It’s a much different environment for people.

Bill: Okay Scott, I think this is all great. You’ve given us to several great ideas to think about and I know we’re keeping you from getting to all the snow that’s piling up in your neighborhood!

Scott: Okay, fantastic! Thank you!

Bill: Thanks Scott, I really appreciate it!

Scott Ambler - [email protected]

Scott W. Ambler is Chief Methodologist for Agile and Lean with IBM Rational, working with IBM customers around the world to help them to improve their software processes. He is the founder of the Agile Modeling (AM), Agile Data(AD), Disciplined Agile Delivery (DAD), and Enterprise Unified Process (EUP) methodologies and creator of the Agile Scaling Model (ASM). Scott is the (co-)author

of 19 books, including Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, and The Enterprise Unified Process. Scott is a senior contributing editor with Dr. Dobb's Journal.

Scott holds a BSC in Computer Science and a Master of Information Science from the University of Toronto.


http://www.agilemodeling.com/

http://www.agiledata.org/

http://www.enterpriseunifiedprocess.com/


of 109

Neil Potter

How to Get Faster Results with a Goal-Problem Approach

Bill: This evening I’m talking with Neil Potter. Neil is co-founder of The Process Group, a company that helps organizations with process improvement, software engineering and project management. To get started Neil, I’d like to let everyone know how I came across your name. I recently read several of your responses on one of the process improvement groups on the Internet, and your responses caught my attention as someone who’s pretty pragmatic and experienced. I went to your website and saw more good information there, so that was what prompted me to contact you. So, may I just start by asking you the first question we are asking everyone, Neil, what is your best process improvement strategy or tactic that has worked really well for you and your clients?

Neil: I’ve boiled it down to one attribute that we have been using for a long time now, probably since the early 90s. Let me talk about it from two perspectives. One is from the perspective of when people don’t do this, what happens, the classical approach they get themselves into. And then I’ll discuss the strategy from a solution standpoint, that is, if they had tried this approach, they could have avoided many problems.

The classical approach that people use when they look at a model or standard (such as CMMI, ISO, FDA or a medical device standard), is that they often start designing their process improvement program around the standard they are trying to achieve. So if there are six sections to a standard, or seven process areas to the standard, they start with seven sections, seven teams, and seven documents, hoping to fulfill the standard.

So the strategy we recommend is to have people focus on the business of the organization and use that to drive the use of improvement frameworks. I’ll give you an example to make it more specific. When a group starts out wanting to achieve CMMI level two, or level three, or an FDA standard, we have them list the next upcoming major deliverable. If they have a device they are going to ship to the field or an IT solution to deploy in the next six to twelve months, we have them start with that, rather than a model or standard because we know they are focused on that.

The second part of the strategy is to have them list all of the key challenges they are having right now with achieving a particular deliverable goal.

For example, a team may say that their current challenges include scheduling, estimation, supplier problems, changing requirements, or technical surprises. So the strategy is to design the improvement program around their goals and problems, and not around the sections of the


of 109

model or the framework. This strategy always applies; the goals and problems always tell the team where to improve next.

For example, during a project a team may encounter any number of challenges. When they apply the strategy, they start to improve by tackling the major challenges they have right now. They then look at the framework or model they are using, and recognize that the framework has the very same things in it that they are struggling with, but they are described in different words.

So if I said to a team, “What is the major goal you are working on and what are the major issues you are having right now?” And they may say surprises and a lack of good estimates. In any model framework, there is something about risk management and estimation. Now, what they are basically doing is verbalizing the model practices in their own language.

What happens when a model is created? It’s created by a committee and stated in a generic language. The more a project team can see that there is an overlap between elements of the framework that they want to use, and the very things that they have issues with, they see that the issues list tells them where to start. If they go through that cycle and they fix those three or four challenges, and they actually use those related practices of the model, they are making model progress and improving their performance at the same time. The next step is to repeat the strategy, because now they have those problems solved. On the next project or the next major deliverable, they do the same thing and select a few more issues to address.

Now let’s run through another scenario. Well, maybe their issue is now that they can’t find defects quickly enough, or they can’t find defects or mistakes early enough in the project. Or they have difficulty in dealing with code versions, changes to the product, and maybe suggestions from the outside about how the product should change. So the team has again verbally described (in their own language) new practices they need to use from the model. These might include CM, estimation, scheduling, requirements development, or improving requirements management. They apply those practices and they make progress on the model again. All they are really doing is using their own current situation to navigate into, and through, the standard and framework they want to use, but in an incremental fashion.

The benefit of using this strategy is that they never have to be confused about where to start next because the goals and problems that they have now will always tell them where to work next. You’ll always have goals and you’ll always have problems.

The other side effect is that when they use a practice from the model or framework to fix the problem, they can now obtain immediate benefit. They no longer have to wait six months for a committee to define the requirements management procedure, or twelve months for the team to define everything to meet the standard. They get immediate benefit from putting a few practices into place now on the current project.

The second benefit of using the above strategy is that the changes are correctly sized for the problems that they have. No longer are they creating very large documents, standards and templates that are all encompassing and meet no one’s needs. They are building process


of 109

solutions, templates and guidelines that are sized specifically for the issues that they have. If they are careful, they can make the solutions a little bit more robust to deal with different situations that come up later on.

The goal-problem strategy has an organization integrate the improvement and work activities as one element. No longer are they seeing work and improvement as two separate things - you either choose to improve, or you choose to do work. When you do work now, you are improving, but incrementally.

Bill: That’s really interesting, Neil. You’re really chunking it down for them, helping them see what the real issues are, and then guiding them in a way that they are solving real issues, and not creating piles of documentation and standards that may or may not get used.

Neil: What I would just say on your point, the thing about documentation and standards is that documentation is now a natural byproduct of doing work. If they were ever to have a regulating body or an auditing group looks at them from outside, where they have to demonstrate planning or risk management, they are now producing documentation as a natural byproduct of doing a process correctly. The solution that they have built is at the right level and size for the issues that they have. If it’s a small group, they’ve boiled it down to what they need.

Bill: Okay, very good. In terms of presenting that approach when you work with a client, do people usually see the immediate benefit of that approach, or do you have a pilot type of run to show how well it works?

Neil: That’s a good question. When we present the approach, usually the light clicks on pretty quickly because they start to recognize that they don’t have to take a standard or a model like CMMI and then do the whole thing at one time in parallel. They realize that they can get to the end point incrementally, but they can choose the elements in the order that are suited to where they are now.

The only side effect is that somebody in the group has to track which model practices have not been used yet and make sure that they don’t get so focused on just work. They need to keep track of what they have used, and what they have not used, such that when they get to the point of either being appraised or audited, they have been through enough cycles and they have directly used all the practices.

That’s not a big consequence to pay. They are going to track improvements anyway, but now it’s just made a little harder because before they had seven documents to track, and that was easy. Now they have to revisit the framework, and see what is left. Also if they do have difficulty getting improvements to work, they can find that issue early, rather than wait six months for a committee to finish, and then find what the committee wrote is not applicable, too cumbersome, too complicated, or too free of content.

Bill: Yes Neil, I really like your approach. I’ve seen too much of that wait six months and see what comes out, and then try to make it work. It is very interesting approach. Thank you very much for talking with me today!


of 109

Neil: Thank you very much!

Neil Potter – [email protected]

Neil Potter is co-founder of The Process Group, a company formed in 1990 that consults on process improvement, software engineering and project management.

He has 25 years of experience in software and process engineering. Neil is an SEI certified lead appraiser for SCAMPI appraisals, certified high-maturity appraiser, Intro

to CMMI instructor (development and services), Six Sigma Greenbelt and Certified Scrum Master. He has a B.Sc. in Computer Science from the University of Essex (UK) and is the co-author of Making Process Improvement Work - A Concise Action Guide for Software Managers and Practitioners, Addison-Wesley. Click this link to find more information on Goal-Problem Improvement.


http://www.processgroup.com/book.html

http://www.processgroup.com/book.html

http://www.processgroup.com/pgpostfeb11.pdf


of 109

Bob Payne

Applying an Intuitive Experienced Based Approach to Agile Adoption

Bill: Today I’m talking with Bob Payne. Bob is President of Electroglide, Inc., a consulting and training company specializing in Agile Software Development. I attended one of Bob’s introductory agile training sessions last year and was impressed with his deep experience that was evident from his presentation and responses to questions. Bob, if you’re ready to get started, here’s the question I have for your today: what’s your best process improvement strategy or tactic that’s worked really well for you or your clients?

Bob: That's kind of an interesting question. The strategy is not necessarily a particular technique; it tends to be around trying to get a handle on the organization, the people in the organization and how to align their goals and desires. To be perfectly frank, there’s no silver bullet; a lot of it is basic discovery work, and a gut feel that I get in conversations about what techniques might work best in that organization.

So when I tell you that it’s a meta technique, a lot of times I will change my strategy based on the client or the particular personality that I'm dealing with in an organization. So if I were to look at the things that I do from a purely mechanical process aspect, I'm not sure you would find much in the way of one process improvement structure.

There’s always a lot of assessment, structured training, and engagement with team members directly. But that doesn’t really give you any sort of recipe. A lot of this has to do with experience. If you look at the Dreyfus Model of Learning, something I happened to hear about from Dave Thomas, it talks about how you move from a mechanical process to a level of expertise. I don’t want to make any bold statements about being an expert, but the Dreyfus Model essentially talks about moving from prescriptive, rule-based learning or operation to moving towards a more intuitive model.

Most of the techniques that I currently employ are based on intuition, having been in tens of organizations, doing an agile transition. And over the years, I see that I have evolved along that Dreyfus Model, moving from a very dogmatic approach to changing an organization—you know, “We’re going to do XP.”

I started out as an XP person, so I was very dogmatic about XP processes. Then as I learned more about organizational change and about how other models of Agile delivery, for example, LEAN, SCRUM, FDD, how those essentially address the same problems with different techniques, it became clear to me that there wasn’t one solution.

http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

http://www.featuredrivendevelopment.com/


of 109

So a lot of my work has evolved around trying to find situation-specific techniques that will work in an organization. It’s really about moving from mechanical process to a point where my goal is to try to understand the organization and apply techniques that will work for both the organization, the people, and the structures that those people create—when you get those people in a PMO, what happens?

Recently I’ve tried to fight against the kind of very dogmatic approaches to agile adoption. The pendulum may have swung a little bit far on situation-specific, and some of my most recent work I’ve been moving back towards specific practice, engineering practice and requirements practice, for example.

But I think that really how I approach it is to move into the organizational change mode and apply the techniques and processes from agile that will allow that organization to get a bit better.

Bill: I think of you as an agile, SCRUM type of person, and I have this perception that you’re probably going to be pretty dogmatic and have a silver bullet that you can bring into a company. So I'm fascinated with your response to this question.

Bob: That’s because you met me at the client that we were just talking about, and they needed a very dogmatic solution—or the organization was asking for that.

Bill: Exactly.

Bob: These are the things you do. The other thing to understand, you know, I may be approaching it on this organizational change level; I also know the people I'm trying to change need rules. So Dreyfus Model says, “You can, at any time, be somewhere on that scale depending on what you’re talking about.”

So I may come into an organization and be further up towards the expert on the agile scale, but all of a sudden someone will ask me to enter my timesheet, and all of a sudden I'm a novice, I need a [recipe]. “Where do I go? What password do I need? How do I get there? Where’s the security office?”

So understand that even though I might be thinking about what is your organizational context and what are the meta issues at hand, generally the folks I'm dealing with are like, “SCRUM, what’s that? What do we talk about at the standup?” And for those people, the answer is, “Do this, and do it for a while, and then we’ll talk about why you’re doing it.”

So I may take a more recipe-based approach to what are the practices that you try. In a retrospective I conducted today, I said, “Well, we tried this thing last week that we thought would help, but it didn’t seem to help, so let’s stop doing that.” And people looked at me like I had two heads, because I want them to learn that improving, continuous improvement is not about picking a thing, doing it and sticking to it if it works or it doesn’t; it is about asking the question, “We thought that would help, did it?”

And if the answer is no, then there’s another question, “Did we not give it a good shot?” or, “Should we try something else?” And so I think it is that idea of moving along the scale of


of 109

experimentation, and if not quantitative, some qualitative measurements of our experiments to determine what’s working. So first you start out with the recipe, and then you show them that it’s okay, it’s ok to experiment, and then at some point they’re kind of on their own.

Bill: Thinking about this approach, I imagine clients sometimes may have preconceived notions about how you’re going to come in and do what you do. Do you run into challenges in meeting those expectations sometimes? They’re looking for a recipe, and you’re thinking you need a little more background and experience here, to size things up and formulate a solution of how they're going to approach improvement.

Bob: Fortunately, SCRUM provided a mechanism that I could be dogmatic about. That is, we’re going to adopt a continuous improvement plan which relies on retrospectives. Outcomes of retrospectives get prioritized by the team, and possibly depending on the scale of the change that the team wants to try or the organization wants to try out of the retrospectives, might involve management.

And we’re going to implement and track that to look at the results. It’s kind of interesting because it’s kind of a trick. You say, “What we’re going to do is we’re going to start out with this recipe, and we’re going to implement a process of continuous improvement, that we’ll tailor the solution for your organization.

And most executives understand that organizational context is important. They also falsely believe that they're the only people in the world that have this problem many times. But those two play together nicely in that yes, you have the same problem, whatever that happens to be, we’re missing dates or quality is low, but you have it in a way that is somewhat unique based on your organizational context.

So I don’t really go in having to trick them into experimenting, because the recipe kind of lends itself to that.

Bill: In terms of what we covered today Bob, would anyone be able to look at something on your website or a podcast that would expand or reinforce anything we discussed today?

Bob: Yes, I'm sure there’s stuff on the podcast. I think really, the key is to, as an organization… If I were to talk to potential clients, what I would say is, “Yes, there’s a recipe.” SCRUM is important; XP is important; LEAN is important—but only so far as they point towards a model of team delivery, and I don’t even want to say software delivery because clearly, these things are used in many different contexts—that looks at the system as a whole.

I think one of the major issues organizations have, they look at it as a, “This team fixed this project,” problem, and Agile, when it is really working, fundamentally transforms the way the organization delivers; it transforms the way employees or associates are engaged with their delivery, and it can fundamentally change the way organizations do business.

Now, you have to start small, and I think that piloting, growing that pilot and investing the time in a continuous improvement or Kaizen process from LEAN, will lead you to a place where you


of 109

are delivering better. But it is fundamentally a journey that requires work and not a mechanical process.

Bill: In the past I worked with a number of LEAN manufacturers as well as more traditional types manufacturing companies, and I had a mix of LEAN manufacturing companies that made the transition, and the difference was night and day. You walk in, the place is clean and organized, it’s smaller, the people react differently; and to your point, it’s a whole different environment.

Bob: Right now I have the Toyota Way Fieldbook, which I haven’t started reading, but it’s on my shelf.

Bill: Yes, a lot of ideas are easily transferable from lean manufacturing into the software world, for sure.

Bob: Well, let’s do a podcast when I'm in D.C., and you can talk about what you’ve learned from these interviews.

Bill: That'd be great Bob. I’ve learned a lot from these interviews, and I’m fortunate to have had the opportunity to do these interviews. I’m truly in awe of the quality and value of the ideas one simple question is prompting from everyone. Thank you very much for taking time to talk with me today!

Bob Payne – [email protected]

Bob Payne is the President of Electroglide, Inc, and a leading proponent of Agile Methodologies and Agile Engineering Practices with 25 years of project management, software development, engineering and business experience. As an early adopter of Extreme Programming (XP), he has worked exclusively as an Agile Coach and practitioner since 1999. He has mentored and managed many projects ranging in size

from five to over one hundred people. As host of the AgileToolkit podcast he has produced over 60 podcasts, recording a variety of industry leaders and Agile practitioners. He has been on the organizing committee of the Agile Software Development Conference in 2007 and 2008. He is cofounder of the Washington, DC XP Users Group. Bob is passionate about training development teams in the use of Agile Engineering Practices that allow them to deliver high quality software in an Agile, iterative and incremental manner. With a MSEE in Computer Architectures for Artificial Intelligence and having grown up working in his family’s restaurant, he brings a unique blend of technical excellence and customer service to bear on his projects and training courses.


http://agiletoolkit.libsyn.com/


of 109

Mike Bonamassa

A Rational Perspective on the History and Current State of Process Improvement

Bill: This morning I’m meeting with Mike Bonamassa. Mike is VP of Strategic Services at MKS and formerly COO of Number Six Software. It’s kind of funny Mike, but it just occurred to me that I was meeting you for breakfast almost exactly seven years ago to the day when you were recruiting me to join Number Six Software! Joining up with you and Number Six Software was one of the best career moves I ever made and I am fortunate to have had that experience to work alongside so many talented software engineering professionals. Mike, before I turned on the recorder, we had already started to address the main question we ask everyone: what is your best process improvement strategy or tactic that has worked really well for you or your clients. You began by talking about Karen Base’s interview, your experience at Rational, and your reaction to what Karen said about having the people on your side.

Mike: It was interesting to me because when I was at Rational, Rational was (I believe) the very first software engineering company, where it was around doing things the right way. You have to consider what the world was like before Rational. You had every different government contractor creating their own language to implement the systems for the government, partially because they thought they needed to because they had great and smart people there, and partially because they realized, “If I create the language and I own the language, I'm going to be doing this for the government forever.” There’s a benefit to it.

So Rational was one of the first companies to actually say, “We’re going to enable good software engineering.” So we created this environment to go do it. Originally it was a purpose built computer, and then it went into different kinds of software. But we had this belief that if you give people technology that supports doing the right thing, people would just automatically change into the right thing.

And the reality is that the only reason Rational succeeded and grew was the technology enabled the change, but the change came from the services and the support that we provided. Rational got a reputation, if you had a program that was failing, you’d buy Rational. It cost you a lot of money, but you bought Rational. The reason was it would turn you around, and it turned you around because we had that technology enabled through the support of these tech reps, and they would come in, and they just knew how to do software engineering, and they knew how to do innately what Karen said, that consultants skill, explaining to people how you can change your behavior and use this tool to enable that change, so that there’s less risk.


of 109

I think that’s what it really comes down to. What the tools do is they enable you to minimize the risk associated with the change, because whenever you’re doing something new, the biggest fear people have is, “I’ve not done it before; what if I screw up?” And what tools can do is you can use a tool to say, “Well, the tool won’t let me screw up; the tool will guide you.” You just have to get them open to the change, and then teach them how to use the tool.

So from the Rational perspective, that was illuminating for me, to see how technology could enable change, but it certainly is not a change agent - that has to come from people.

Bill: Thinking back a bit in terms of Rational, what was it that people were doing that was enabling them to be very successful? Did you see any patterns, strategies, or tactics in that regard?

Mike: It was interesting because the funny thing is there’s this thing called the Rational Unified Process that got pretty popular in software development. Really, it was a precursor to Agile. RUP didn’t come from Grady Booch, Ivor Jacobson or Jim Rumbaugh. They just synthesized it as a process oriented extension to UML.

I always called Grady Booch the great synthesizer because he was able to look at what people were doing, and see patterns of best practices, patterns of behavior, and then he was able to quickly codify and explain those in terms of the process.

So that was really good and hugely valuable. But what he was looking at was what these tech reps were doing. What we were doing is we were working on these really tough programs, it was do or die. So when you’re in a do or die situation, people have to face change.

It’s like you either continue doing what you’re doing or you die, or you change and have a chance to live. So what these tech reps were doing is we were constantly talking to each other and moving between projects and identifying these best practices. So we learned very quickly—that’s why the Rational Unified Process was built around these best practices.

We learned very quickly that the concept of knowing what you need to do in a novel situation. There are different types of systems, novel systems, which you’ve never done before, you don’t have experience with, and then you have systems that are reengineered systems where you have experience with it, but you’re taking it to a new technology platform, and then you have pure legacy maintenance systems.

This can be modeled and associated with that if you have a new team that’s never used it, but the knowledge is already embedded in the code, so the knowledge is there. Where Rational was focusing most of its efforts on were the truly novel systems. And at that point what was in vogue was a thing called 2167a, waterfall development, and that sort of thing.

And it had this methodology associated with it that said you’d get all your requirements right up front. And it was very clear. You didn’t have to be a rocket scientist to see most of these programs were failing because of requirements. Because they would spend years sometimes


of 109

getting these requirements, and then they would go to implement, and the requirement wasn’t complete or wasn’t implementable, or wasn’t relevant.

And so then it would change, and so you would have all these requirements you spent all this time getting; they were all built, it was almost like a semantic network, they were built on top of each other and it wasn’t use cases. There was a hierarchy—so they changed something down here, the ripple effect of the semantic impact was huge.

And then if you got the requirements stable, then you went and did this monolithic design, and you do everything, and then you’re just going to go and code it, and then deliver it. So in each of those things there were problems. But the problems started with the requirements. The fact is that no matter how smart or how well-intentioned you are, they don't really know what they need.

A lot of times that’s why the user interface stuff got in vogue, because it’s like, “Show me.” It’s like, “Well, that doesn’t really do it too because there’s more than just this thing.” (pointing to an invisible field on a screen) You had this recognition that you really needed to do small chunks of functionality. So you start doing small chunks of functionality, and you take them through and implement it, and that’s great.

Very quickly we’re able to get a slice of value for you. That created its own set of problems. And here’s where I think the real key is, to me, to process change. It’s not a step, it’s a philosophy. Because a lot of times people will attack one symptomatic area, for instance, “Okay, we’ll fix the way we do requirements,” but that creates another whole set of issues, and it never changes.

When you look at SEI and CMMI, when you get to constantly improving processes, that kind of an optimized, constantly improving process is the pinnacle, right? That's what real process change is. You change something, and it enables you to break through. But you’re going to find other areas - you can’t ever rest back on it.

So when we changed the requirements and we created this functional [slice] capability in the system, we started to realize now we have ad-hoc architecture, because it’s kind of like you’re building a bunch of systems that didn’t know about each other. So that brought in the idea of, “Maybe we should try to think about what are the things that are architecturally significant that are going to drive our architectural impact and decisions? Maybe we’ll focus on that functionality first.”

Once you started to get that architectural significance in doing that, that started creating an integration issue, because now it’s like, “Well, we didn’t really think about integrating this, so we built this functional capability, we thought about how it was going to have to be modified over time, and we implemented it, and when we built the next thing it broke all of that stuff and it didn’t really work in the environment anymore.”

And so then it got into kind of continuous integration. So each of these different innovations led to new problems, which led to new innovations. Once you got that engine going and you’ve


of 109

got teams that were supportive of the idea, it was really fun to do that. Until people get that this is not a sport for people that want to go and work at a job and do the same thing every day, they should look for legacy maintenance, find a system that’s been built, and you can do that.

Bill: I worked with several lean manufacturing organizations in the past and one of the examples they used was to think of the process as a river. When we lower the inventory levels, we’re lowering the water in the river, but lowering the water to a certain point starts to expose some rocks — the rocks are the problems. Now you can see the problems that you couldn’t see before and solve them. Then you repeat the cycle. Lower the water a little more, and more rocks show up. It’s sort of a similar type of process.

Mike: It is.

Bill: And then you mentioned Karen and her experience—I worked with her during that transition, and it was fascinating how once it got going, people saw how this worked and that it was going to improve things, everybody jumped on the bandwagon, and everybody was all for it. There was a lot of enthusiasm, a lot of progress.

Mike: That reminded me of another thing. This was a fairly common failure mode we saw with the Rational unified process and iterative development. It definitely ignited, but it didn’t stay where it was, and a lot of people failed. And here’s, I think, the other problem that we had with process change. If you have that project that’s successful, and that group of people that gets it and starts changing and innovating, it becomes exciting.

You’re truly creating and you’re empowered, and it’s a very fulfilling thing to do. Other people in the organization see that shiny thing, and they want to become part of it. What happens, though, is that if they don’t get the core of it, you have a project that’s successful because you found certain rocks when you lowered the water, using your example.

Then the next project is, “We know where the rocks are now, so we’re just going to adopt the exact same thing they did, and that’s change.” It’s like, “Well, it’s change; it’s not thoughtful change; it’s just copying.” If you’re the exact same river and the rocks are in the exact same spot, that’ll work for you.

But in our world, novel development, it’s never the same. So that’s where things would fall down, because you needed to have process improvement. We did this project at a large financial organization. We were on Project Enterprise, and we got out there and they were failing miserably. They were doing everything the books said—doing use cases, using UML for design, really rapid development cycle, integrated configuration management, etc.

But they didn’t have continuous integration. They had huge integration issues. But they also had this vertical architecture. They were doing a lot of the best practices; it’s just they had done them by copying them out of a book. They never embodied them, never brought them into the way they thought and applied them in context of the problems they were addressing.


of 109

So we went in there with a relatively small team—the project was probably 60, 70 people, and we have six or seven people, and we had a huge impact on that project. We were able to turn it around and it was successful. Well, all of a sudden, instead of Project Enterprise being this project that’s going to get canceled, it became the glory project.

When we went back a year or so later, everyone was like, “Oh, Project Enterprise,” everyone was trying to take the exact same approach and apply it. It just doesn’t work. So to me that was the most frustrating thing about process improvement is that when it works, people tend to say, “That's great; let’s stop thinking now; let’s just take it and apply that in every situation.”

And then it ends up hurting the original process innovations, because they’re like, “It worked because of Bob, it worked because of Sally; it worked because of the people, not…” Well, yeah, but it was actually the way the people were working together, and they didn’t say, “No, because that worked once, we’re going to do it, we’re going to write it down in the book and never change.” That's where the problems came in.

Bill: I know you used to work for Rational Mike, how long did you work there?

Mike: 13 years.

Bill: From the beginning?

Mike: I think the company started in ’85. I think ’85 was the first product, and I was there in ’89. It was all Ada development back then. Ada was the government’s answer to the plethora of languages that were out there. It was actually a really good language. But Rational had a purpose-built computer that was a development environment for Ada.

It did continuous integration, it did all these things. Basically it was a million dollars for a computer that supported typing in an ASCII interface. It’s like EMACS type stuff. From there it kind of grew. So I was there very early on. I think I was employee 89 or something like that.

And in 2001 when I left Rational, there had to be like 3,000 employees, so it grew phenomenally.

Bill: So you had various roles throughout that time?

Mike: I came in as a tech rep. I came in as a tech rep simply because I was doing software development in C and C++ at the time, and I was trying to apply a lot of the things like encapsulation and stuff you can see, and l still love the language. I was trying to do all this, and when I saw Ada I was like, “Oh my goodness,” because I was also into those kinds of things.

I thought Ada was good. Then I saw this company, they understood software engineering, they got component based architecture. I said, “This is phenomenal.” So from the technology, I was all over it. Then when I got in there, I started to realize that it wasn’t the technology; it was the way we worked with people, the way we got them to apply the technology, the way we got them to think about problem-solving.


of 109

That allowed me to kind of move up to a lead tech rep. And then Rational’s culture was a sales culture, so then you had to move into sales in order to move up into management. So I moved into sales, moved into management. It was fun.

Bill: Anything to add in closing Mike?

Mike: There’s this concept I’ve shared inside Number 6 and places where I’ve been leading at, that I call Compassionate Accountability. I think that too many times everyone says, “We want accountability,” and I think accountability is absolutely core, because without accountability you can’t have trust. If I say I'm going to do something and I don’t do it, there’s no trust.

If you come back and say, “Mike, you didn’t do this,” and I'm like, “Oh man, I totally forgot,” or, “This came up and I wasn’t able to,” then you’re able to restore that trust because you’re able to communicate and get through that period. When I say compassionate accountability, it’s that we know we’re going to make mistakes.

None of us are perfect. Matter of fact, if you’re not making mistakes, you’re not making progress. The key is to have a process in place that says, “Let’s identify a mistake; let’s not obfuscate how we got there. Let’s get to the root cause. The root cause is you just didn’t know what the hell you’re doing? That's okay. Let’s understand that. Let’s get you the training or the support you need, so that that failure pattern doesn’t happen again.”

Now, if you have a failure [mode] that occurs, and it occurs over and over, then it’s not—it’s a different situation. But in that compassionate accountability, it’s like make sure people understand the accountability is there to help you not fail. And I think when you start to do that, it really becomes a core theme that you have to have in order to get process change to occur.

So for me, that’s one of the huge things.

Bill: That's very important, absolutely. You don’t see that often enough.

Mike: You don’t. You hear people talk about it, “It’s okay to make a mistake,” but what happens when people make a mistake? You just slam them down, instead of supporting. It’s frustrating to me because I really do believe in empowering teams, and I think this is another thing that’s important for process improvement, is you can’t have process improvement from the top-down, where you get the one big brain sitting in the office, everyone brings in their problems, “I’ve seen that rock; do this,” and they’ll do it.

That doesn’t work. On small projects sometimes you can have that one hero who pushes through and, through sheer force of will, you get through. All you did was really enforce process control from a top-down, you didn’t do process improvement. You just had a very smart person that’s a little dictator.

Bill: Like you said, it’s too complex; one person can’t know it all anymore.

Mike: Yeah. So what I’ve always looked at is true empowerment. The way you get empowerment is through making people aware of what they’re good at, and also making them


of 109

aware of what they’re not good at. And most importantly, and this is the thing that always gets me, is knowing what you know and knowing what you don't.

Situations we get in the most trouble are when we don’t know what we don’t know. We think we can solve it, and we just charge right in. All of a sudden we’re like, “I'm not on the mountain anymore; I'm skiing and I'm not on the mountain. What the heck happened?” [laughter] So I'm a big believer that if you look at most businesses, go to the 80/20 rule, 80% of the things a business does are not novel or complex; it’s really applying past experience to solving problems. You empower people, you give them all the education, give them the training, you give them the support so that they can handle that 80% of the situation, but you let them know where the edge is.

Because that 20% where you actually need to get creative, you have to bring in innovation and thinking, you’ve got to see it when it’s coming. Those people have to be empowered enough—again, with compassionate accountability—to be able to raise the flag and say, “I'm coming to what I know I don’t know; how do we handle this and support it?”

When those organizations rally around individuals at that point, that’s when I think real change and improvement and stuff can happen. But it’s knowing that edge of what you know and what you don’t know.

Bill: Mike thanks for meeting with me this morning. This has been a fascinating journey back through your career, and I’m sure it will give many valuable perspectives on the state of software process improvement.

Mike Bonamassa – [email protected] I have had the honor of working for one of the best organizations in the world - Rational Software Corporation. The experience at Rational of contributing to and building teams has been a key influence in my own leadership style. Rational was one of the first companies to realize that knowledge of the operation and decision making should be pushed as far down into the organization as practical. Because of that

Rational was able to move in many directions quickly yet still remain coherent around a central culture and vision. Rational also had a sales driven culture regardless of organizational focus. This empowered and sales driven culture has been imprinted on my DNA and is transferable across domains. At Number Six Software we applied many of these lessons and grew the company from $3 Million in 2001 to over $35 Million in 2007. The Number Six growth was both acquisitive and organic - although the bulk of this was organic. At Number Six we built a unique culture of technical and business knowledge interwoven with client facing consulting and account management. Again we empowered employees but also made them engage in the sales process. We integrated our sales and account development with our technical excellence and created growth momentum that positioned us for an outstanding investor return upon sale to ATSC.



of 109

Mario Hyland

How to Achieve Results and Success with Multiple Models in a Small Company Environment

Bill: Talking with me today is Mario Hyland, Senior Vice President of AEGIS.net, Inc (AEGIS). Mario is the founder of AEGIS, and I had the opportunity to work with Mario’s organization over the past year. While working with Mario, I noted two key distinguishing characteristics that caught my attention that I thought would be of interest to our readers.

First I noted that while AEGIS is a small company, they had achieved a rating of CMMI Maturity Level 3 for Development 1.2 Constellation (CMMI) as well as ISO 9001:2008 (ISO) certification. That’s not an easy achievement for a smaller organization.

And secondly, in my day-to-day interactions with AEGIS employees over an eight month period, I noted a consistency, reliability and quality in the work they performed that was above the norm.

With that introduction, Mario, I have one question for you today. What is your best process improvement strategy or tactic that has worked really well for you and AEGIS?

Mario: I would point to three things. The first is that we approached process improvement organically. We knew that in order to be successful at the end of the effort, we needed processes that we could live with. So we didn’t think the right approach was to bring in an outside organization with a turnkey solution for process improvement. Processes, procedures, templates, standards – we knew it had to be uniquely AEGIS’ way of doing things in order for it to be accepted organizationally and therefore something we could live with. That said, we knew we couldn’t get there overnight.

CMMI initially just was too large for us to take on. So we thought, “We’ll start with ISO.” We identified about nine process areas around which we needed to formalize and document our procedures and processes—we needed to develop a quality manual, quality processes, and through the implementation of that effort, we learned a lot. We began to formalize processes and make them consistent across the organization.

Meanwhile, a number of our employees had been with other organizations that had been successful, and some unsuccessful, at implementing ISO and/or CMMI. There was a certain level of anxiety within the organization as we continued down this path. I would say that one of our success factors was that the AEGIS leadership did not simply task it to be done; the leadership actually rolled up their sleeves and participated in getting it done. We helped review, write, edit, and revise, and we were an integral part of supporting it moving forward. That, I think, helped allay a lot of fears.


of 109

So once we had ISO in place, once we had lived with it for a year, we began to investigate CMMI and plan around how we would implement it. We spent a long time figuring out if it could be done, if AEGIS could operate under CMMI, before we even decided to “Go”. But once we did decide to go, we engaged a Class A SCAMPI appraiser as a consultant to provide us with some guidance. We tasked one of our IT professionals who had prior successful CMMI implementation experience to internally coordinate our efforts. We had a couple of dates in mind that we were trying to shoot for, but they were soft dates, they were targets, and not rigid. We were able to evaluate where we were in process and doing what we needed to do, and we ended up shifting the schedule by a couple of months to ensure that we were successful as opposed to ensuring we met a date. Again, leadership made it clear up front and regularly reminded the team that the goal was to implement the CMMI model to fit AEGIS – not to fit a particular deadline. We still drove toward the goal with purpose and resolve, but not with some artificial date hanging over everyone’s head. This helped the whole organization realize that we were committed to doing it right – not simply checking a box.

The second strategy has to do with maintaining these ratings and certifications. They require regular internal and external audits and appraisals to make sure the organization is doing all the things we say we do as part of ISO and CMMI. Some of the challenges we had just standing up CMMI was that we were already ISO, and if you start reading ISO, ISO says that you will only have processes and policies that are fully implemented across your entire organization. Well, CMMI doesn’t implement that way, not unless you do a staged implementation. We found, as we were evaluating CMMI, that the staged implementation is extremely rigid and difficult even in a small organization. Continuous improvement was the way to go, but the two, ISO and CMMI, collided; ISO was looking for everything to be done, and CMMI was looking for focus projects to appraise. We had to spend some time making sure that we ended up with processes and procedures that are uniquely AEGIS and which happen to conform to both the ISO standard and the CMMI model.

So the timing of our ISO audits around our CMMI implementation has been critical so as not to have a major finding during an ISO audit, which could jeopardize our ISO certification, at the same time be bringing in CMMI. So that was tricky, but we did work around it.

Finally, our third strategy has been maintaining our Improvement Opportunity (IO) system. This came out of our ISO implementation and is a key element of ISO, but it has also very effectively supported the continuous improvement philosophy at the heart of CMMI. Our IO system allows any employee or customer to submit, literally, an “opportunity for improvement.” It’s submitted on an electronic form that categorizes the issue and states the issue that needs to be improved. IOs range from corrections to internal forms and templates to suggestions for new employee benefits to corrective actions for preventing service delivery problems. The big benefit of the IO system is that it provides an easy but very meaningful way for everyone in the company to directly contribute to continuous improvement. When someone submits an IO, they are notified of the status as it moves through the steps of analyzing and addressing it, so they know they are having an impact. Of course, everyone understands that not every IO leads


of 109

to change – some great ideas just don’t fit the organization for one reason or another. But our IO process has been specifically recognized more than once by outside auditors as clear and compelling evidence that AEGIS has embraced process improvement across the organization.

Bill: Another element of your strategy is the importance of people and how that forms the foundation for your process—what do you look for in the people that you bring onboard that assures you that they will sustain and improve your process?

Mario: Our recruiting process is—I'd like to say that we’re only recruiting people, but we do find people for specific opportunities. But what I’ve found is through our recruiting effort, we’re looking to find the right people, so the skills, they’re soft skills. The ability to communicate, that’s critical. Identifying people who are always looking to learn is another critical area. These areas as well as the sheer level of experience and expertise are what we look for in prospective AEGISians to differentiate us as an organization.

Bill: You talk about differentiation. You want to differentiate yourself from other organizations out there. How has going through this process allowed you to differentiate? What do your customers and your clients see that you do differently?

Mario: Right, as a small company engaged at a level more typical of much larger companies, we know we need objective ways to stand out. There are a lot of benefits of small companies – agility, attention from the executive level, dedication of the personnel. But size can also be viewed as a risk – lack of depth, cowboy-style approaches that are not repeatable, uncertainly about consistent quality. Implementing ISO and the CMMI model, particularly CMMI ML3, has helped us establish a level of credibility before we walk in the door that sets aside a lot of the perceived risk. Likewise, our focus on senior staff – people who have already been around the block a few times with various waves of technology, people who are excellent communicators, and people who have reputations for solving tough problems with ingenuity and hard work – helps us stay once we get through that door.

Our customers see and appreciate these differentiators. They see how we apply our processes and deliver consistent results. They really look at all of the AEGIS people and they say, “Wow, that person’s from AEGIS and they’re definitely performing above the bar,” and that’s what we try to do. While it’s important that there are individuals and they have their skills, we want to tie that back to the organization. When the client sees four or five of our people doing things the same way – going back to our processes - that’s where AEGIS stands out; that’s where it’s not about that one person anymore, although it’s important; there’s something behind them driving it, and that’s AEGIS.

Bill: I happen to know that metrics are an important part of the AEGIS process. What advice do you recommend based on your experience with metrics?

Mario: Metrics are important to us since they help us see where we’re going and how we’re doing. We need to track metrics as part of our continuous improvement. While we don’t have firm plans to go for CMMI appraisal at levels 4 or 5 yet, we know we can’t get there without


of 109

metrics since organizational metrics are key to level 4 maturity. But there are plenty of obvious practical reasons for tracking metrics. We have found that, as with many endeavors, it’s best to start out simple. Choose metrics that are meaningful and ideally ones for which you already collect the data or can make the data collection part of your normal routine. If you are

developing software, metrics like lines of code are not relevant anymore, but defects per development cycle or sprint are important, and probably right in front of your face no matter what format or mechanism you use for defect tracking. So it’s easy to pull out that metric and track it over time, see the effect on it when you make changes to your development process and so forth. Like the other aspects of process improvement, it just doesn’t have to be complicated. You start with what you can do easily and improve from there. That’s probably our most important overall observation and

recommendation – process improvement can begin with the most basic level of effort. One of our folks mentioned this recently when he was visiting a break room in a large local system integrator’s offices. They had a coffee maker in the room, and evidently the coffee drinkers there had decided to take a simple step to improve the coffee making and consumption process. Someone tacked a sheet of paper on the bulletin board behind the coffee maker and wrote, “Fresh Coffee Made Times.” They added columns for “regular” and “decaf”. Various people (based on variations in the handwriting) had updated the chart with dates and times when they started brewing fresh coffee. That’s a very practical example of metrics used for process improvement and it shows that process improvement doesn’t have to be complicated.

Mario Hyland – [email protected]

Mario Hyland, Principal Consultant, a Senior Vice President and founder of AEGIS.net, Inc. (AEGIS) in 1996. Mr. Hyland’s extensive career spans more than 25 years, with 15 years focused on Health Information Technology. Mr. Hyland currently supports the Department of Health and Human Services Office of the National Coordinator (ONC) – for the Standards & Interoperability Framework

Federal Health Architecture CONNECT as a Federal Health Architect, and the Virtual Lifetime Electronic Record (VLER) Program. Because of his commitment to his customer’s vision and mission, Mr. Hyland has been asked to serve on the VA Architecture Review Board, and as a member of the program’s Risk Management Team. Mr. Hyland has authored numerous publications and has been the plenary speaker and most recently supported ONC at HIMSS11 Interoperability Showcase. Mr. Hyland graduated from Control Data Institute in Toronto, Canada.

Figure 1 - Fresh Coffee Made Times



of 109

Jeff Dalton

An Iterative and Incremental Approach to Process Improvement

Bill: Today I’m talking with Jeff Dalton. Jeff is the President of Broadsword Solutions and his company provides a broad range of process improvement and Capability Maturity Model Integration (CMMI) products and services. Several months ago I started following Jeff on Twitter and periodically checked in on his posts on his “Ask the CMMI Appraiser blog”. It was becoming evident to me that Jeff was highly experienced and offered a lot of sound advice. Recently Jeff announced that he would be speaking at DC Spin on May 2nd, and I thought that would be great opportunity to ask Jeff if he’d be willing to be interviewed for this report. After an exchange of emails, Jeff graciously agreed to an interview and that led to our phone call today. With that background Jeff, I’d like to start by asking you our opening question: “What’s the best process improvement, strategy or tactic that has worked really well for you or your clients?”

Jeff: I’ve been thinking about that question and I have an answer for it. The hardest part of process improvement is not telling clients what they should do—that’s not even part of what we do—and it’s not writing a process for a customer, and it’s not even getting them to write a process and propose one and deploy it, although that is useful. The hardest part, and the thing that’s most impactful and what works most for us, is actually how you deploy it to the community. In other words, how you get people to embrace it and use it.

And the approach we use that has been very successful is an iterative and incremental approach that we call Agile CMMI, and that’s our branded approach for this. In some ways you can think of this as using Agile methods—like you’ve talked to Scott and Hillel, they’ve probably talked about Agile methods.

Using agile methods like incremental delivery, continuous build, collaboration, to not only write software, but to use those same similar techniques to deploy and get people to embrace process as well. So we do a lot of different things to help organizations embrace processes successfully. Because the best process in the world is useless if you can’t get people to actually embrace it and adopt it.

And until they embrace it and adopt it, you don’t even know if the process you developed is even useful. So we use incremental methods where we deploy small components of the process in releases over time. So we might release two or three sub-processes and test it out, and then once the company has embraced those small, easy to digest, useful things, we’ll give them another set of small, digestible, useful things.


of 109

Now, we plan it all out in advance so they’re getting appropriate pieces at the appropriate times. But the real kicker on this one is that that’s how we learn. We learn as human beings by digesting things in very small pieces. So when you look at so many process implementations that have failed, the key thing that was identical is that the company tried to throw a big binder or a big website at all their employees and said, “This is going to be your new process,” and we sort of turned that upside down on its head by saying, “We’re not going to do that; we’re going to give people very small components to start working with and we’re going to keep feeding them those things over time until they have their complete process suite and their process improvement architecture and their methodology and everything they need will be implemented over a period of time,” sometimes a period of months, where they get these things in small enough bites so that they can understand them, they can put them in context, and they can start to embrace them and use them successfully.

Bill: What was the genesis of getting to that strategy? Did you evolve it over time?

Jeff: Good question. My background is in consulting. I was with Ernst and Young for ten years, and in software development. In my days at Ernst and Young, when I was doing a lot of, let’s call it business consulting or process consulting, I noted that almost every process implementation was a failure. It’s a little bit like large-scale software implementations often fail, or software development implementations often fail.

I really struggled with, “What’s the reason behind all this?” and I discovered two things. One is that human beings don’t learn in a waterfall way; they learn in an incremental way. And adopting and using new processes is, above all else, a learning experience. People learning how to do things; people learning that this is good for them; people learning how to change the way that they think, because that’s really what process improvement is all about — changing the culture and changing the way they think.

So going back almost ten years, I really started thinking about, “How do we turn this on its head so that we can make process implementation a learning experience?” and I came to the conclusion that iterative and incremental was the way to do that. The second part of that is as a software person, I realized that there are so many process experts out there in the industry, talking about Six Sigma, CMMI and process improvement and ISO and using all these sort of process-centric languages, and I realized that until we started talking to software developers and project managers in language they can understand—things like object orientation, encapsulation, polymorphism and all the things associated with software development, that they really wouldn’t get what we were talking about.

This Agile CMMI method not only takes the first concept of incremental and iterative design and deployment, but it also embraces the second concept, by presenting everything to developers in a language they understand and using UML diagrams and data flow diagram, things they’re used to using, as opposed to trying to shove them into the process world, which is a world they don’t want to be in.


of 109

All of these things together sort of brought me to the conclusion that process isn’t overhead—process isn’t like this foreign thing that we make people do; process is another word for engineering. And we just, as an industry, as a process-proven industry, we’ve done an awful job over the decades really explaining that well enough, and part of it is our toolset and our methodology.

And our Agile CMMI methodology solves both of those problems. So we’ve had really good success with it. We have probably a dozen clients that embrace it wholeheartedly, and some have even gone and started using it in other parts of their business, and it has really been a very successful adventure for us.

Bill: In terms of clients, do you need to find organizations that embrace this, or do you have to sell it?

Jeff: It’s an interesting question because, and if you talked to Hillel, he probably talked to you about clients who seek certification versus clients who really want to achieve greatness, that’s kind of a thing for him. We have similar ideas. We call it the “Path to Greatness”, that’s our slogan. And obviously you want all your clients to have that kind of mentality, but the honest truth is 95% of clients in my space, which is similar to Hillel’s space, they come to us saying, “I need a certification, I need this piece of paper, I need to be level three or I need to be level two.”

The difference between some other folks and me and our company is that I consider it part of my job to turn them; in other words, to change their mind. So one of the things I believe it’s our responsibility to do—and you can read our website; I don’t want to give you a marketing pitch—you can read anything you’d like because it’s all on there, but I believe that as a process improvement expert or consultant, it’s our job to help our clients understand why this is good for them, because they don’t come to that conclusion, and they don’t come to us with that understanding, usually.

They usually come to us with the need for certification and questions of, “How much does it cost? My job is to say, “Look, okay, we can help you with this, we can help you get the certification.” I then start working with them and really start to change their attitude about how this whole thing works and how it can benefit them.”

And I would say that I need about three to six months with a client to change their cultural understanding of what it is they’re trying to do with CMMI anyway. And once you make them believe it, they’re evangelicals and they go off and spread the word very quickly among their people. I think what’s missing a lot is there’s a lot of guys out there pitching CMMI work or process improvement work, and it’s not that hard to put the acronym on your business card, but I think what’s missing in our industry—and there’s very few guys and girls that get this, I think—and that is the real consulting help we can give our clients, helping them understand why this is valuable to them and how they can use this as a strategic weapon for their business. I consider that part of my duty to educate them on that fact.


of 109

Bill: I think that’s right dead on, Jeff. When I have been involved with a successful implementation, I can see that idea take hold in people as they observe things happening and results happening and things changing, and all of a sudden a light switches on.

Jeff: I think the term consultant is—I don’t want to go off on a rant here, but the term consultant is kind of used loosely with a lot of people. I believe that to be a total consultant means helping them understand culture, helping them communicate things, helping them learn. These things are all above and beyond the certification discussion, right?

So our methodology has all that built into it. It sort of came about over the years as just a reaction to all these problems. So it’s really been good for our clients.

Bill: I think that’s right Jeff. I think you are addressing all the other typically unseen issues that are below the waterline of the iceberg that so often many organizations seem to learn the hard way. How would you describe the mission of your company?

Jeff: The kind of mission I guess I'm on is to help people really understand that this discussion is about culture; it’s not about certification. The big message that I often deliver to clients—as a matter of fact, I'm on my way to teach a class in Dayton on this subject—which is process isn’t overhead; process is the definition of how we do work every day.

One of the little tricks I use when I give this talk at conferences is I talk about how I have a new way to spell “process,” and then on the screen I bring up a phonetic spelling of the word “engineering” and I let people look at it for a minute and figure out what it says, because it’s phonetic and it’s not obvious right away.

I think it really makes the point that process isn’t this thing we do that adds overhead, time and energy, because if you do it that way, then you did it wrong. Process is about how we perform engineering tasks every day, and every engineer in the world, if he thinks about it and it’s presented to him the right way—and we think our Agile CMMI method is that right way—any good engineer you present that argument to will be in agreement and will embrace it. So that’s kind of a mission that we’re on in our company. So I guess that kind of sums it up.

Bill: Jeff, this has been another very informative and revealing interview. Thank you very much for taking time to share your expertise and experience with us today.

Jeff Dalton - [email protected]

Jeff is President, Certified Lead Appraiser, CMMI Instructor, ScrumMaster and author of “agileCMMI,” Broadsword’s leading methodology for incremental process improvement. In 2008 he coined the term Process Debt to describe the crushing, over-bearing processes too many companies employ to achieve a CMMI rating. In 2009 Jeff was awarded the prestigious Software Engineering Institute’s SEI Member

Award for Outstanding Representative for is work uniting the Agile and CMMI communities together through his popular blog “Ask the CMMI Appraiser.” He holds degrees in Music and Computer Science and builds experimental airplanes in his spare time.

mailto:%[email protected]

http://www.broadswordsolutions.com/agileCMMI

http://www.broadswordsolutions.com/process-debt

http://www.askthecmmiappraiser.com/


of 109

Paul E. McMahon

How to Discover Your Own Best Practices for Process Improvement Success

Bill: I’m pleased to be talking with Paul McMahon today. Paul is Principal at PEM Systems and helps large and small organizations improve their technical and management processes and move toward increased agility and process maturity. I recently encountered Paul while I was reviewing presentation briefs at the upcoming Better Software Conference in Las Vegas, Nevada in June. Paul’s presentation brief on improving your organization through Lean and Agile techniques caught my attention, and I decided to pick up his recently published book, “Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement.” I was so impressed with it that I decided to contact Paul and was excited when he agreed to interview for this report. So Paul, why don’t we go ahead and get started by asking you our lead in question: “What’s the best process improvement, strategy or tactic that has worked really well for you or your clients?”

Paul: It may sound strange at first, but even though I'm a consultant I have learned not to try to give my clients answers or tell them what to do. Rather, what I'm finding I'm doing more and more of is helping clients discover what’s already working in their organization, which sounds strange because if it’s already working, how is this going to help them?

To explain this a little more, I’ve learned through the years there are two ways to look at process improvement: The traditional way is— when we see behavior that isn’t quite right—to immediately try to correct it and get the behavior going the right way. But that’s where we often run into resistance because that’s where you start telling them what to do. They’re not so sure they should listen to you because you’re an outside consultant.

They think: “Do you know my job?” or “Why should some outside consultant be able to tell me what to do?” So the other way I like to look at it, to avoid that scenario, is to go in, listen to what’s going on, and to talk to people, letting them tell me what’s happening. I take notes and just try to discover the behaviors that are already happening—good and bad.

The interesting thing that I’ve discovered is even in an organization that needs help, there are always people that have figured out some really neat ways to address common problematic issues. Often their techniques aren’t even considered a standard practice. So what I like to do is observe that, extract it, and then help spread it across the organization.

I hadn’t really thought about it until you asked me this question. When I considered it, just this past weekend, I realized this is definitely the best strategy that I’ve come across. I think the reason it’s the best strategy is that it really does avoid all those issues of, “Why should I

mailto:http://www.amazon.com/Integrating-CMMI-Agile-Development-Performance/dp/0321714105/ref=sr_1_1?ie=UTF8&s=books&qid=1304649164&sr=8-1


of 109

change?” or “Why should I believe a consultant who doesn’t really know my organization or my job?” It removes those common obstacles.

Bill: Paul, can you share any examples with us?

Paul: What I talk about in the book are some of the best practices that I discover this way. People sometimes don’t even think of these as practices. I call them local practices. They’re usually not documented, but they’re things that are happening and helping people succeed in each organization.

For example, in the Bond case study in the book I talk about doorway risk management. This is something I actually observed. I'm watching the way they do risk management. This organization really was successful because they lived and breathed risk management. When somebody was worried about something, they’re in the doorway of their manager, and they’re already working out the mitigation strategies.

That wasn’t written down. It was just something that was happening. But I actually wrote this down, described it, and helped them train others in the organization. We trained people and spread the word this was an expected practice. People loved it because when we trained it, it wasn’t the consultant saying, “Here, this is what you should do.” I brought the people in that were already doing it in their own organization, and I was just the facilitator.

I said, “Joe, could you describe what you do?” And then they shared with each other their own best practices. The more I do this, the more I'm finding as a consultant I have less work to do, because what I'm really doing is motivating the people in the organization to talk to each other. Just a few other quick examples—again, a lot of them are in the book:

What I call the super resource spreadsheet. Every company does something like this, but they don’t write it down. They don’t train others in how they do it or why they do it. There’s usually somebody managing the resources across projects, and somebody usually has this big Excel spreadsheet with a lot of valuable information, such as all the engineering people in the company listed—and what projects they’re working on.

They’re often tracking how much work each person is doing on each project. They’re making decisions related to, “Well, if I'm having trouble on one program, I might have to pull Joe off of this one and put him over here, but what’s the impact?” Some keep a column in that spreadsheet of important things to consider with respect to people working certain projects, such as potential impacts to that project if this person was moved to another project. They use this informal spreadsheet with all this valuable information to help make better decisions.

I’ve brought this to the attention of a number of companies. Few companies ever write this down and describe it as a best practice, but something like this is used in many organizations. This is an example of a technique that is used to help with critical decision-making that frequently has to be made in organizations.


of 109

Let me give you another example with peer reviews. The interesting thing is there are a lot of people who think a peer review has to be formal, “I go at a set time and I go into a room.” But one of the things I’ve observed in a lot of companies is the best peer reviews are the ones that happen when a situation occurs and they know that they’ve got to get their best people together to talk about this situation. The review just happens at that point when they knew they needed it. Some people may view this in a negative light because it is ad hoc, but I see it in practice as smart because it works.

When I observe this happening, I ask someone in the organization, “What are the criteria you are using when you call such a meeting?” When they think about it they realize they do know, but they haven’t really described it and told others about it. So again, I pull that information up, extract it out, we write it down, and then we say, “This is expected. We expect you to pull people into a room, talk about issues and solve problems when you have these types of situations because they have proven to work in this organization in the past.” By making more of the people in the organization aware of such practices the organization as a whole can begin to perform at a higher level and do it more consistently.

Another piece of this strategy I really like is what I call tailored workshops where I'm just facilitating. I make sure to have people in the workshop that are doing these local practices. Then I just turn it into a sharing and have the different people in the organization share with others some of these best practices they never even viewed as best practices.

Bill: I think that’s a fascinating approach about helping them to discover and find the answers themselves Paul. You point out the practices that are so well known to them they aren’t even recognized. I’ve seen instances of how successful this approach can be, but it seems like there are so many distractions, there are so many ways to get off-course, and I'm wondering if you found any ways to keep a focus on this approach.

Paul: I agree. You do need to stay focused on the right things because I have also found you can get overwhelmed and go too far with this approach. The way to keep it focused and to really keep value there is not to try to discover anything. If you talk to people and you ask them how they do their job, they will start sharing with you. You will start hearing where their pain points are in getting their job done. I listen for what’s getting in their way.

When I do this I start to see patterns in organizations of where the trouble spots are. Then I listen for the people who best know how to solve those common trouble spots. So the things I raise up in these workshops and get people to talk about aren’t just any particular neat thing they’re doing, but it’s something that someone is doing that others need help with, and that’s why it’s of value and why people get excited about it. Typically in the workshops if I ask people how they might handle some specific common issue that I have heard about, I also make sure I have somebody there who has faced a similar issue and has found a good solution and is willing to explain that solution to the group.


of 109

That keeps a focus on this approach. We’re not talking about a lot of things. There are often just a few of these key trouble spots, or patterns, that keep reoccurring and really have value if you can show people how to handle them effectively.

When a project starts to get into trouble, it’s not uncommon that there are two or three things that are causing it, and it’s not the same two or three things in every organization. Each organization seems to have their own specific patterns that tend to repeat. So if we can find the best way to keep away from these common patterns, or solve them rapidly when we sense them, and share those techniques it leads to real improvement in the organization.

It’s not just, we’re putting processes in place for process’s sake; we’re putting them in place where we can really see value added that can help the people in the organization with the common obstacles and trouble that they face.

Bill: Paul, we’ve been talking about ten minutes now and before we end our talk today, I’d really like to ask you why you wrote your most recent book. I’m so impressed with how well it’s written. And there are so many great insights and examples throughout the book. It’s clear to me that you put a tremendous amount of work into this book.

Paul: The thing that really motivated me to write that book was the misunderstandings that people have about CMMI. To me the best way to use the CMMI is to turn the model around and not look at it as a set of dictated practices, but turn the practices in the model into questions. Asking questions, and then listening—that’s the way to use the model. Using the model this way got me into this mode of just listening, and then finding where we can really help this organization, rather than just creating a lot of processes.

I think when you do that, people really quickly begin to see how the model can help them, and how it can work well with Agile approaches.

Bill: I think the CMMI model is a very powerful tool and it’s not exactly obvious at first glance. My motivation to write this interview series with people like you came about in a similar manner. I was involved in a successful CMMI implementation and then a new CIO came in at the very end who didn’t understand it and killed it.

Paul: The mistake that gets made is, when people decide, “I'm going to use the CMMI and I'm going to use it right now because I want to be level three in six months.” If you take that attitude and you put that schedule in place and you start driving for a formal appraisal as your primary goal, you totally lose the value of using it less formally in this question mode, which really is needed before getting focused on a formal appraisal.

You need to give the organization time to find out where they need their improvements and to implement appropriate changes or just share what is working across more of your organization. So it’s a less formal way of using the model. If you jump right to the formal way of using it for an appraisal, you won’t get the value.


of 109

Bill: Paul, thank you very much for talking with me today. I really enjoyed talking with you today. And I’ll leave our readers with this teaser. “If you’re looking for a guaranteed way to improve your golf game or just about anything, pick up Paul’s book and read chapter 9!”

Paul McMahon - [email protected]

Paul is Principal, PEM Systems (Binghamton, NY), helps large and small organizations as they improve their technical and management processes and move toward increased agility and process maturity. He has taught Software Engineering at Binghamton University, State University of New York; conducted workshops on Engineering Process and Management, and published more than 35 articles on software and

systems development and management, including several in CrossTalk, The Journal of Defense Software Engineering. Paul is the author of two books, Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement (August, 2010) and a book on collaborative development, Virtual Project Management: Software Solutions for Today and the Future (CRC Press, 2000).

A frequent speaker at industry conferences, including the Systems and Software Technology Conference, Paul has been consulting independently since 1997. His experience, insights, and recommendations he shares with his clients reflect 24 years of engineering and management experience working for such companies as Link Simulation and Lockheed Martin. Paul holds a BA degree, Magna Cum Laude, in mathematics from the University of Scranton, and an MA degree in mathematics from Binghamton University.

His current interests and work with clients focus on the use of Agile Methods, Lean techniques, the CMMI framework, and distributed teams. Paul provides tailored workshop training for his clients. He is also currently on the leadership team of an international initiative to refound software engineering founded by Ivar Jacobson, Bertrand Meyer and Richard Soley (www.semat.org).

Paul is a Certified ScrumMaster and has been a member of the CROSSTALK Editorial Review Board since 2004 and continues to serve on the board in 2011. Past and current clients include Raytheon, L3 Communications, BAE, Alion Science and Technology, Northrup-Grumman, and the Department of the U.S. Navy.




http://www.semat.org/


of 109

Karl Wiegers

Three Key Questions to Ask at the Start of Any Process Improvement Initiative

Bill: On the phone with me today is Karl Wiegers. Karl is Principal Consultant at Process Impact and has broad expertise and experience in all aspects of software engineering and process improvement. I’ve read one or more of Karl’s book on software requirements, but I decided to contact Karl after reading about the sessions he will be leading at the Better Software Conference in Las Vegas, Nevada in June. Karl will be delivering a keynote presentation on software quality, as well as leading a tutorial on project management best practices. Karl, I’d like to begin by asking you: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Karl: I always like to begin by asking anyone who’s embarking on a process improvement journey of some kind, “Why?” Why do they want to do something different from what they’ve done before? What I’m hoping they’ll say in the answer is something about the business results that they want to achieve, that they want to get some kind of better business-related outcome than they’ve been enjoying to date.

In fact, that was my premise when I started my company, Process Impact, in 1997. I thought long and hard about the company name. Finally I realized that my mission is to work with clients to try to have an impact on the processes they use to build software, and I want those processes to have an impact on their business outcomes.

I always like to ask “why?” and sometimes people really haven’t thought about that, I’m afraid. I think sometimes they’re looking to jump on some bandwagon. I once heard a great phrase to explain that, the idea of a manager taking a flight somewhere and coming back and saying, “Oh, look what I just read about; we should do that.” That’s called management by BusinessWeek, and I think that it happens.

So the first thing I want to know is why people are doing this, and that leads to a very natural second question: How will you know if you’ve achieved the desired results? In other words, what can you measure or observe that would tell you if whatever changes you're making are getting you where you want to be?

I think a lot of people haven’t thought about that, either. They know that things could be better, they know they’ve got some pain, but they haven’t really thought about how to measure that and how to measure what would be better. By the way, I think pain is a great motivator for change. I don't mean artificially induced external pain—someone beating on you with a hammer—but rather the very real pain that people experience because of the ways they’re currently working that aren’t giving them the results they would like.


of 109

I’ve been to several clients where people said, “You’re here because the pain has become too great.” That tells me that they’re really looking for ways to reduce the pain.

Bill: Did you look for satisfactory answers to those questions? Do you need to have satisfactory answers before you work with a client? Or did you help them really get to a good response to those questions?

Karl: It’s really more of the latter. If I don’t hear an answer that suggests to me that people have a pretty clear idea of what the pain is and what they would like to see as better outcomes, then I think that’s an important conversation to have first. You need to try to steer people toward that clear understanding. If you don't have an actionable outcome, then it’s not obvious what to do to try to change how you're working today.

That leads to the next question that I’m interested in with a client, which is to say, “Okay, if these are the better results that you want, why are you not already getting those results?” I’m a big believer in root cause analysis. Instead of just hopping on the latest bandwagon, or just assuming that something you’ve learned about or heard at a conference is going to solve all your problems, do some root cause analysis. Ask yourselves, “Okay, what problems are we experiencing or what results do we want?” and then think backwards to ask , “Why are we having those problems or why are we not already getting those results?”

If you come into an improvement situation with preconceptions that, “We want to do X,” whatever X happens to be, whether X is CMMI or X is convert everybody to Agile or whatever, then I don't have much confidence that that is the right thing to do. It won’t necessarily address the real root causes of why people are not already getting the results they want to get.

Bill: What type of reaction do you get to that question? Does it result in a lot of analysis? Do they usually have answers to that right away?

Karl: My experience has been that most people do not think in terms of root cause analysis. It’s rare that I go someplace where people have already carefully thought through that and say, “Okay, here’s what we want to accomplish. Here’s what we're doing now; here’s why we think we aren’t currently getting better results, so help us figure out the right way to get from here to there.”

I just have not encountered that very often. I think people do have a sense of what’s wrong. Frankly, when I’ve done some kind of process assessment for a client, it’s rare that I tell them something they don’t already know. I’ve had the same experience when I’ve been on the receiving end of process assessments. Years ago, when I was at Kodak, consultants would come in and they poke around and talk to people and look at some documents. I found that you can very quickly learn what the likely problem areas and process weaknesses are.

When you tell the client your observations, the reaction is often, “Yeah, we knew that,” but it’s somehow better to hear it from me, coming in as an outsider without being caught up in the politics of the organization, coming in without a particular axe to grind. I try to be very methodology-independent; I’m not a methodologist. I don't have a methodology package to sell somebody, that’s not what I do.


of 109

It seems to be okay to hear about your problems and process shortcomings from an outsider, even if you already knew what they were, so I find that people aren’t usually surprised by what I tell them. But I don’t really get the sense that they’ve done a lot of that kind of structured root cause analysis. When I have worked through some root cause analysis with a client, usually in hour or less you can get a pretty good understanding of where you might want to start doing something different.

To me, process improvement is really simple. Process improvement is just doing something better tomorrow than you did it yesterday. Everybody has a process, some way that they get things done, whether it’s well-documented or rigorous or not.

Bill: Karl, you have a new book called Pearls from Sand: How Small Encounters Lead to Powerful Lessons. I know it covers a wide range of topics, but does it have any lessons that apply to process improvement that people might want to read?

Karl: It does, actually. I should mention that the pearls of wisdom that I describe in this book are all life lessons that I’ve accumulated over my years. Many are from ordinary conversations I had with a teacher or a friend, where they just happened to say one sentence that really resonated with me. I still remember that sentence decades later, and I think about it from time to time and use it in my life. Other lessons came from experiences and observations that I’ve had where—if I’m paying attention—I realize, “Wow, there’s an important message in here.”

One of the chapters in the book is titled “An Ounce of Preparation.” What I describe there is the value of thinking through what you need to do before you actually do it. I find that, for situations where there’s a significant risk of something going wrong or a significant downside if something does go wrong, it is well worth the time to do some planning to try to reduce those risks and improve the chance of things going well.

For example, I like checklists. Checklists are very simple and easy. They’re reminders of things that I might otherwise overlook. I use a travel checklist, so when I’m taking a trip of any kind, whether it’s personal or business, I pull out my travel checklist. I go through and customize it (in process terms, that’s called tailoring) for the specific needs of this particular trip—whether it’s international or not, or whether it’s an event I’m driving to versus flying to. By using that little checklist, I never end up someplace missing an item that I wish I’d taken along.

I described my travel checklist to another software consultant. He laughed a little bit and said, “I have one item on my checklist: slides.” But then he told me about the time he went to a conference to give a half-day tutorial, only to discover that it was a full-day tutorial, and he did not have enough slides for that. So even his one-item checklist failed him because he didn’t take it seriously. I just find that little work aids like that save me time, reduce stress, and give me confidence that I don't have to worry so much.

Another story I tell in that chapter is more sobering. My brother is a real outdoorsy guy in Boise. He’s always very well-prepared when he goes out into the desert and the mountains. That saved his life about a year ago when he slipped on an ice-covered rock at the bottom of a canyon, fell, and broke his femur, dozens of miles from anywhere. That’s a serious, life-threatening injury. But Bruce was well-prepared with a companion, emergency equipment, tracking devices, batteries for all of his electrical devices, and so on. He ended up getting

http://www.pearlsfromsand.com/



of 109

winched out of this canyon several hours later when rescuers arrived, then flown by helicopter to the hospital in Boise, where he had five hours of surgery. Now he’s doing fine. But he’d probably be dead if he wasn’t well-prepared for something like that.

You hope you never need to follow your emergency procedures, but boy, if you do, it’s a real good idea to have them. So I like these kind of systematic planning things.

Bill: Karl, I would agree. I’m a private pilot and in the flight environment you learn very quickly how essential and necessary checklists are for even routine tasks. So before we wrap up, Karl, is there anything else you’d like to talk about?

Karl: There are some other key ideas that I think are important in software process improvement. These are little one-liners that I keep in mind.

One point I like to make is that anytime you're asking people to do something different from what they’ve done before, their first natural reaction is, “What’s in it for me?” And you know, when you're talking about process improvement, sometimes there’s nothing in it for a particular individual. He may be asked to do more work or a different kind of work in a way that doesn’t provide evident value to him, but does provide value overall downstream, perhaps by saving testing time or preventing rework.

In my view, the correct question is, “What’s in it for us?” I really hope people will get into the mindset of looking at it more holistically and less personally, to ask, “If we do these things you're suggesting, what’s likely to be our collective benefit, even if certain individuals don’t get a personal benefit?”

Bill: I think that’s a really important point, Karl. It’s a subtle change, but I’m sure its impact can be far reaching in keeping an improvement effort moving forward.

Karl: Right. I think anybody who’s being asked to do something differently has the absolute right to ask, “What’s in it for us?” and they’re entitled to a sensible answer. You should be able to describe how, if we do these things differently, there will be some net gain for the project, or the team, or the company, or the customers, or the universe as a whole. If you go through that thought process and you can’t identify clear expected benefits, then whatever is being proposed probably is not a very sensible thing to do.

One other point is that you can’t ask people to do everything radically differently on Monday. You don’t just throw them the big procedures book and tell them, “Forget everything you know; here’s what we're doing now.” You need to take baby steps. People, and organizations, can only absorb so much change at one time. It takes time to internalize doing something in a different way until it just becomes part of how you do your job, as opposed to being a burdensome process script that you're following.

One more operational principle is that management must keep the process improvement activities visible. If you start out with a big flurry of noise and commotion and change demands and then it drops away, the team members will conclude that it’s not important after all. “I’ll just wait it out,” they say. I’ve actually been told this by people in an organization going through a major software process improvement effort.


of 109

Another key phrase I like to use is “Gentle pressure, relentlessly applied.” The change agent or managers need to steer the organization and the individuals in it towards different ways of working. They need to keep the improvement effort visible, ask to know what’s going on and to see the results so far, and make course corrections, to gently push people toward where the organization is trying to go.

Bill: Karl, thank you very much for talking with me today. You’ve shared a lot of valuable insights that I’m sure will help many organizations with their process improvement initiatives.

Karl Wiegers - [email protected]

Karl Wiegers is Principal Consultant with Process Impact in Portland, Oregon. He has provided training and consulting services worldwide on many aspects of software development, management and process improvement. Prior to starting Process Impact in 1997, Karl spent 18 years at Eastman Kodak Company. His responsibilities there included experience as a photographic research scientist, software applications

developer, software manager, and software process and quality improvement leader. Karl has led process improvement activities in small application development groups, Kodak's Internet development group, and a division of 500 software engineers developing embedded and host-based digital imaging software products.

Karl is the author of the following technical books:

Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007) More About Software Requirements: Thorny Issues and Practical Advice (Microsoft Press, 2006) Software Requirements, 2nd Edition (Microsoft Press, 2003) Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002) Creating a Software Engineering Culture (Dorset House Publishing, 1996) Karl's most recent book is a memoir of life lessons called Pearls from Sand: How Small Encounters Lead to Powerful Lessons. Please visit PearlsFromSand.com for more information. Karl has also written more than 175 articles on many aspects of software, chemistry, and military history. He has served on the Editorial Board of IEEE Software and as a Contributing Editor for Software Development magazine.

Karl received a B.S. degree in chemistry from Boise State College, and M.S. and Ph.D. degrees in organic chemistry from the University of Illinois. He is a frequent speaker at software conferences and professional society meetings. When not at the keyboard, Karl enjoys reading military history, cooking, drinking wine, playing his Les Paul and Stratocaster guitars (loudly), and riding his Suzuki VX800 motorcycle (quietly).


http://www.processimpact.com/pubs.shtml#projinit

http://www.processimpact.com/pubs.shtml#moreabout

http://www.processimpact.com/pubs.shtml#reqs

http://www.processimpact.com/pubs.shtml#prbook

http://www.processimpact.com/pubs.shtml#csec



of 109

Mary Lynn Penn

Listening to What’s Needed and Not Limiting Yourself to a Single Solution

Bill: Speaking with me today is Mary Lynn Penn. Lynn is Director of Strategic Process Engineering at Lockheed Martin Corporation in King of Prussia, PA. I met Lynn last month after listening to her interview on Tom Cagley’s SPAMCast. Lynn shared a lot of valuable insights on process improvement during the interview, and I’m pleased that she’s on the phone with me today and agreed to take on our key question. So with that introduction, Lynn, I’d like to ask you the opening question that we ask everyone: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Lynn: One of the best strategies I think we have is listening to what is needed, and not limiting ourselves to a single solution. So many people listen to their customers and say, "You need CMMI," or, "You need Six Sigma," or, "Oh, you need some ISO standard that's out there." I like to listen to what they really need, dissect it, if you will, to find the actual low-hanging fruit, and what they're looking to achieve.

I ask those typical five "why’s" to get to the root cause of what they're looking for. And then a lot of times I use a combination of standards to understand what they really need. Now, of course if somebody comes to you and says, "I need a Maturity Level Three against the CMMI for development," that's okay.

But if it's a real process improvement need, you need to listen and then provide a strategic approach, which could be a combination of standards. I very much advocate the use of standards and models as best practices versus registration/certification/I got the hat and the t-shirt.

Bill: That seems to make so much sense Lynn but seldom discussed in my experience. How would you compare this approach versus a prescribed approach?

Lynn: Very often when you have a prescribed approach, it's to a set discipline and it's stovepiped. So a lot of times—now, this isn't every time. But a lot of times when you get a single standard, you're leaving somebody out, or you're not focusing on that part of the business, or some other discipline isn't involved. So you get this interface that's a ‘throw it over the wall’, and this makes it difficult to optimize the process within the focused discipline. However, if you look at the process and optimizing its operability you have to look across disciplines.


of 109

So if you don't take a look at the holistic view, you could leave somebody out by singling in on a single standard. An example I'll use is recently here at Lockheed Martin, IS&GS we’re very much involved in services. So we have programs that we have ISO-20000 either because they're required contractually or for various other reasons.

But a lot of them also now have to be concerned with cyber security. Obviously, services associated with databases, etc. So we've used a combined approach of ISO-20000 and ISO-27000 to gain a real focus on the service associated with cyber-security concerns. In fact, I think recently within the last month there was a press release that came out about that particular approach that we used.

Bill: I think you make an interesting point there about when you use a prescribed approach, you're frequently leaving someone out. I've seen that and the impact it can have. But I'm also thinking this approach must be much more challenging for you or the process-team to manage.

Lynn: It is, but that's why I'm saying you need to listen and understand the real issue out there. Long before CMMI, when we were implementing software CMM, we realized that unless we got discipline into the systems engineering, throwing those requirements over the wall wasn't going to make it. So we picked up the systems engineering CMM, and we combined the two to really get a true engineering approach.

We realized the program managers needed discipline because we disciplined everybody else—let's do a trade study out there, find out if PMBOK or something else is what we need for program management. The challenge is doing the trade studies on the standards that are out there, keeping abreast of all the things that are out there, all the opportunities you have for these best practices that have been collected.

And it's challenging because you have to stay current. What we do as part of the trade study, we make sure that at least one person goes to a foundation or intro to that particular standard so there's not some nuance that we thought existed there and really was off from what we ultimately need.

I think the challenge is that, and the difference is that, we not only have to take a tactical approach to process improvement, but a strategic approach. And I think a lot of times people just think of process improvement as tactical and not strategic.

Bill: Lynn, can you describe the reaction from management and staff to this type of approach?

Lynn: Number one, obviously, with management, you can't do this bottoms-up, so you absolutely have to do it top-down. You need management commitment to process. But the interesting thing about this approach is it's not like the, "Oh my gosh, here's another standard off the street that we have to get registered in. Or, “Oh my gosh, I'm doing this for ISO, and this thing I’m doing for CMMI," etc. The answer becomes “I’m doing this for the business.”

We don't really advertise the standards, etc., that is, to Joe on the floor. We try to integrate and put the goals or the requirements of these standards integrated into the normal business rhythm,


of 109

so they're not seeing it as layered on, "Oh, I'm only doing that 'cause we want an ISO registration this week."

We try and integrate it right into the business rhythm, and that way they take it as a standard improvement. And by the way, when we talk to the workforce or when we do a normal quality audit that turns out to be an ISO audit, if they end up registered against a certain standard, it's funny because nobody turns it back. As a result, they find out that it wasn't that tough.

But we really avoid that layering on or advertising that you're doing this for ISO, you're doing this for CMMI, you're doing this for AS-9100. Yes, we have the mapping and we know why everybody's doing the certain things. But they just need to know they're doing good business practices.

Bill: Do you have any advice for people who are resonating with this on how to take this type of approach?

Lynn: Not to use this as a plug, but I've actually been asked to write technical notes and articles about multi-standard use and the implementation and the strategies around it. In fact, this is very timely because I actually have a meeting with one of the people that asked me about that article tomorrow afternoon.

So we realize that people have looked at the standards as stovepipes, and it was the article that came out on the ISO-20000 and 27000 adoption that caused someone to call me and ask, "Why did you use those two?" And I went down the avenue that they were two that I needed at that time.

But you always should be broadening your approach to look across multiple standards. So you're right, there's not a lot out there, but hopefully I'm going to remedy that in the next few months.

Bill: That'd be great, Lynn. I think it'd be very valuable to people and I’d be happy to include a link here when it’s available. Thank you for speaking with me today.

Mary Lynn Penn – [email protected] As Director of Strategic Process Engineering, at Lockheed Martin Corporation,

Information Systems & Global Solutions (IS&GS), Lynn oversees policies and process command media, process compliance via audits and process improvement activities. She develops and manages compliance to multiple standards including CMMI DEV, CMMI SVC, ISO 9001/AS910, ISO 20000 and ISO 27001.

Software Engineering Institute (SEI) Capability Maturity Model (CMM) involvement began with version 1.0 and has progressed to the current CMMI version 1.3. She has participated in multiple formal SPAs, CBA IPIs, Assessments using the Acquisition Model, Risk Evaluations and supported multiple Software Capability Evaluations per versions 1, 2, and 3. She has supported multiple assessments using both CMMI DEV and CMMI SVC. She is currently certified as a CMMI Instructor and a SCAMPI B/C Team Lead and an SEI Affiliate. She is the Industry lead for the CMMI V1.3 model release.



of 109

Lynn has a BS in Mathematics from Villanova University, she has done graduate studies in Computer Science and Management Information Systems. She is a certified ISO 9000 internal auditor at Lockheed Martin. She is also a Certified Greenbelt and Blackbelt in Six Sigma and Lean Techniques.

She has published a book “CMMI and Six Sigma: Partners in Process Improvement”.


of 109

Ally Gill

Changing the Conversation from Process Improvement to Process Management

Bill: Talking with me today on a Skype video chat is Ally Gill. Ally is an independent Software Process Management consultant based in the UK. Ally was an early reader of this publication and has frequently commented and promoted it on his website, Twitter and LinkedIn. We’ve communicated on a number of occasions and I’ve had an opportunity to read his numerous posts, papers and presentations on process improvement. I think Ally has some keen insights to share on process improvement and I’m glad he was willing to take the time to talk with me today. So Ally, I’d like to begin by asking you: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Ally: I've been thinking about this for a while, because you've had some really great people in this series so far, and they've all said so many good things, so I've been trying to come up with something original and it's been quite a challenge.

There are a number of things that have come to mind. One of the ideas that I've tried to promote in my writing, on my website, and out in the field, is the concept of moving away from pure process improvement to process management by thinking about the whole package of process related activities rather than just improvement. When you think about it, you don't talk about quality improvement, you talk about quality management. That encompasses quality improvement, quality planning and management, quality assurance, quality control and compliance and I like to think about process improvement and process management in the same way.

A key risk is that when an organization embarks on a process improvement initiative, it's quite often done as a big gesture with lots of internal promotion but not necessarily done with very sensible objectives. It's more along the lines of we want to get to level three CMMI by November next year or something similar, rather than doing it for the business benefit that should really be underpinning what you're doing.

But so often, with a goal like that once the target is achieved everything stops. Things just start to revert to their previous state, because they don’t have that concept of continuous improvement and the continuous management of those processes once they've got them in place. I've seen lots of organizations which have spent huge amounts of money, and they've come up with not unreasonable process, they've tried to get them embedded, they've gone through the appraisal, they've got the badge, and almost immediately they revert back because all the work's done as far as they're concerned. And then the cycle starts all over again when they decide they need to be reappraised three years later.


of 109

For me, process management also encompasses the role of organizational change management. At the end of the day, the technical aspect of process management is really quite easy. Anyone can sit down and write a set of processes and procedures, and a corresponding set of document templates. Heck, you can go out and buy a Quality Management System off the internet. Getting the right processes and artefacts is a bigger challenge, but it’s still largely a technical exercise, especially if you align them to what already happens in the organization.

But, even after more than 20 years that we've been doing this, people still have a tendency to write their processes, publish them on a web site or wherever they store them, and think they are done. They just expect their staff to use them. There’s no training, there's no education, there’s no context. It's just, "We've done the hardwork, now it's up to you, you shall comply to these processes and templates, and that’s how we are going to measure you"

Unfortunately, people don't work like that. They reject that kind of command and control environment and management, because it's "Do as I say, not as I do." and there is little explanation as to why these things need to be done (and often they don’t!). The difficult part of process management is winning hearts and minds, and you can only do that by involving and engaging with the people who do the work.

Bill: I totally agree with you, Ally. Can you talk about how you infuse a longer term, more progressive, quality management perspective that results in on-going continuous improvement?

Ally: I think unfortunately, as a consultant, quite often you're not in an environment at the right time to be able to get that message across. Sometimes I arrive when it's too late; sometimes I've left when it's too early. I think it's important that you set the principles in place so that people have those guiding lights to follow, and continuously reinforce that message while you’re in the organization.

If you constantly repeat basic concepts and principles as if they were a mantra eventually some of them start to take root. Senior management especially have to understand that process improvement and management need real commitment and deeper comprehension about what they are really trying to achieve rather than just posturing and pandering to the latest management fads. Success becomes much more likely with a shift in attitude and how you commit to what you're doing in your environment.

Bill: Do you speak to this perspective and challenge directly when you work with clients? How do you do get organizations to look beyond the effort at hand and address the longer aspects?

Ally: I think for me, the most important thing is to have a real and genuine sense of passion and desire to improve. Find those people in the organization who share that excitement and drive that I have, and that other people in this business have. And try to organically grow that passion and enthusiasm within people in the organization. Find the real change agents. They’re not necessarily the guys in the process improvement team or management team.

They are more likely to be some key project managers, some disenfranchised engineers and probably a small selection of mid-level and senior level managers. If you're really lucky, there


of 109

will be someone right at the top who understands what you're trying to help them do, and who is doing it for the right reasons, rather than as a cost-cutting or badge-seeking exercise.

So you've got to go out there and get them on board, get them to look at the websites, to read the books, read the documentation, go to the seminars and conferences and learn from other people's mistakes as well as their own. There is no need for anyone to waste time and money by failing to address the basic principles involved in process management which are brilliantly addressed in this series also.

Bill: Ally, what else do you think the process improvement community could be doing to improve the overall situation?

Ally: At the European SEPG conference a couple years ago in Prague, Peter Leeson addressed this topic. Peter stated, "We have been doing this 20-30 years, and we're still getting it fundamentally wrong." I think a lot of my colleagues out there would say we don't hit the right people. We don't get the C-level execs there. We don't get the real decision makers or the real budget holders there either.

The people who do attend are process improvement specialists, and they're talking their own language to each other and the already converted. Until we can start to get to those C-level execs to attend, I don't really see anything changing very much, which is frustrating.

Bill: I think you just gave me a perfect segue to talk about the paper you recently published, “IT Quality in Crisis?” What’s that all about?

Ally: I don’t think of myself as an alarmist. I’ve learnt the hard way that bad things happen and getting worked up about them or panicking does little to change that. It uses up vital energies that are best utilized on finding solutions to the problems. But I am concerned that there is a crisis emerging in IT Quality of major proportions and it’s a crisis that will have an impact on everyone who works in IT and who has to rely on IT to run their business. It is a global crisis, its effects are already being seen, and have been for some years.

I believe that there are three underlying problems that are contributing to the crisis in IT Quality and the decline of the role of the quality team in IT businesses. These include: the perception by management and staff regarding the role and value of the quality team within the organization; the apparent lack of ambition of quality people to rise up the management chain in such a way that they can genuinely make things better; and the IT industry’s habit of using real world terminology and downgrading it through constant misuse or reinvention.

My biggest concern is that quality in many organizations is still about ticking boxes and managing quality after the fact. Prevention is better than cure, but continued obsession with compliance is wasteful and de-motivating to project staff and quality folk as well. My issue is that far too many quality people are prepared to live with this status quo and too scared to push back. That really has to change! There’s plenty more on this subject and others on my website

http://www.allygill.co.uk/


of 109

Bill: Ally, I think you’ve brought up some sobering topics that are unfortunately all too true in my experience. However, admitting that there’s really a problem and correctly identifying the problem is the first step. I think you’ve done an excellent job of communicating both. Thank you for talking with me today and sharing your experience and expertise.

Ally Gill – [email protected]

Ally is an independent Software Process Management consultant with over 25 years’ experience in Software Engineering, Project Management and Process Improvement and Management. He held permanent internal and external consultancy positions at EDS, Q-Labs, DNV and Experian before becoming a freelancer.

Ally is involved with many different aspects of process improvement, quality and change management. His specialist areas include Organizational Change Management, Project Management, Metrics and Quality Management. He is a qualified ISO 9000 Auditor and experienced CMM/CMMI Assessment Team member. He also has experience with Six Sigma, ITIL, SPICE and Auto-SPICE, as well as Lean and Agile Thinking and techniques. Ally has presented papers on Process Management and Improvement at various conferences including ASQ ICQS, SEPG Europe and UK Software Metrics Association. He maintains his SPM Blog and will willingly talk SPM to anyone who wants to listen, or even those who don’t but who happen to follow him on @allygill on Twitter.

ALLYGILL.CO.UK was formally launched in September 2008, with a mission to educate the world that software process improvement is not enough; for sustainable commitment and robust return on investment companies need to embrace and integrate a software process management capability into their operations.


http://allygillcouk.blogspot.com/

http://www.allygill.co.uk/


of 109

Alan Shalloway

Understand What Your Challenge Is and Where You Want to Go

Bill: On the phone with me today is Alan Shalloway. Alan is founder and CEO of Net Objectives. His company helps organizations transition to Lean and Agile methods enterprise-wide. In the past year, I’ve attended several webinars held by his company and started following him on Twitter where I have found them to be thought leaders across numerous Lean and Agile disciplines. Alan was recommended to me by another interviewee, so I’m excited and fortunate to have the opportunity to talk with him today. So with that introduction Alan, I’m looking forward to getting started: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Alan: I’d say the key thing is to really understand the client’s problem. What we see a lot of in the industry now is taking some great methods such as Scrum, which is a phenomenal team process, and applying it without necessarily looking at the organization’s true challenge, which could be the team; therefore it’s very appropriate to use it. Or it could be other things. It could be management. If it’s a large organization, how are you going to transition the organization? Or maybe it’s a business direction point of view; maybe the business stakeholders aren’t identifying the most important items that can be built, the things that have the greatest value to the customers and the business.

It could be the team doesn’t understand the process; that would be a good one for Scrum or Kanban would also be very useful. Or it could be the relationship between the stakeholders and the team is problematic, in which case something more like Kanban and Lean would be useful. And then, it could be the team doesn’t really know how to code. At the end of the day, you’ve got to write high-quality code, so you might only go in and see how to remove technical debt or stop increasing it. In that case, design patterns and test-driven development might be useful.

In a sense, I’m answering your question, but the thing is to have your heads up and not come in with a solution, but come up with questions about what is the best approach. How do you best transition an organization? How do you do change management, how do people react to change, what’s the culture of the organization? Things like that have to be considered, so that’s our approach. We come in wanting to understand the customer. We want to understand who we’re helping since that’s our business – helping organizations transition through better understanding. And that’s the first order of business, to understand what your challenge is and where you want to go.


of 109

Bill: That’s interesting Alan because in preparation for this call I read one of your articles on your web site titled, Where to Begin Your Transition to Lean and Agile. I liked it because it nicely addressed the challenge of transitioning the whole organization. But it seems so often these efforts start out in development and the other parts aren’t considered. I’m wondering how you deal with challenge of beginning with development when you may not have the opportunity to uncover the fundamental challenge to the organization? Do you have any recommendations how to address this challenge? Does it have to start at the top?

Alan: That’s a good question. There are reasons at times that you can only start at the team level, and if that’s the only place you can start, then you’ve got to start there. And then your question would be: how do I create visibility for the management and the business stakeholders, so they can see that as the team starts developing and delivering value quickly, that this creates new opportunities for the business, stakeholders, and management. So, you can do a bottom-up approach, but it requires an organizational view. Even when you can work with Kanban and Scrum at the team level moving up, you have to have a higher context to do it.

I wouldn’t say most of our endeavors start at the top, but I would say relatively few do because those are usually very large engagements. We’ve probably done the largest Agile transition done with over 4,000 people in a financial organization, and we are engaged with another one even larger.

But if management and business stakeholders and the executive level are interested, then the real emphasis is to show how they will get business value delivered quickly. The real intention is not incrementally building code; the real intention is incrementally building value to the customer and towards the business. You have to ask that question and you have to talk the language of the business to get the business interested. All too often, people think of Agile as a method of building instead of delivering quickly, of adding value quickly, and in steering the organization.

The other thing is to view software development or business development as like a pipeline that just comes in. You decide what you want done, you figure out how to import it into the organization, and then you build it. If you can get that kind of view, you can also get people involved. Now, I think the reason a lot of times things happen at the team level is because it’s a lot easier. If you’ve got a team that wants to go Agile and they’re all set to go, starting Scrum is trivial, really.

The problem is if the structure of the team doesn’t really fit. In other words, if you’ve got people who are going to stretch across several different responsibilities, then Scrum models can put a lot of strain on the organization, which is one way to improve the organization. They have to remove the impediments and things of that nature, but if the management and the business stakeholders don’t see the need for it, it’s somewhat of a challenge.

But this structure, at an enterprise level, is actually not necessarily good structure. You have to have buy-in at some point that says we need an approach that is designed for an organization, and the simple model of just having every team be self-sufficient is not always working. Now, all


of 109

teams should always be self-organized. In Kanban and Scrum, those are both fundamental practices (or principles) that teams are self-organizing.

The power that Kanban has over Scrum is that it doesn’t require a fully cross-functional team. Now, it’s a good thing, if you’re using Kanban, you get the cross-functional and the self-organizing team, but it doesn’t require it. So, at an enterprise level, Kanban has a lot more power because it allows for different kinds of team structures that make sense at an enterprise level or you can have architecture over certain people with key knowledge, for example, domain or legacy code. Not just the skill sets, you can actually coordinate multiple people better with the Lean model than the Kanban model.

Bill: I noticed in the article I referenced earlier that you emphasize delivering value and measuring cycle time. If you start at the team level, my sense is that measuring and getting the message out become very important. Is measuring cycle time the one key measure that you would recommend focusing on, or are there others?

Alan: I would look at a few, but cycle time is key. That’s not so just for the team, because things languish before they ever hit the team. I remember an organization we worked with years ago, they brought us in to help them do Scrum and I casually asked them how long their products were at the team level and they were about six months, which is a little long. But then I asked how long is it before it hits the team and he said about two years. So, you had a team focus on six months out of two and a half years, which is 20% of the problem. It’s really how quickly can you get idea come in and then go out. You really look not for team agility, but enterprise, the business agility, which is how fast can an idea come in and go out.

The reason cycle time is so important even though it’s not something you necessarily push on, but the reason cycle time is so important is that it is highly correlated to a lot of factors that make a huge difference in the organization. For example, there’s a phenomenon I’ve talked about—actually, I have a YouTube on it; if you go to our website www.netobjectives.com\resources, and look for a Lightning Webinar, as we call them. There’s one on the tenets of Lean—how delays cause waste, and it’s this notion that with a little reflection anybody who’s been in software development can see. That if you have a two-week job and you spread it out to six weeks because you’re also working on other things, people attribute this to multi-tasking being the problem, but what really is happening is by spreading a two-week job out to six weeks, you’re literally creating additional work because the longer it takes to get to it, the more you forget. That’s not so much multi-tasking. You might work on one thing each day, but the age of the information degrades in your head. Or if it’s a two-month versus a six-month project, it’s even worse because the requirements age and change.

This notion of speed is a misnomer. People think it’s about going fast. Actually, it’s not about going fast. It is about removing delays, so you can deliver quickly. If you can focus and concentrate on getting something done and get it out the door, what happens is much of the work that we normally face in the development cycle literally is never created.

http://www.netobjectives.com/resources/lightning-webinars


of 109

Another thing we talk about in Lean is what can you do to stop the waste from being created in the first place. I think avoiding waste is perhaps a more powerful principle than eliminating waste. I mean, maybe they’re the same, and maybe it is just semantics – but I like couching things in terms of getting you thinking along the right lines. Avoiding waste means I’m not going to create it. Eliminating waste sounds like creating it and then I’ve got to eliminate it. I don’t know. It’s a small point, but it’s the idea of focusing on how we stop extra work from ever taking place, not how do we eliminate the extra work we’ve created.

The thing in Kanban is you focus on cycle time. One of the ways a cycle time gets stretched out is when you work on too many different things at once. So by eliminating how much work you have in progress, limiting it to the capacity, the right level of work, you shorten the cycle time, and by shortening the cycle time you lower the actual amount of work to be done, quality goes up, and timeliness is improved.

Bill: Alan, a week or two ago I happened to notice one of your tweet’s that spoke to the recurring cycle you’ve observed of new methodologies coming and going. I’ve certainly observed that too and it’s part of my motivation for creating this interview series. Would you be willing to comment on this further?

Alan: Yes, I would, and I’ll try to keep this short and succinct. I’ve been in this industry for 41+ years now, and I’ve seen this pattern of new processes coming, plateauing, and then getting stuck. We’ve seen it with virtually everything. We saw it with waterfall a lot. Recently, we’re seeing it with Scrum and I think we’re about to see it with Kanban too. And I’m a proponent of Kanban.

And the reason, I think, we’re seeing this is people tend to start getting good ideas and using them, but then falling down to practices without thinking. I think the key thing here – whatever you do, is really always inquire if it’s the right thing to be doing. Always look at your own experience, your own past experience, whether something you’re about to embark, what would have happened. In other words, run a thought backward-looking experiment, in a sense.

And don’t really trust what people tell you; you trust your own instincts. I think people have really good instincts if they use what experts are saying to think about… to decide on their own, but then use their own experience to see how it would work. You have to be open and skeptical all at the same time. And I really believe that most people out there know almost all they need to know; they just sometimes have it couched and framed in the wrong way.

And we have to keep thinking. We can’t say there’s a set of practices now we can follow, but there are principles we can follow that will always guide us. Principles meaning there are a set of rules that seem to work, like a Golden Rule is something that works in all situations, and this notion of “delays cause waste” is an example. That always happens, pretty much, when it’s a delay from start to completion. So, that’s basically what I would say: Trust yourself and experiment, and get ideas from others.


of 109

Bill: Yeah, I think those are really great thoughts, Allan. In fact, ever since you mentioned in your Tweet it’s been sticking in my mind because it really makes you stop and think, “Where is this all going? How do we corral it and marshal it to use all this most effectively?”

Alan: I’m definitely an optimist, but I think we can break it. I think once you recognize a pattern of behavior, it’s possible to break it. We all acknowledge it, and a lot of people are just like, “Oh, it’s happened. It’s going to happen again.” I think I do understand it, but I don’t have time to go into it now. But I will be writing a blog entry on it. I think I understand the human nature that has us have these patterns, and it’s something I’m working on a little bit with one of my other guys. I think it’s going to be a new stand and here’s what’s possible to break the cycle, so we can start moving forward.

You know, you don’t see this in physics. You don’t see them going up in waves, but why do we see this in software? It’ll be interesting if you had more momentum, but I don’t want to put it out there until I actually have it well thought through. I’m close, but I’m not all the way there yet.

Bill: This sounds very interesting Alan. I will be watching closely for this blog post. I’ll include a link in this interview so others with interest can pick it up too.

Alan Shalloway – [email protected]

Alan Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas. Alan has developed training and coaching methods for Lean-Agile that have helped Net

Objectives' clients achieve long-term, sustainable productivity gains. He is a popular speaker at prestigious conferences worldwide. He is the primary author of Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Pocket Guide for Scrum Teams, Lean-Agile Software Development: Achieving Enterprise Agility and is currently writing Essential Skills for the Agile Developer. Alan has worked in literally dozens of industries over his career. He is a co-founder and board member for the Lean Software and Systems Consortium. He has a Masters in Computer Science from M.I.T. as well as a Masters in Mathematics from Emory University. You can follow Alan on twitter @alshalloway


http://www.netobjectives.com/resources/books/design-patterns-explained

http://www.netobjectives.com/resources/books/design-patterns-explained

http://www.netobjectives.com/resources/books/lean-agile-pocket-guide-scrum-teams

http://www.netobjectives.com/resources/books/lean-agile-software-development

http://www.netobjectives.com/resources/books/lean-agile-software-development

http://www.netobjectives.com/resources/books/essential-skills-agile-developers

http://www.netobjectives.com/resources/books/essential-skills-agile-developers

http://www.leanssc.org/


of 109

Tom Cagley

How to Accelerate Process Change with Lean Feedback Techniques

Bill: Today I’m talking with Tom Cagley. Tom is Vice President of Process and Measurement at the David Consulting Group and leads several key practices there. Tom and I first met up on Twitter when I discovered his profile and identified him as someone influential in process improvement. Tom is the publisher of a very popular podcast called Software Process and Measurement Cast where he makes available a wealth of interviews and essays with experts on process improvement and measurement. Tom, I really appreciate you making time in your schedule to speak with me this late Friday afternoon, so if you’re ready I’d like to begin by asking you: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Tom: So this one is actually something that has been sort of a slow realization in terms of how we approach process improvement. Basically, I think we all think that people don't like change and they don't like to change often. I'd like to suggest that my experience is that people are okay with change, and actually if you go and do the research in psychology, I think that they do actually embrace change, but they just don't embrace change that they think is going to be bad for them.

Otherwise, your kids would still be living with you, you would've never gone to college, all those things that you do because you think it's going to be a benefit. So finding a mechanism to convince people and build trust is, I think, makes this work faster. So what we've done as we've worked with our clients really is to use very small changes.

And with relatively short feedback loops, we’re taking a page out of what's been developing in the agile world. So they tend to be small changes, processes that have an enforced sort of constraint that says if it doesn't all fit on one page, it's got to be something else. But very frankly, it forces people to be concise and do things in small chunks, so that you can get a much shorter feedback loop.

There’s an additional benefit to keeping the feedback loop short, is that will allow you to not get far off track. I think we've all been part of big process changes that grind away for a long time before they spit out something like a brand new project management process. And if that's been on the road for months, and you're not getting feedback, people build up this anticipation that it can't be good for me. And because they build up that anticipation, they tend to be resistant to change.

What we find is that by being responsive to change, such as using demos and pilots to get feedback before you roll it out; feedback you can react too early. People see that the change will

http://www.spamcast.libsyn.com/

http://www.spamcast.libsyn.com/


of 109

have value, small enough that they can test it, get a good feeling of it, and you also build up that trust kind of scenario that they know that you're not out to radically re-change their world.

Even though you might be radically changing their world, you're doing it in small enough chunks where they don't build up a lot of animosity toward the change. So small pieces, gain trust, and then use that whole process to get people involved. A very smart person once told me about collaboration. I think this whole involvement piece is part and parcel of how one builds the trust scenario.

So that in a nutshell is the nugget that we've basically fallen over as we've worked in process improvement, especially in the development side where we help people with agile too.

Bill: That's an interesting idea. Even though you chunk it down to small pieces, do you still need to show what’s in it for them? What if it's not a benefit to them directly, but it is a benefit to the company?

Tom: I think very rarely—and maybe it's my marketing background—I think it's very rare that you can't find or you can't package a change where it doesn't have value to the people that are participating in gathering the data or interacting with it, that it's only that the organization gets value. But where that does happen, obviously there's that direct need to have what you're doing in terms of change to be linked back into the organization's value stream, to the goals of the organization.

And I know that sounds sort of like a truism, but it's easy to forget that as you're plowing around in the middle of a CMMI implementation, and forget that in reality the whole goal of doing this is to, in essence, increase the value proposition to the ultimate client and to the organization. So having it tied to the goal I think is important, but I think I challenge other process improvement folks to really think hard and long about finding that link back to the individual project, or whomever you're interacting with.

Bill: One thing I've encountered is that some people have seen process improvement three, four, or maybe even more times in their career. It seems you get to a point where no matter what you bring to them, they've seen it before, and they’ve seen it come and go away and not work. Does this strategy or approach help work with that type of situation?

Tom: Yes, I think so. And I think you're absolutely right. There has been a lot of change that people have had to deal with, whether it's embracing ISO, CMMI, or object orientation—the number of things and different strategies and tactics that have been floating around almost come to the flavor of the month club.

I think taking those small chunks and doing it in a manner that they can see value, and react to it—so instead of making it something very huge, which again allows them to build up that push back, by doing something relatively small, getting them involved in the demo, showing it to them, co-opting them into the process, I think you do end up with a scenario where you can help break through some of that, "Well, we've done it before; it didn't work. We did the variant over there and it didn't work. Why is this going to work now?"

The answer is, "Let's do a little bit of it, and if it doesn't work, we'll try a different view of it. But we won't have to sink the entire budget of the project; we won't have to sink and make


of 109

fundamental changes to how you do your work again and again, just to find out that it doesn't work. We'll take it in small pieces, so that you can build up an understanding that there is value to the change, and then ask them in."

Bill: I like that approach. When you use this approach, how much does showing the big picture factor into this?

Tom: Here's the classic consultant word: It depends. I think in some organizations that it's very important to show the big picture and it has to be tied together. In some organizations, the journey is the big picture to them. So being able to help them see that they're on a journey is the entire big picture they want to see.

They don't necessarily need to see the ultimate end, as long as it's building to value. So I think for some organizations you have to link it. And obviously you always have to have it linked to the ultimate goals, but you don't have to always rub that in their faces in terms of making that the central message of every readout kind of scenario.

You can take it as, “We've gotten to this point along our journey,” and celebrate that, versus, "Well, we're only halfway to our ultimate goal."

Bill: What kind of response do you get from people when you use this approach? What do they think about it? How do they compare it with other things that they've participated in in the past?

Tom: That's a fantastic question, Bill. The answer is sort of mixed. You build in the whole process of building up, "Here are the list of things that we think we need to tackle," and then let their internal folks get involved in picking. And because you can only take little bits at a time, it sometimes builds up a little bit, "Why can't we get to my top priority first, versus other pieces that have been prioritized first?"

But using the whole agile technique of re-prioritization, I think you allow them to continue to come back to the table and bring their priorities forward. So in terms of the people involved in the change, it really resonates with them, and we get very good customer satisfaction views from that.

Where an organization has trouble prioritizing and saying, "This will have more value to us than this other," and they want to do a more shotgun approach, this approach tends to be not something I would try. So there's a degree of angst that builds up in those circumstances. But in general, we get success when we go down that route at a much higher rate than when we attempt the old school big bang approach.

Bill: Tom, you’ve shared some terrific insights with us. Thank you for taking time to talk with me today. I’m looking forward to working my way through your impressive library of podcasts.

Tom Cagley – [email protected] Tom Cagley leads the Software Process Improvement and IT Performance Improvement and Software Measurement Consulting Practices at the David


http://www.davidconsultinggroup.com/process/

http://www.davidconsultinggroup.com/performance/

http://www.davidconsultinggroup.com/performance/

http://www.davidconsultinggroup.com/measurement/


of 109

Consulting Group. Mr. Cagley is an authority in guiding organizations through the process of integrating software measurement with model-based assessments to yield effective and efficient process improvement programs. Mr. Cagley is a recognized industry expert in the measurement and estimation of software projects. His areas of expertise encompass management experience in methods and metrics, quality integration, quality assurance and the application of the Software Engineering Institute’s Capability Maturity Model® Integration (CMMI) to achieve process improvements.

His consulting engagements have included clients in software and hardware manufacturing, retail, health services, public utilities, telecommunications, manufacturing, insurance, financial services and government agencies. He is a frequent speaker at metrics, quality and project management conferences.

Mr. Cagley has over 20 years experience in the software industry in which he has been a consultant since 1997. He was previously Metrics Practice Manager at Software Productivity Research. Earlier, he held technical and managerial positions in different industries as a leader in software methods and metrics, quality assurance and systems analysis. Mr. Cagley is a frequent speaker at metrics, quality and project management conferences. His areas of expertise encompass management experience in methods and metrics, quality integration, quality assurance and the application of the Software Engineering Institute’s Capability Maturity Model® Integration (CMMI) to achieve process improvements.

Mr. Cagley is a member of the International Function Point Users Group and is a Certified Function Point Specialist. Mr. Cagley is currently on the IFPUG Board of Directors as the Vice President. He previously served as the Chair of the IFPUG Conference Committee and Director of Conferences and Education.

Mr. Cagley earned his BS from Louisiana State University and has done extensive postgraduate work at Cleveland State University, Case Western Reserve University and Kent State University


of 109

George Dinwiddie

Measure Progress in a Way that’s Visible and Reliable

Bill: On the phone with me today is George Dinwiddie. George is a software development consultant who helps organizations tune-up or completely overhaul their software development processes. He works at the organizational level to define and implement broad strategies, at the project management level to add visibility and reliability to delivery of the system, and at the development and testing level to improve quality and reliability of the system. So with that introduction George, I’m looking forward to getting started: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

George: The thing that I find most important is that you’re measuring your progress in a way that’s visible and reliable. Visible in terms that you can see at any point whether or not you’re making progress, and reliable in that you’re measuring what you really want rather than some surrogate measure that may or may not really correspond to that. I’ve seen far too often where people are tracking their progress on some estimation of that progress, or by how much effort has been extended rather than what they’ve accomplished.

Bill: How important is it to do this from the very beginning?

George: Well, I think it helps to do it from the start. You can certainly start doing it at any time though and get an idea of where you are and how you’re going. I think it’s important to do it both in terms of whatever practices you’re trying to put into play and also the adoption of it. It works on both levels there.

Bill: I think this is a really good, important strategy tactic to use. One thing that comes to mind to me is … I’ve seen a lot of organizations struggle with defining what to measure. They have difficulty focusing in on exactly what they want to measure and doing it in a way that is reliable like you say. Do you have any advice along that line of things that you may want to pick to start?

George: My preference is to measure functioning software. I’m typically working with software projects, and so, from that point of view, pieces of functionality are fairly distinct as to whether or not they’re working. You decide what they’re intended to do and then you can test whether or not they do that. The better you define what that functionality is, the more reliable that is. Slices of functionality that are really visible from outside the system are much more reliable as indicators than working on a component or architectural basis. When you’re working on individual components, too often they don’t really match up with the next component, and so there are unseen gaps or overlaps that give you a false impression of how far along you are.

Bill: Can you give me an example of something like that, George? Where you’ve seen that done or have done that?

George: For example, in many situations, people try to go through and say they’ll do the database schema and then build some logic on top of that, and they’ll display and try and be


of 109

complete on each of these at each step. Whereas, instead, you can kind of do all these in concert to create some functionality, and perhaps you start with a simple version of a screen and do enough of the business logic, the middle layer to implement that, and enough of the database schema to support that. You can tell that it works and then you can go on and add new functionality on top of that, standing that functionality or adding new features and build out that way. You can check this functionality, I don’t know of any way checking just a database schema to make sure it’s correct. Or just the middle tier, or even just the screen when it’s not connected up to any functionality.

Bill: So you’re saying componentize the functionality for measurement purposes. Maybe the complete picture that you’re going to develop, but you’re marking off each piece of as it gets developed?

George: Yes, from the perspective of functionality rather than architectural layers. It’s basically slicing in a different direction than people normally do. Any given piece of functionality may depend more heavily on different components or different layers of the system, but it tends to cross multiple layers in the architecture and makes it a completing working piece, rather than just something that is envisioned to be necessary for the final product.

Bill: Now this is interesting, George, because you’re taking this in a little different direction than I expected. I’ve never heard of going in this sort of direction. It’s usually more of a business oriented measure in terms of cycle time or a financial or numeric measure. I think this is interesting because I think it gives people who struggle with measures another way to look at things that they can probably not come up with more quickly. Do you have any comments on comparing those two different types of measures?

George: Well, cycle time is another good measure, and I think it gives you a lot of information on how well you’re able to complete stuff. By looking at how much you’ve completed, in addition to that, gives a more complete picture.

Let’s you look at it this way: Say you want to create a whole new system. If you look at the cycle time for when this decision is envisioned to when you put it in production, then that can be a couple of years. If you break that system down into smaller pieces of functionality and look at the cycle time for each or those smaller pieces, it’s going to be much smaller. You can implement these and then go on and add others.

So, cycle time is a good measure of reaction and efficiency. But in terms of building, creating the system itself, if you can measure it in completed functionality in small steps, then you can see the rate in which it’s being built before you get through the end of the entire system. And you can measure cycle time on each of these smaller pieces.

This gives you a lot more visibility into your progress. So I would say cycle time is sort of a number two measure I would want to do. But measuring the progress on something that really represents what you’re trying to achieve, (which in my mind, tends to be functionality, but it could be something else in certain circumstances) is a really important predecessor to that.

Bill: When you measure functionality, do you put it in terms of almost an earned value type of metric or it’s more a checklist of functionality?


of 109

George: To me, I’ve kind of gotten down to more of a checklist of functionality. My problem with earned value metrics is that they often value the functionality based on the amount of what it costs to produce. It’s an easier thing to measure than the value that it really brings, and so, most people who are doing earned value take the simple value assumption that the cost and the value are roughly equivalent. And I’m not sure that I trust that simple value assumption in a lot of cases.

Bill: Another thing you mentioned, George, was about making progress visible. What are some good ways you’ve seen this done?

George: One of the simplest mechanisms I’ve used is the burn-up chart. With a burn-up chart, you’re measuring two things over time: One is your completion. If you’re measuring functionality, it’s what functionality is completed. The other is how much there is total, because that changes over time also. As you go, you discover there are new amounts of work that we need to do or you may change your mind. And this allows you to adjust scope to cut deadlines too. You may decide we’d really like to have this really fancy system. Now we realize that we can start with a simpler one, leave out some of these extra features or just provide simplified versions of them, and be able to get a system out sooner that will meet some of our needs and maybe start producing revenue or producing savings, depending on the type of system. And that will realize some value earlier.

Bill: Any final thoughts or closing statement you’d like to make about this approach?

George: I would be interested in hearing from people about other measures that they find to be the right thing, a reliable measure of things that they value in their project other than functionality. I may be stuck on the idea of functionality, which I think is very important, but there may be other things that are just as important to people in certain circumstances.

George Dinwiddie – [email protected]

George Dinwiddie helps organizations develop software and systems more effectively, bringing thirty years of development experience ranging from electronic hardware and embedded firmware to business information technology. He helps organizations, managers, and teams solve the problems they face by

providing coaching, mentoring and training. Capable across the broad range from process improvements to engineering skills, George currently has special interest in team-building, collaboration between business and technical, acceptance test driven development, developer and tester skill-building, and Agile process transformation. He has helped numerous clients, large and small, in the U.S. and overseas, and has presented at conferences such as the Agile conference, Agile Development Practices, and numerous regional or specialized conferences. Find George’s blog at http://blog.gdinwiddie.com, his company, iDIA Computing, LLC, at http://idiacomputing.com, or email him at [email protected].


http://blog.gdinwiddie.com/

http://idiacomputing.com/



of 109

Bob Schatz

A Powerful Tool for Improving Quality: Definition of Done with Standards

Bill: Today I’m speaking with Bob Schatz. Bob has nearly 30 years of experience in software/systems development and leadership. He is a Certified Scrum Trainer, Experienced Agile Executive, and the Owner of Agile Infusion. I met Bob in 2010 when I attended his Certified Scrum Master Training that was held in Northern Virginia. What impressed me about Bob was that he was an Executive at a very successful software company and was responsible for leading the organization to a very successful transition to Scrum starting in 2002, the early age of agile adoption. Bob is someone who has done it successfully many times and has keen and experienced insights on how to be successful. Bob, with that background, I’m looking forward to hearing how you answer the question: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Bob: OK, thanks, Bill. One of the things that I’ve found really helpful in getting organizations to begin creating a better work environment and getting a better quality product out is the “definition of done.” And it’s something that’s evolved over the years, because originally, we were trying to put in place a general understanding of what “done” means to everybody, so that there would be a common set of practices or set of steps that people would go through. And I think over time, it’s evolved. I know it certainly has in my practice of dealing with a lot of clients that are trying to adopt these techniques.

And I try to look at it somewhat pragmatically to help them get better. I evolved that definition of done to be more robust based on the my experiences and the available research in Lean and Six Sigma practices over the last decade or two in other industries. One of the things that becomes really important, that is typically missing in a lot of software development environments, is a work quality standard. This was the purpose of the definition of done, attempting to establish a standard set of steps that people will go through in order to complete a piece of work. Not to imply a sequence like a waterfall, but to make sure everyone had a common view of the current best practices.

There are a couple different levels in a definition of done. First, we look at the compliance level, which is identifying any steps and artifacts necessary for an organization to meet a compliance standard if they were in some type of regulated industry, using a DOD Mil-standard or an FDA standard, like 21 CFR Part 11, or they’re ISO or CMMI, any of those things where people tend to see them in conflict with what we do in Agile is actually not in conflict. They’re just steps. And once an organization agrees that they need to do those steps, for whatever purpose that is, that becomes part of the work standard. But those things don’t always tell you the quality level to meet. That is left to the sponsor and developer of a system.

http://www.box.net/shared/erszagsh3c


of 109

Next, we capture the best practices in the organization. The compliance level tells you what you need to do, and the best practices tell you how the organization does that. Examples of this would be code reviews, tools employed, and internal process steps. The combination of the two gives a comprehensive list of the steps to create an increment of a product. And the critical piece I’ve added to that is a quality check for each step.

The idea came to me from two sources. One was when I read the book Checklist Manifesto by Atul Gawande, the other was my experience as a student pilot and the intense focus on the checklist as a key quality/safety tool. The aviator’s checklist has each step and the correct condition to look for. It’s kept simple because there are so many other activities going on, like flying the plane. On project startups, I have the organization do a 2-hr exercise where they create a checklist based on process compliance and best practices steps. This provides an easy tool for a team to see what they need to do. I try to keep it simple, a single-page checklist that encompasses all the steps and the quality condition to meet.

When working on features, the team uses the checklist as a guide to complete a piece of work. Before they check one of the boxes and say, “we did that”, they need to ensure the quality standard is met. For example, one the steps might be to run an automated acceptance test. Without the quality check we could run the test, identify/document 20 defects, and claim victory. With a quality standard that says tests have to pass 100% and ALL defects are fixed/verified, the team can only check the box when that condition is met. That’s a game-changer for most organizations. The challenge of course is to set your initial quality levels and then begin the hard work of raising the bar.

Having the ability to know before you check a box off that you’ve actually done those steps and that it’s met a quality standard is important. It puts professionalism into our work. We’ve learned this from companies like Toyota, Honda, Kia, Hyundai, and even Ford in the automotive industry as well as other industries that do very well at Lean/Six Sigma-type production and development systems. A key lesson-learned is not to send errors “down the line”. Find and fix problems at the earliest possible time when they are least expensive. This way of thinking applies regardless of the process used; Scrum, XP, Kanban, even the waterfall. In order to do that, we want to make sure we have that quality standard in place.

Different organizations are trying to figure out what level of quality they can currently achieve and what their customers expect. Obviously, one change I’d love to see is for teams to set their goals for zero defects. Usually the first reaction is that this is impossible. This “can’t” thinking becomes the biggest barrier to moving forward; the belief that it can’t be done. But just as Toyota is in a constant pursuit of perfection, so should we all. That would steer us to creating the highest quality product. As organizations are learning little by little how to do that, some will have certain levels of defects that they will continue to pass down until they start building the disciplines to find and fix them earlier and ultimately put in measures to prevent them from being injected into the product development process.

As process improvements are identified and put in place after each iteration, some will go into that definition of done. This raises the bar on the quality making sure that they can get better and better with each iteration. This has fostered a shared view and responsibility for quality of the product throughout the process.


of 109

I usually combine this enhanced definition of done technique with other parts of the project setup. Making sure everybody understands what the vision or the purpose of the project is and what the set of outcome goals are provides clarity for better decision-making. This is something a lot of organizations have not been doing consistently.

I know a lot of companies will set goals in terms of features and functions they want to put into a product, but that doesn’t really tell you the outcome goals. Outcome goals are what you hope to achieve by putting that product or service out in the market. These goals are measurable, time-based success criteria. For example, we want to be a 4-star or better, top 25 downloads, in the Apple App Store, 3 months after release.

Decision-makers in companies may start a high-cost project without establishing clear outcome goals. When you ask them what the outcome goals are, or what they hope to get out of this in terms of either revenue or benefit, the response can often be a puzzled look, “Oh, we never really thought of that, we just knew we had to do it”. But you really need to have a good reason to start a project and a measurement system that provides feedback on whether that was the right decision or not.

I lead them through the process of creating prioritized outcome goals, which helps guide the creation of a prioritized backlog of features we need to complete. Next is a discussion of the constraints of the project, which have to do with your scope, cost, and time parameters. If you look at the constraints as the currencies of change, then you have the mechanism to make trade-off decisions and steer the project effectively.

Sometimes one or two of the constraints might be fixed. For example, say there is a fixed-date project, and we have a set number of people on the team. In this case, scope becomes the spendable currency. If decision-makers don’t do this and they create a scenario where scope, cost, and time are fixed, it forces a tradeoff in quality which we really don’t want because it drastically increases cost in both short- and long-term. If companies want to increase speed, with increased quality, they must understand how to steer a moving project with the constraints. The idea that quality suffers with speed is not real, it’s just a poor excuse.

So, all together we have 4 important starting points for a project:

• Vision/Purpose/Mission

• Prioritized, Measurable, Time-based Outcome Goals

• Understanding of the Driving Constraints

• Definition of Done with Steps and Quality Checks

This has proven to work well for organizations. It provides a simple process for actively managing a fast moving, high-change, project. I’ve heard a number of stories of people I’ve had as students and clients where releases are now going into production with less than 10 defects, which is a pretty good place to be when you’ve historically gone out with hundreds, or possibly thousands of defects that are known in the system, so that’s a really big improvement. That’s nice to see.


of 109

Bill: I think those are great results that speak for themselves Bob. I like the way you have tied this all together. I know from my own personal experience with the “definition of done”, that it’s a powerful tool, but adding the quality standard seems like it starts to set the expectations from the beginning. I think that builds in a higher level of performance from the start.

Bob: Yes, using the approach gets us in that prevention mode instead of waiting until late in the process and then trying to find the errors, which is very costly and very risky.

Bill: Exactly. I’m curious about your experience when they don’t meet the quality standard especially when they are first adopting these standards. How do they allow for flexibility or do they end up changing the standard?

Bob: When you move to put the definition of done in place, it forces a conversation. The initial quality standard should be at a level that can realistically be reached based on current practices. But as those process improvements start, the quality bar has to be raised. I personally and professionally strive for a continuously higher quality, because at the end of the day, that’s what customers really care about. As professionals we have to pay attention to both the “plumbing” and the “exterior” from a quality perspective.

There’s always going to be pressure to produce better, faster, and cheaper. What I want to put in place is the understanding and the financial proof that if we don’t meet a quality standard, we are going to pay a heavy price for that later.

I try to explain it to people like this - whenever you release a product without meeting a high quality standard, or as some describe it as leaving debt in there, you’re taking a mortgage out. When you take a mortgage out, you have to make payments. In subsequent projects or iterations, you are going to continue to pay a price for that previous project and it’s going to have interest associated with it. You’re going to have a price to pay in each iteration to continue to fix past problems because that’s the mortgage payment. The longer the debt remains, the more it costs.

When they’re budgeting out a team’s time for a sprint, part of it must be allocated to paying off the mortgage, which means you’re going to pay a price for those past quality issues in every sprint. Raising awareness of this dynamic, in these simple terms, helps expose the economics of quality issues to stakeholders, product owners, and the people that are actually trying to drive the value of a product.

Bill: I think that’s a really good way to look at this Bob and make it real. It’ll help people understand what the true cost is. When you lower the quality standards and let things slip through and make that trade off, the impact keeps coming back to haunt you.

Bob: I think it mirrors what we’ve seen in the economy. We had a decade of everybody buying things on credit without any kind of sense of what that would cost later on. Banks and lenders were focused on short-term gains knowing that everything could very well come crashing down, and 10 years later, it hits you like a brick in the face. We’re seeing it in the economy; we’re seeing it in the real estate market. This is the same behavior pattern we’re dealing with in the development of systems. Years of getting systems out too fast, trying to get things into the market quickly, which I’m not saying is a bad thing, but I don’t think anybody realized the price that would be paid later on.


of 109

I think when people start talking about technical debt; they use the language of debt. It really is the same situation. It’s just if you read the newspaper and then translate it to what we’re going through, you see the correlation and you see the same behavior patterns.

Bill: That’s right. That’s a really good observation. Bob, you’ve given us some great things to think about and presented them in a manner that I will hope get more people to pay attention to them. Any closing comment you’d like to make that summarizes how we might change these faulty behavior patterns?

Bob: The only thing I’d say is that I think every organization is trying to increase their agility as a matter of survival. They shouldn’t over-focus on the mechanics of something like Scrum, XP, or whatever process you use. Focus on getting back to the basics. Scrum and XP are great frameworks for exposing problems to solve, but you will always need to have standards in place and that’s a good place to start.

If you look at lean implementations in other industries over the past four decades, you can see very similar behavior or adoption patterns where companies tend to focus too much on mechanics and miss the underlying culture changes. The history of lean transitions in the past 3-4 decades provides a glimpse of our current issues.

I think that’s a good lesson to learn. We’re not blazing new trails; they’re only new for us. There’s a lot to learn from the past and I think the more people do that, the more they’ll see these things are not so difficult to implement. You just need a little courage, and a belief that it CAN be done.

Bob Schatz – [email protected]

Bob Schatz is a 29-year veteran in the field of enterprise software/systems and product development and leadership. He has held positions from Developer to C-level executive. As VP of Development, he led the widely publicized enterprise adoption of Scrum at Primavera Systems starting in 2002. Currently, Bob is the

Owner of Agile Infusion, a training/consulting practice that helps large enterprises successfully adopt lean/agile practices. Bob is a Certified Scrum Trainer, has a BS in Computer Science from Temple University and a MS in Organizational Dynamics from the University of Pennsylvania. Connect to Bob on LinkedIn at: Bob's Linkedin Profile. Click this link to download an example “definition of done” with quality standards.


http://www.agileinfusion.com/

http://www.linkedin.com/in/bobschatz

http://www.box.net/shared/erszagsh3c


of 109

Mike Kelly

How to be Successful with an Out-of-the-Box Agile Methodology

Bill: Today I’m speaking with Mike Kelly. Mike is a Partner at DeveloperTown. I met Mike at a conference this past September where I became aware of his work in agile software development and software testing. Based on our conversations on these and other topics, I knew Mike would have a valuable perspective to contribute to this report. Mike, I’m looking forward to hearing how you answer the question: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Mike: Most clients I work with are looking for help with their software development process. In most cases we start the engagement by looking at the way they plan, build, and release software – and we then get them started down a new path with an out-of-the-box methodology. The engagement becomes us working with them to iterate on that methodology over time. For the first few iterations it is “by-the-book”, and over time the process morphs and adapts to look and feel unique to that organization.

Most of my background has been doing this with Scrum. Through the retrospective process that happens at the end of every two-week sprint, we have built in checkpoints to make changes to the process along the way. Not knowing all the context or nuances of their organization up front is okay. Our approach is to prepare them for some of the issues they are going to hit as things start to unfold, and then get them engaged in addressing those issues real-time. Every two weeks we make these small changes and tweaks, working to get everyone on board, making sure everyone on the team has input and is able to help provide direction.

Bill: That’s an interesting approach, Mike. It’s a little different twist than I usually encounter. As I understand it, you come in with a prescriptive approach and then use a retrospective to fine-tune it.

Mike: That’s right. I used to come in and say, “Look, I'm just going to listen and learn and understand. I’ll be here for a couple of days or couple of weeks. Once I come up to speed on the culture and the team, then we can start making changes.” What I found was, a lot of that would just end up being a distraction for me. People are really good at hiding information - hiding why things are the way they are. Many times they may not necessarily understand why things are the way they are. A lot of times there are systemic problems that really affect process and affect a lot of the behaviors that become manifest in the team’s culture. Many times you can’t identify those issues quickly, or even over the course of a couple of weeks. It’s difficult to understand all the implications.


of 109

One of the things that this process rewards is that it’s typically a big change for the team. So all of the things that are going to conflict with the out-of-the-box process changes happen in the first couple of weeks, or maybe the first four weeks. If you're working in a two-week development cycle it’s difficult to bury issues for a long period of time. All of the culture and financial clashes are going to become visible relatively quickly.

So, it ends up still unearthing all of those things that more traditional long engagement models uncover. Only it’s much more focused on the process and not necessarily the people involved. No one ends up saying, “Hey, what’s this new guy doing here? What is this going to mean to me? Should I really share this information with this guy or shouldn't I?”

Bill: That’s interesting, Mike. I can see how that would be an advantage, and I'm wondering how that works out over time. Do you get to a much better, stronger place over a longer period of time?

Mike: We have so far. I’ve done this with a number of companies, and in each one, this typical scenario plays out when we come in. We talk them through the type of process that we're going to put in place: what it’s going to look like, what it’s going to feel like, some of the common struggles, and some of the good things that are going to manifest right away. We do a short training session around it, and then we just do it. We put it in place and we get started.

That will cause some pain for certain people within the organization, and it will also alleviate other pain points. One of the reasons why they’re calling us in a lot of times is because there’s some part of their existing process that’s broken. One of the things that I'm always relatively sure of is whatever process we end up putting in place to start with is going to address those known pain points head-on and directly. But if you’ve ever done this type of work, you know that through unintended consequences, you’re likely going to break something else that was working previously. That’s why it’s an adaptive process with tight feedback loops.

The process of just getting started - jumping in and getting things moving - does a couple of things: One, it brings a huge amount of engagement. It’s not something you can ignore. It’s not something that you trivialize. People jump in with both feet and they just start doing it. And there’s really no way not to, because we're not coming in and saying we're going to make incremental improvements. We're saying we're going to make a big change, and then we're going to incrementally improve that big change by tuning it to your organization.

What we typically see is in the first two weeks to a month; we get some of the big improvements we were looking for. But then, we also surface some of the more painful issues like overall velocity, how hard it is to release the software, and how teams are incentivized. Our process changes can often make the development team move faster, but what about everything else? A lot happens after development, whether it’s support, training, marketing, sales, or client communications – the rest of the organization can’t just turn on a dime and now suddenly move faster as well. Suddenly our efforts are moving beyond the development process and looking more at the organization – it’s a series of connected processes.


of 109

For me, it’s a series of concentric circles. Initially we are very focused on some of the initial pain points – that’s the first circle. Every sprint, we widen the circle just a little bit more to focus on some other aspect of the team or organization. We tune the process more and more as the circles get bigger and bigger.

Up front we say, “We're going to drop a big rock in your pond and it’s going to have a lot of ripple effects. With each one of those ripples, we're going to have to make a tweak or process change, and that’s going to take time.” We typically sell it with the idea that we're going to come in and make a big impact day one, but you're going to be fine-tuning these changes over a three to four-month period. It still takes time, just like any other process improvement.

Bill: Mike, can you tell me a little bit about the initial implementation? Are you doing it on a pilot basis? Will you apply it to a whole organization? What size groups can you do this with?

Mike: It’s a good question. We typically work with smaller product development companies or project teams. I've done it on both specific teams in an organization, as well as for entire companies. But from a scale perspective, those are all typically either teams that are under 10 people or companies that are under a hundred people, maybe 50 to 100 people. So they’re still all relatively small and they’re fairly agile. There’s just not a lot of overhead in a company of a hundred people - it probably wouldn’t be a good business if there were.

But we have seen a couple of examples where we've gone in and worked with a project team, that team hits its stride and has large successes, and then the rest of the company just kind of looks at them and says, “Wow, what are they doing? Should we be looking at that?” So we’ve seen it cascade (a bit) based on project team success. We've also seen the other side of that happen, where the project team ends up doing things so differently that the rest of the organization has to adapt to accommodate their increased output. In those cases, because so much of the company is affected by those changes, they need retool to keep up.

Bill: I have a question about the ripple effects, Mike. When using an approach that’s focused on a development group, are there supporting groups that are impacted? Are you informing them ahead of time or is that part of the process as you go along?

Mike: They’re involved from day one. But often at that point they still don’t fully grasp how different it’s going to be. It takes time for the real implicates of the change to be clear. It’s one thing on PowerPoint; it’s another when you actually have to change something you’ve been doing for the last two years.

Just recently with one client, I met with each of the developers one-on-one and told them, “There’s going to be a big change. The pace is going to change. The way you’re viewed within the company is going to change. The way the people respond to you is going to change. The amount of work you're going to get done in a two-week period is going to change.” A couple of the developers sat back and smiled. They didn’t believe it at all. And why should they, right? “We've heard this before. We've done other process improvement. We've been through this


of 109

song and dance. Yeah, yeah, yeah, whatever… You're the outsider. You don't know how things really are here. It’s not going to change.” And that was about three months ago.

Just last week, at that same organization, I asked one of those of developers, “So, what do you think?” At this point, we are a couple months into the change and the organization has posted a number of new job requisitions because they’ve uncovered gaps in the team and they were hiring up to accommodate the need. That team has completely changed the way they do software development. They previously worked on an eight-month release cycle. Now, they’re working on a one-month release cycle. People respond to the developers the same day they ask the question now, because now there is a shared sense of urgency throughout the company. The developer just smiled. He wouldn't even respond. He just nodded his head as if to say, “OK, I get it. You're saying, ‘I told you so.’” That’s rewarding.

Back to the question, on day one we bring everybody in who is very likely to be impacted and we talk about what this change means. Unfortunately, on day one almost everybody thinks, “Yeah, we've heard that before. It’s not going to be that big of a deal.” It’s not until the second or third sprint when the work starts to hit their queue at a pace that they’ve really not seen out of their development organization before that it becomes real to them. At that point there’s a shock of, “Oh, wow! We're really doing some of the things that they said we would!”

When that occurs, those people come back and ask, “OK, how do we deal with this again? What are we going to have to do differently?” A lot of times that’s when we start to really dive in to those groups and figure out what changes we can make to accommodate the new workflow coming out of development.

Bill: OK, that’s really a great success story. Mike, so often, these folks have seen things come and go and they fall on their face. They’re not really done correctly. So, it’s really good to hear stories like this. We've been going about 15 minutes. I know we have got plenty of content at this point, Mike. So, if you have any final closing statement or anything you'd like to make, this is probably a good time.

Mike: I think the only other thing I would say is, a big important part of the way that I work when I engage with the team is that upfront - in the very first stages - we identify who the process owners on the client side are going to be. It may be one person or it may be two or three people. I want to work with them to make sure that they’re the ones facilitating the changes that we make. When we first come in and we drop the big rock in the middle of the pond, that’s me, swinging a big stick and saying, “This is the way we're going to do it, and it’s going to be this out-of-the-box process.” I’m the bad guy if no one likes the changes.

Then on a sprint-to-sprint basis (or every two weeks) when we make process changes, it’s the process owners that are facilitating the changes that the organization is going to make to that out-of-the-box process to make it more effective. They’re the ones going in and soliciting the feedback and asking: “What’s working? What’s not working? What should we start doing? What should we stop doing? What should we do more of?” To the organization it feels like and looks like they (the organization) own the process now. They’re the ones making those changes. They


of 109

are shaping the direction. I really want them to own it and feeling like it’s theirs and it’s not something that just worked when it was dropped in by some outsider.

When they look back three or six months into the transformation, and they look at all the changes that have been made over time, I want them to talk about “our” process. I want them to own it and view it as something that they’ve grown over time.

Bill: This sounds like a very effective strategy to me, Mike. It’s a clever way to provide strong guidance when needed and show results quickly but at the same time let the organization take ownership where it needs to belong to make it successful going forward.

Mike Kelly – [email protected] Mike Kelly is a partner at DeveloperTown, a venture development firm. He regularly writes and speaks about topics in software testing, but spends most of his time working with teams to deliver ridiculously high quality solutions faster than they could without rigorous testing practices. Mike is a past director and president for the Association for Software Testing and a co-founder of the Indianapolis Workshops

on Software Testing, a series of ongoing meetings on topics in software testing.


http://www.developertown.com/

http://www.associationforsoftwaretesting.org/

http://indianapolisworkshops.com/

http://indianapolisworkshops.com/


of 109

Graham Oakes

Where to Start When You Don’t Know Where to Start

Bill: I’m talking on the phone today with Graham Oakes. Graham is Principal at Graham Oakes Ltd. in the United Kingdom. Graham is another in a series of recent interviewees that I was fortunate to meet up with at a conference this past September. I had the opportunity to hear him speak on a number of topics and know he has deep experience helping organizations with process improvement, so I’m excited to have the opportunity to talk with him today. Graham, I’ll get right to the question then if I may: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Graham: That's a good question. I've been thinking – I don't have a single view on it that says “do this or do that.” Where I fit into things is I help people typically at the early stage of a project or when they're looking at the overview of what they’re trying to achieve, and I help them think through what they're trying to do and how they're going to do it. I’m generally working in the fairly fuzzy stage, helping people construct some sort of mental framework that clarifies what’s going on in the situation. Almost by definition, there isn’t a single best practice or best thing to be doing, because if there was an obvious thing to be doing they wouldn’t be talking to me.

A framework that works really well for me is one that Dave Snowden helped create called Cynefin, which has got a lot of currency in the knowledge management community. Where I'm typically working is what it calls the complex domain, which is where you don't have a defined best practice. You don't have a set way of categorizing what's happening and saying, “Okay, it’s a type X situation; therefore I need to use strategy Y.” The tactics that work there are probe, sense, and respond.

What this means is you set up a series of experiments, typically lightweight interventions, to help see what's happening. Then as you monitor what's going on, you gradually build an understanding of the dynamics. Hence you can start to identify what's the right way to respond to this particular situation.

It’s like kaizen in the Lean world, where there is a strong culture of doing experiments, seeing what works or won't work, and being prepared to accept that you've got to try things, learn from those experiments, and then adapt what you're doing, rather than coming up with a grand process and strategy that can be brought in from the top down. For me the key in this step is to have a bag of tools I can use to set up small experiments to help people think through what they are trying to do and understand some of the context of what's going on.

http://en.wikipedia.org/wiki/Cynefin


of 109

I use thinking from a bunch of places – certainly from Project Management classic PMBOK type-thinking – a lot of thinking from the Agile and the Lean communities – and a lot of facilitation techniques. I have a variety of techniques that I might use for setting up workshops for groups of people to think around stuff. But the most powerful intervention in that early stage is often just to listen to people. It's surprising when you talk to people in organizations, how much of their organizational communication is about telling people what to do, and passing stuff down to them, rather than listening to what’s their actual experience on the ground. People can often work out for themselves what needs doing if they’re just given a chance to talk things through with someone else and reflect on the situation.

A good example, yesterday while talking to a sales director in an organization: his perception of how projects were set up and the reality on the ground of how projects are being set up were just two totally different things. A lot of organizations just don't have those feedback loops effectively set up to hear what's going on, and so part of what I'm doing is just listening to people, hearing what's going on, helping them pass that information to other parts of their organization, either up the chain or across the links in the organization, just so people can at least start to get a sense of what's going on. Building that awareness is itself a very powerful intervention in an organization.

From there, a lot of what I'll be doing is helping people to frame that awareness of what's going on, and get some sort of view of what are the forces acting, what are the principal dimensions. I often spend time trying to create a bespoke framework describing the type of customers they're dealing with or the type of products that they're building or the type of competition they're dealing with or the type processes that they're operating.

This looks at what comes out of their experience on the ground to help them organize it, and to identify the different types of things they're doing – then maybe helps them connect that to something that might be going on in the Lean community, that might be going on in various product development models or to connect that to some other external wisdom. And a lot of it's really about giving people confidence in their own internal wisdom and in their own understanding. I believe that in most organizations, there's somebody that knows what the problems are and how to solve them: organizations really just have a problem in finding that inner wisdom and executing on it. I'm really helping them connect to that.

Sometimes you need to help them look at the external frameworks. And there’s a lot of use for external frameworks. What you have to be able to do is say, “Well, what’s applicable to these people? Is it CMMI, or is it Scrum or is it Kanban? There are lots of models, but if you go in with one model, you’re force-fitting them onto the model, whereas really what you're looking for is much more illuminating perspective – helping them organize and understand what's going on.


of 109

Bill: What’s interesting to me Graham is that several people I've interviewed recently have talked about similar approaches. I've taken this type of approach on occasions, but this is the first time I’ve become aware that it has a formal name. Can you talk a little bit more about Cynefin?

Graham: It's a Welsh word and the person who originated the concept is Dave Snowden. It’s a collection of related techniques that are quite powerful facilitation techniques and things like that.

Bill: How would you contrast the Cynefin approach with an approach such as CMMI, or Scrum, etc.?

Graham: I can think of previous lives, if you like, where I’ve worked with big and midsize consultants, where you tend to have a standard approach. A lot of organizations like this standard approach. They want someone to come in and drive the process for them and somebody that tells them, “This is what's going to happen on week one, this is what's going to happen on week two, this is what's going to happen on week three,” and that gives them a lot of comfort. But by the time you get to week three, it's totally different to what you said it would be. So suddenly the discomfort hits you at some point down the line, whereas often, for me, the discomfort, it’s probably coming early on when I can’t give them a clear picture – this is what the solution’s going to be, and this is where we're going to get to – so we have to deal with that discomfort early on. The point is, in complex situations, you can’t avoid the discomfort. So you might as well try to start dealing with it from the outset.

Pragmatically, that means there are some potential clients it’s not going to work for, that I'm not going to be able offer the sort of comfort that they want. That's because I'm not avoiding it – I'm bringing out that discomfort. But like I say, the discomfort is probably going to come, if they're going to make any sort of step change. I'm just saying let’s face discomfort from the outset, or else, they're not actually looking to make a step change – they're really not prepared to engage with the discomfort. That's a clear sign that I'm probably not the right person to help them.

And it's interesting – the cross-section and the types of clients that are prepared to engage with that, and the type clients that don't want to have that discomfort. I hesitate to use the word maturity, but there’s a sense some organizations have not faced up to the reality or are not prepared to face reality. They're going to constantly be engaging with different changes to improve things, and there's a bit of a fantasy around some of the process improvement frameworks. There’s a lot of good stuff in CMMI and its five maturity levels, for example, but they also create this impression that it’s a mapped-out process, and you go from stage one to stage two to stage three, and this can be a comfortable, safe transition as you gradually get towards maturity.


of 109

But the reality of organizational change is that it's going to be chaotic and messy, and there’s going to be people that resist, and there's going to be people that have ideas of where you ought to get to, and how you're going to get there, and you're going to have to get some of that complexity and that chaos and that discomfort, and so I'm sort of setting that out from the outset.

Bill: I can see how some clients would be ready for that, and others aren't. I'm curious – do you ever find yourself in a situation where people are surprised by that approach – maybe not expecting it, and then they see the value and get excited about it?

Graham: So, yes. To go into that approach you've got to establish trust from the outset. Often on a project, I may find myself in the early stages doing things that are mostly about establishing trust between me and the client.

For example, I can think of a client where they were looking at their product development process. The first round of that engagement was really just demonstrating that I knew what a product development process looked like, and could give them a fairly accurate answer to their questions about it. Once they understood that I knew what I was talking about, then we could start to engage with some of the real complexities of how the process might actually work when they implemented it into their distributed teams around the world, and deal with all the issues of different team cultures and their different disciplines. That's a fairly common example of the type of account where I'll be working. I’d expect to be working with organizations that might have teams in the UK, the U.S., India and China. I work with teams that have software engineers, hardware engineers, designers, marketers trying at some level to come together as cross-functional teams, so there are a lot of cultural issues to deal with.

One of my challenges as a consultant is that I don't have an easy answer to “What do you do?” People like to say, “Hey, he's the Scrum guy or he's the Oracle database guy or he's the Balanced Scorecard guy.” My slot is really, I help you think through, “What are the potential slots in this situation?” to help you understand what sort of support you might need, by helping untangle the complexity at the outset before you’ve got a picture of what the slots are.

Bill: Yes, I think you’re facilitating and helping people solve their own problems. I think we are all often in the best position to solve problems once they are made more visible to us. I think we’re all susceptible to not seeing the obvious sometimes because we’re so used to living with them.

Graham: Yes – and, as a consultant, you're always helping people to solve their own problems. The nature of being a consultant is that you come in and do what you can to help, and you do what you can to help people build skills and understand their own situation. But at the end of the day, you exit at some point, and they’ve still got the mess, and they’ve still got the problems, and they solve them. You like to think that you can be the Lone Ranger riding in and actually


of 109

solving the problems, and leaving them in a clean state – then, actually, you're probably putting them in a state where it looks clean for a couple hours before the mess starts to come back at them.

Bill: Yes, exactly. Graham, thank you for taking time to talk with me today. You’ve made a strong case that by understanding your current state, you put yourself in a strong position to make real and lasting improvements.

Graham: Okay, cheers Bill.

Graham Oakes – [email protected] Graham Oakes helps people untangle complex technology, relationships, processes and governance. He assists organizations to understand their current state and hence develop strategies and systems that deliver business value.

His book "Project Reviews, Assurance and Governance", was published by Gower Publishing in 2008.

Find more information about Graham by visiting his website at www.grahamoakes.co.uk or connect with him on LinkedIn at http://www.linkedin.com/in/grahamoakes. Follow him on Twitter at http://www.twitter.com/GrahamDOakes.


http://www.amazon.com/Project-Reviews-Assurance-Governance-Graham/dp/056608807X

http://www.grahamoakes.co.uk/

http://www.linkedin.com/in/grahamoakes

http://www.twitter.com/GrahamDOakes


of 109

Jim Benson

How to Leverage Impatience to Drive Process Improvement Success

Bill: I’m talking on the phone today with Jim Benson. I’ve been following Jim on his Kanban adventures around the world for some time on Twitter. I’m also mid-way through reading his Personal Kanban book and trying Kanban out in my own personal activities. I’m excited to have the opportunity to talk with Jim today, so I’m looking forward to getting started by asking you the opening question, Jim: “What is your best process improvement strategy or tactic that’s worked really well for you or your clients?”

Jim: I would say that my best tactic is just being impatient, and so because of that our engagements only last a week and then there can be follow-up engagements, usually the next quarter. But I find that if we sign up for a very short, focused engagement we get right to the heart of the issues that a client has as opposed to coming in and very slowly and methodically going around and asking questions. And in order to get to that information quickly we use something that we call Lean Coffee where we will get together the people who are involved and we will have a directed, open conversation where the agenda is entirely picked and created by the participants.

And usually what happens is in about an hour or so there's a realization that these things that the organization has been focusing on, the issues that the organization has been focusing on, aren't the core issues that need to be addressed. Now I find that we've written an entire scope around one set of issues and we arrive on Monday and by the middle of the day Tuesday that entire scope is out the window as we've discovered something deeper and newer and ultimately more liberating for the people.

Bill: That’s ironic Jim because I was reading one of your blog posts a few minutes ago about the Lean Coffee. And coincidentally I attended a conference just a few weeks ago that used the same technique to establish the agenda for the week. It’s very effective for setting an agenda I believe.

Jim: It's gone beyond that because what we found is that every single company that we started doing Lean Coffees in have continued them after we've left. And they've usually continued them not because management says that they should happen but by popular demand. The rank and file, if you will, keeps going with the Lean Coffees. And what we've discovered is that people at work are generally too busy to talk about work, therefore improvement never happens because there's no avenue for these types of discussion.

http://www.amazon.com/Personal-Kanban-Mapping-Work-Navigating/dp/1453802266/ref=sr_1_1?ie=UTF8&qid=1322627542&sr=8-1


of 109

Bill: That’s fascinating that they continue after you leave. Why do you think that is? Is it because there's no forum for this type of discussion otherwise? What do you think?

Jim: Well yes, that and since Lean Coffees have no set agenda in the beginning they're not tailored to somebody's political needs, they're not tailored to a specific political element of the organization, and therefore it's very liberating. It's a way for people to come and actually talk about work because they care about the work that they do, because they're actually professionals and they actually have something to say.

Bill: A practice that I've used on fast-moving projects where there's a lot happening, a lot of people and it's very dynamic is something I call “build the agenda” where we have a basic idea of what we need to do but there's so much going on we don't know the whole picture. At the beginning of the meeting we'll just build the agenda together, but looking at how you do it using Kanban seems to add a whole new clarity to it. Any comments on how that occurs, what happens?

Jim: There are a couple of things that happen. With the Kanban, since you can change the columns of the Kanban at will, I've seen teams or groups get halfway through and then suddenly somebody will write down a follow-up and they'll add that as a column and then people will start putting sticky notes in that column as a result of the conversation or to do or to discuss next time or table for next time. There's that element of it where the format of the Kanban itself can change at the whim of the group.

The other thing is that some teams will take the conversations and they will limit the amount of time that you can spend on each one of the sticky notes, so they'll say for eight minutes or ten minutes we'll discuss this and then we'll come back to the group and we'll say conversation's going well, do we want to continue it or since we're about topped out on this let's move it along. And by doing that they keep everybody aware that the reason you're there to talk is to actually make some decisions and make some things happen and get some learning done and not just to run your mouth.

Then that leads to—and this probably happens with build the agenda as well—the group then owns the agenda so there's no longer a person who called the meeting. It's now a group meeting so people tend to do less things talk out of turn or talk over other people or derail the conversation because now rather than having a power struggle between them and the agenda holder, it's them and the rest of the group and that defused, or that shared responsibility tends to make meetings move fast, make them pretty exciting, and then when you're done people are like wow, I really learned a lot. It’s not so much yeah, I came here and talked about what he wanted me to talk about.


of 109

Bill: Okay, looking at how these meetings become more productive using this process, how would you characterize the results? There's the work that gets done and the direction gets set at the meeting. How does that impact the other work that gets done outside the meeting?

Jim: There's a variety of things that when we're going in and working with a team or with a corporation. Usually they come in and they say we have this set of issues we'd like help with and we say OK. We come in to do exactly that, but then we have the Lean Coffee and everybody puts down their tickets and the first ones are always those issues that we were asked to talk about. And then a couple others will appear, and then way down at the bottom there will always be this one and then everybody sees that and they recognize that that's the thing that was really upsetting everybody.

That's the thing that was really slowing them down, that was really causing people pain, and so they'll all vote for it. But if you ask them even after they voted for it what are the most important issues, they'll still say the ones at the top because it's kind of a combination of being taboo and often the problem itself is a solvable root cause but everybody has convinced themselves that the problems are much larger than they think they are. Then what happens as far as moving on to subsequent meetings or subsequent action, when something happens either in a Lean Coffee or in a Lean Coffee-style meeting everybody again owns the agenda so they also own the outcome, and they're more likely to be invested in it.

And since it came out of a productive meeting, people are less hesitant to call a future meeting about it. And there's a lot of books out there right now that call for two things—one is less meetings and the other is strong agendas. And I would like to see more meetings with no agendas. (Laughter) But with the only goal being to actually complete something and create it by the time that you're gone. So get together, work collaboratively, create something of value, have it be done, and then move on. Don't get together, divide up the thing that you're going to create into a bunch of pieces, send everybody off to a bunch of separate rooms to work with them without talking to each other, and then gather at some arbitrary point to see how everybody did.

If the group structure that created the idea also gets together and creates the solution, the solution ends up being created more quickly with less defects and is completed in a way that you don't have to come back and revisit it in the future so it's done, it's gone, and move on to the next thing to do.

Bill: Can we explore what you just said a little more, Jim? It sounds like this way of meeting is causing more people to engage fully in what's going on instead of just coming to a meeting, attending, and zoning out. Everyone is providing their input, they're being heard, and they’re more fully engaged. Is that part of it as well?

Jim: Yes, so whether it's being used in a meeting or so… rather than Kanban will just say, like, a visualization. Using some sort of visualization to show people at any given point in time what


of 109

hasn't been done yet, what you're working on and what's been completed simultaneously gives people reassurance that things get completed because they do see things that were actually completed. You see what's going on now, which gives you reassurance that people are actually working for a common goal and working with purpose.

You see what's coming up next so you see the context of the thing that you're completing now. I'm going to complete this thing now so that I can do these other things in the near future. All of those things combine to create a flow and so you start to see that work is created with a cadence, at regular intervals, that as that work is completed if there are interruptions in those intervals you immediately know that something's wrong, you don't have to wait for an alarm or a lagging indicator.

You see opportunities to collaborate with other staff and you see ample ways to either improve the process that you already have or to relish in the fact that you've already improved your project. And we've used this with software development and support groups and lawyers, marketing departments, with the UN to create major reports. We've used it for all sorts of knowledge work, not just for software development.

Bill: Jim, I have one question. I’ve had experience with Kanban in manufacturing but never associated with software development, and I don’t know anyone using it the DC area. Is Kanban adoption a regional trend or is it being more widely adopted?

Jim: No, this stuff in software development is rapidly overtaking Agile as a preferred methodology, and that's globally. But outside of software development people are just starting to take note, so we've used this in government but government is very focused on, as many corporations are, on an RFP-based system where you guess up front what you're supposed to do and then I beat on you at the end when you don't make your exact targets.

And you would think that with 200 years of experience we would have gotten by now the knowledge where it has a high degree of variation and that giving somebody a precise estimate is an invitation to failure. And it creates failure out of success. When I was working for government, I was an urban planner for over ten years, there were many projects where we would get 99 out of 100 things done and we would get in trouble for failing.

Bill: Yeah, I think I’ve experienced that! (Laughter)

Jim: You know, only 1% of the project wasn't complete and it's not even an important part and they're like the check box isn't checked.

Bill: That's kind of insanity, isn't it?

Jim: Yeah, well and it's the point at which it's impossible to provide value. Within the beltway there are a lot of software Kanban fans and the lean startup community is starting to be rather active. Between Derrick Huether, Paul Booth and then of course Tonianne DeMaria Barry, my


of 109

business partner who lives in Bethesda, there are Kanban people there and the first non-software Kanban project that Tonianne and I did was actually at the World Bank.

Bill: Jim, this has been another fascinating talk and I’m really looking forward to publishing it. Thanks so much for taking time to talk with me today.

Jim Benson – [email protected] Every organization has elements of efficient collaboration and elements of inefficiency and waste. Collaboration is something that people do naturally, but with individual styles. The best products result from well-run group projects. However, a group needs clarity of purpose, product, and plan in order to be successful. Given that people approach problems from different cultures, styles of learning, and ego states, this can

prove challenging.

Jim Benson’s career has included psychology, urban planning, government technology planning, software development, and corporate change management. During his 20 years of experience, he has acquired an appreciation for how people, teams, and organizations process information, set goals, and achieve their objectives. A fundamental part of this appreciation involves the identification of opportunities for waste reduction and innovation in knowledge work.

Knowledge work is fundamentally tricky to gain focus around. Knowledge workers are by nature inventive, but highly susceptible to political shifts and misdirection. Invention, innovation and politics can be unpredictable. For the past two decades Jim has worked at uncovering ways for groups to find clarity in unpredictable and amorphous environments. He has led expansive teams including social scientists, computer programmers, urban planners, business developers, concerned citizens, and writers to successfully create complex rapid-release products. He has led these teams both in-person and on-line.



of 109

Dale Emery

The Amazing Power of Asking Questions and Following the Energy

Bill: I’m talking on the phone today with Dale Emery. Dale is a consultant to software teams and leaders. I met Dale at a conference this past fall and observed that he was sought out by many in attendance for his expertise on a variety of topics. I also noted that Dale had a special talent for helping people solve problems by asking good questions. Dale, I’m looking forward to getting started and asking you the question we ask everyone: “What is your best process improvement strategy or tactic that has worked really well for you or your clients?”

Dale: The thing I try to do is help people use skills and knowledge they already have, but for some reason are not applying to their current goals or activities. People always have knowledge and skills that, for whatever reason, are just not occurring to them in the moment. So I try to help people tap into their existing abilities.

Bill: That’s really very interesting, Dale. I'm always surprised by what comes out of these interviews when I ask this question. Any thoughts on why you think that is?

Dale: Why I do it, or why it works?

Bill: It’s more along the lines of why do we behave in that manner. I'm speaking from my own perspective that I don't always apply the skills that I know I have. When I ask this question to interviewees, it seems to cause some reflection that result in responses that are surprising to both the interviewee and me.

Dale: Right. I don’t think the problem is that we get stuck first, and then can’t remember what we know. I think we forget something first, and that’s how we stuck. If we remembered what we knew how to do, we wouldn't be stuck.

There’s a rule that coaches sometimes use that says people have all the skills and knowledge that they need. I don't think that’s necessarily true, but people always have relevant skills and knowledge that, for whatever reason, they’re not applying right now.

I think it’s because of human limitations. We can never access everything we know. I've had friends and relatives who applied to go on game shows, like Jeopardy and others, and during the audition they blow an answer that they knew. They know the answer but for whatever reason, it just doesn’t come when they need it, and I think that’s a human thing.

We sometimes make the problem worse by becoming really analytical, really focused on what we're trying to do. Logic and analysis are great when we have the facts and data and knowledge


of 109

available to us. And when our knowledge isn’t coming to us, overly focusing on the things that are coming to us can limit our view.

We get so focused on solving the problem, we get so wound up in solving the problem that we don't allow ourselves to step back and let the associative part of our brain help out, let the knowledge come in. For example, when you’re having a conversation with friends, and somebody says, “Oh, who was that actress in that movie?” And nobody can remember. But on the way home, you suddenly remember, “Oh, now I remember. Maggie Smith! Of course!” The answer comes when we’re not trying so hard to think of it.

Bill: Exactly.

Dale: I think it’s just human limitation, just the way our brains and minds have evolved. I think it’s marvelous that it comes to us at all. The fact that we can remember stuff at all is miraculous.

Bill: It really is. So how do you help organizations or people through this, Dale? Do you have recommended solutions or things that you've done that have worked well?

Dale: I focus on asking a lot of questions. Something about my demeanor allows me to ask nosy questions in a way that people are willing to answer. I don't know exactly what it is about me that lends itself to that, but I can ask questions and people are willing to say things are potentially embarrassing for them or that are potentially emotional for them. Somehow, I create an environment in which they’re willing to open up.

So, a lot of what I do is ask questions. I stumbled onto this approach many years ago. Once upon a time at the company where I worked, I was the C++ guru. I knew all the ins and outs of how the C++ language worked, and I knew the quirks of various compilers on different platforms. So whenever people would have a problem, something with compiling or the behavior wasn’t quite right, they would come to me and say, “Dale, what’s going on here?” and I would tell them the answer. Now, the reason I knew the answer is that I had struggled all the previous day to solve exactly the same problem myself. But they didn’t know that. Really I was just one day ahead of them, but they thought I had all the answers in my head. I’m sure I played that up, and encouraged them to think I was magical.

Eventually people started coming to me with problems that I didn’t know the answer to off the top of my head. I would ask them questions so I could understand the problem better, so that I could solve it for them. That was my goal at the time: To solve people’s problems for them. I’d ask, “So what have you tried so far? What happened? And what haven’t you tried?” One of my favorite questions was, “What haven’t you thought of yet?” That is a strange question that works more often than it has any right to.

I discovered that as I asked people these questions, more often than not, they would solve the problem right in front of me. I never got to the point where I understood the problem well enough to solve it, but in answering my questions, people reminded themselves of things and they made connections between things that helped them solve the problem.


of 109

The pinnacle of this was one day a colleague popped his head into my office and said, “Dale, I—” Then he stopped, looked thoughtful for a moment, then turned and walked away.

I caught up with him at lunch and said, “What was that all about?”

He said, “On my way to your office, I was asking myself, ‘What questions will Dale ask me?’ And by the time I got to your office, I had solved the problem myself.”

Bill: That’s hilarious, Dale! Funny thing is that I heard people at the conference asking the same question, “What questions will Dale ask me!”

Dale: That’s how I got into this habit. I didn’t have enough information to solve the problems, so I asked questions. Eventually I realized that asking questions, asking the right questions, asking better questions about a problem always helps people get unstuck. It always gives them ideas. And often, the ideas are enough to solve the problem. Not always but often. So this became a core technique for me.

Bill: I can really relate to this Dale because in the week we spent together at the conference, I was struck by the quality and nature of the questions you asked. I also think part of it is that you’re really a good listener. You seem to be able to ask the question that would open the door in someone’s mind that will provide the solution.

Dale: One of the principles I use is: Follow the energy. By “follow the energy,” I mean that people always give you clues about where their energy is, and where it’s blocked. Something about the way the person is reacting. Maybe they suddenly become a little more animated or less animated, or suddenly sit forward or back, or suddenly their expression will change. I notice those things. I don't know what they mean, but I think the shift means something, so I ask. “What just happened for you?”

Often someone will start a sentence, then stop themselves and go off in another direction. I’ll say, “Wait a minute, go finish that sentence. How would you end that sentence?” And the thing that was on their mind, that they stopped themselves from saying, turns out to matter. Now, sometimes people stop themselves because what they were about to say is mistaken, or irrelevant. But often it turns out to be important.

Those are examples of following the energy. The things that are on people’s mind, the things that are concerning them, the things that are troubling for them, I want to know a little bit more about those things. I’m especially interested in what’s keeping them from realizing the stuff they already know, what’s getting in the way of them solving the problem, of using what they already know. It’s often an emotional reaction to the problem, or to having the problem, or to not being able to solve the problem, when they think they shouldn’t have the problem or ought to be able to solve it. All of those “shoulds" and “oughts” can get in the way and keep people from remembering what they know.

I stay well away from doing therapy, but I watch the energy, and that gives me information about what questions to ask about their process of problem solving.


of 109

Bill: Dale, you asked me that same question, “Where’s the energy?” early in the conference when I was getting oriented. That question has stuck with me ever since then, and I've used it a few times with others as well as myself.

Dale: I remember. I don’t think I explained it well at the time, but I’m happy that somehow the question meant something to you and you've been able to use it.

Bill: I think you explained it very well, Dale. I think the question itself resonates very well with people.

Dale: Another thing I listen to are the words people use. I was sitting with a group of people who were coaching each other. One person described his problem, then said with frustration, “And nobody’s paying any attention to this.”

I noticed those absolute words “nobody” and “any,” and I challenged them. “So nobody’s paying attention to it.”

He shook his head. “No, nobody is.”

I said, “You’re paying attention to it.”

“Well, nobody else is.” And then he thought a minute and said, “Well, OK, there are two people who aren’t.”

And then we were off. We loosened up his thinking to the point where he could attend to who was paying attention to the problem and who wasn’t, and the problem was much smaller than he had made it in his head. It was still a problem, but now he had a better understanding. He had exaggerated the problem in his own mind to the point where it was unsolvable.

So I listen and watch for lots of things, and ask lots of questions. I can explain some of what I do, but not all of it.

Bill: It’s interesting, Dale. Several other contributors to this publication have talked about using questions to guide an improvement initiative, but I think your approach is unique. Rather than ask a set of specific questions, you are helping people answer their own questions. Do you have any ways to help guide the conversation and direction?

Dale: You asked me about change in organization. In organizations, I like to follow the energy by using an approach that’s become fairly popular recently, called “appreciative inquiry.” I don't do appreciative inquiry exactly in the way that’s described in the books, but there are parts of it that I use all the time.

Well, I'll give you an example. I was at one organization where they wanted to improve their development process in some way. And in order to gather information about how they work and what they do, I got people together in groups of three or four and asked each person to tell a story. “Tell me a story about a time you were really excited at work. Tell me a time you were really jazzed. Tell me a time you were really proud of.”


of 109

What was interesting is that everybody had an inspiring story, and the stories had a couple of things in common. Every story was about something that was possible for these people. Possibility is one of the key attitudes that appreciative inquiry helps to magnify. If we've done it in the past, we can do it again.

Most of the stories were about that organization, which meant that each inspiring story was possible not only for these people, but here, in this organization. One of the stories was from another organization. But the person thought for a moment, then said, “There’s no reason we couldn't do it here just as well.”

Finally, every story was something that people had a lot of energy for, and in recounting that energy, they gave themselves more energy for trying something here and now.

I really like, at least, the general attitude behind appreciative inquiry. What are we good at? What have we been able to do in the past? What are our positive experiences that might have some relevance to what we're trying to do here and now?

There’s a principle behind this that that I learned from Marvin Weisbord, a famous consultant who wrote a number of great books about helping organizations change. One of Weisbord’s principles is: What is possible here? Always be on the look-out for what is possible here, and appreciative inquiry is a great way to tap into that: Something that works for these people that has worked in this environment, that we have energy for.

Bill: Dale, I knew that you would have a fresh and interesting perspective on process improvement and you didn’t disappoint. Thank you for very much for taking time to talk with me today.

———————————

Dale Emery – [email protected]

Dale Emery has worked in the software industry since 1980, as a developer, manager, process steward, and consultant. From 1995 to 1999, Dale consulted to IT and software product development organizations about software development, project management, and team and interpersonal effectiveness. From 1999 to 2002, he worked in Sun Microsystems’ IT organization to define, promote, and support

effective software development, project management, and leadership practices.

In 2000, Dale became interested in Agile Development techniques, and has since applied the Agile values of communication, feedback, simplicity, courage, and respect to all areas of software development and software process improvement, especially to the practices of leadership, management, and team effectiveness. In 2004, he began collaborating with Elisabeth Hendrickson to help clients improve their unit testing, integration testing, and system testing processes. Dale considers himself privileged to teach Elisabeth’s wonderful Creative Software Testing class.



of 109

Guy Wallace

How to Use Performance Modeling to Improve Human Performance

Bill: Today I’m talking with Guy Wallace, President of EPPIC, Inc. and a certified Performance Technologist located in Charlotte, NC. Guy is involved in human performance technology, which is an area of performance improvement that is outside the usual focus of this series. However, I was intrigued with his background in quality initiatives at Motorola and his work in this area, so I thought his work would be of interest. I am excited to have the opportunity to talk with him today. Guy, “What is your best process improvement strategy or tactic that has worked really well for you or your clients?”

Guy: I use a set of methods or a method that I call performance modeling. I’ve been using that since 1979. It’s a derivative of a Geary Rummler-Tom Gilbert approach to modeling performance.

Bill: Some people may not be familiar with this approach, Guy. Can you give us an overview?

Guy: Basically there are two parts to it. Part one is establishing what I call the areas of performance, and the second part is capturing all the details per area of performance.

Back to number one, the areas of performance are also known as major duties or key responsibility areas. For example, DMAIC would be a framework of areas of performance from the Six Sigma world; ADDIE would be a segmentation scheme of areas of performance for an instructional design world. As another example, new product development efforts usually have phases, sometimes phase zero, one, two, and three with different names on them. Engineering methodologies have customer requirements that lead to design and building prototypes. They’re establishing areas of performance so you can then dive into each one and capture all the details.

The goal of establishing areas of performance upfront is to minimize any overlaps and gaps. Once you have done that you don’t worry about missing something later and you don’t worry about inadvertent or deliberate overlaps.

It’s a little bit different than Tom Gilbert’s major duties, as described in his 1979 book Human Competence, in that it’s not looking at the things that are common across performance — it’s looking at performance in a process orientation. You’re looking for performance cycles. For example, what does an airline pilot do? Well, one of the things they do is go check the airplane on the inside and the outside. They check all their gauges, and they go through their routines, take off, fly the plane, make the announcements, and land the plane. You do this to establish the areas of performance. I often do this in a group forum with master performers and other subject matter experts. You get them to concur that you have identified one way to frame the scope of performance, it covers it all, it doesn’t overlap into other areas, et cetera.

http://en.wikipedia.org/wiki/Human_performance_technology

http://en.wikipedia.org/wiki/Six_Sigma

http://en.wikipedia.org/wiki/ADDIE_Model


of 109

The second part is capturing segments or areas of performance, the ideal performance, and then the gaps – and capturing that in a single page format. An area of performance might go beyond one page, but you’re looking at: "What’s the ideal performance look like, and what are the gaps?"

I typically do this in a group forum— but this can also be done through individual interviews and observations—but what you’re trying to do is identify the key outputs per area of performance. That depends on what your need is for downstream use; that dictates how detailed you are with this. Next, you need to determine the measures that are applied to those outputs. You are answering, “How do you know a good one from a bad one?” How do you assess that? You can list the tasks associated with each output. It’s doing a task analysis, but it’s within the context of the output; the output is within the context of the area of performance.

Once we have identified what are the outputs and their measures, and the tasks performed, we can begin to define the roles and responsibilities of different performers, players and roles in that performance. We can begin to have some role clarity as to who’s doing what. What’s the senior engineer doing? What’s the junior engineer doing? What’s the customer doing? What’s the supplier doing? It all depends on who’s involved!

The above constitutes the ideal performance. If you’re dealing with master performers, you’re capturing real, ideal performance and not Blue Sky, ideal performance. Blue Sky ideal performance is something that’s never been achieved—but real, ideal performance is what master performers actually do and have accomplished. Then the question becomes, from a gap analysis standpoint, “Well, why isn’t everybody else performing at this level of mastery?”

In my experience master performers typically know why other folks aren’t performing to a level of mastery, and they can tell you why. What I do to determine gaps is focus on the ideal outputs and measures. I then ask them, "Does the rest of the world miss these measures when producing these outputs? Which measures do they miss?" We basically focus them back on the outputs and the measures and say, "Which of these measures are typically—not atypically, but typically—missed?"

Then we ask, “What is the probable cause?” Usually when I’m doing a group forum I don’t have time to go deep and get the root cause for every issue and produce those outputs to those measures. But we can capture that this may be a probable cause. When we’re in a hurry we’re just capturing this at a high level. If it’s worthwhile, we’ll go back later and look at this more specifically and drive down deeper, ask why five times, or whatever the methodology is, to capture the real root cause.

I used the weasel phrase of “probable cause” because that’s the consensus of the master performers in this case. Why isn’t everybody else a master performer? Why are they missing that measure on that output? They give me their reasons, and we agree to attribute those reasons to it being a deficiency of the performer’s knowledge and skill.

Or is it a deficiency of the other attributes of the performer? Maybe they are not ambiguity-tolerant and there’s chaos, and they like things to be more stable. In that case, we’ve got a selection issue versus a training issue.


of 109

Or is the cause rooted in a deficiency of the environmental supports? Maybe they’ve got bad data that they're working with, and they don’t recognize it’s bad data before they use it, and that’s the cause.

Master performers can usually come to a consensus on what the causes are for measures being missed. What are the probable causes, and what’s the root of that probable cause? But just because a group of master performers can come to consensus on what that is doesn’t make them right. But who else would you ask?

You can later confirm that cause with observations and other interviews, as well as other ways. The master performers may have nailed it, and that is the cause for other people not being able to perform at a level of mastery. Or maybe they’re not recognizing the bad data, or they don’t have the knowledge and skills—it takes many years to become a master performer, and if they’re just not there yet, then we’ll need to give them time.

Bill: I’m starting to understand what you do now, Guy. I would say most of the people I’ve interviewed have been more focused on the software industry and the processes and methods that are used in the engineering and support areas. My sense is that you are more focused on the human or people performance aspects. Is that correct?

Guy: Yes. I come at this from the roots of performance-based instruction – but also from Quality and Six Sigma, but I use a different tool for the process mapping or modeling. The roots of Six Sigma come from a combination of TQM tools and the techniques of Geary Rummler’s process methodology, all invented at Motorola back in the early-to-mid '80s when I was there.

This is a different approach to process mapping, but it accomplishes the same goal of identifying the flow of the process. But it also gathers other data such as, “What are the gaps? And if that's the ideal performance, where’s everybody else compared to that?”

Bill: I would like to get back to master performers for a moment if I may. Master performers are people that are performing at a higher level, and so they know why the others aren’t performing at that level, and you unmask what these issues are? Is that right? And then you get agreement from the others to adopt new methods, do things differently or use different data?

Guy: Yes. We figure out the root causes. If people have bad data, you’ve got to crawl upstream to determine what are the sources of data and why are they delivering bad data. You can say, “Well, we need to teach people to recognize good data from bad data before they use it.” But this can also allow you to actually go upstream to the source of the bad data, tools, materials or whatever is the cause and begin to deal with it more systemically, not just with the performers.

What are the causes of the problems? If it’s, as Deming might say, that 94 percent of the problems are with the system under the control of management, not of the performers, why is bad data showing up? You’ve got to look at where the enablers of process performance are coming from. Where are they coming from, and why are they faulty? Is it our suppliers? Is it the receiving dock? Is it the suppliers, when they’re not doing their own quality assurance?

My goal coming at this typically from an instructional design perspective is that it’s usually not instructional. It’s not the knowledge and skills that are a deficit with the performers; it’s other


of 109

causes. Now, we can warn them through instructional means, what to look out for and how to tell good stuff from bad stuff so that they can perform at higher levels because. If these master performers are capable of doing that, we want to get everybody else up to that level where they have the same kind of awareness, knowledge, and skills of the master performers.

Often when I’m doing the data gathering for performance modeling I have the master performers in the room. I also have other subject matter experts. I may have downstream customers, upstream suppliers and the managers of this target audience, so that when doing this performance modeling leads to other things beyond instruction, they understand it. Once you’ve captured ideal performance, gaps and their probable causes or root causes, you can begin to systematically derive all of the enablers of process performance.

I have a model that follows the performance modeling to systematically derive those enablers. But if you think about enablers from the perspective of an old version of the Ishikawa diagram with his Men, Materials, Methods and Machines, I do things differently. I separate things into two sets: the human assets that enable process performance, and the environmental assets.

I begin to look at what the humans really need to bring to the process. Do they need to have certain physical capabilities? Can they be in a wheelchair? Are there psychological attributes that they need to bring, or intellectual attributes, or specific knowledge and skill attributes that they need to bring to enable them to perform?

Do I affect this through better recruiting and selection processes, or training and development processes, or performance management processes giving clearer expectations and feedback to people? Do I affect my reward and recognition systems, my compensation and benefits systems to affect the human side of process performance?

Or do I need to focus on other systems that provide the environment and environmental supports to the process—the data and the information, the materials and supplies, the tools and equipment? Is it the financials, the head count budgets and the other capital budgets? Is it the facilities and grounds that people use? Do we need a clean room where we've got open windows and dust flying around? Is that the cause of this performance gap?

Or is it really the culture and consequence systems in place? Do we have the right culture in place to do this process performance? Does the culture need to vary at different locations? Does the culture need to be different in different locations as that has an effect on terminal performance?

Performance modeling is a means to the ends of figuring out what’s ideal and where are the master performers performing. If we got everybody to be more like them, what impact would that have on the business metrics? What would that change in terms of our quality, cost, and time kinds of measures?

What would be the return on the investment for addressing some causes to get more people to operate at the level of mastery—which isn’t theoretical; it's what master performers are doing today. And if Guy was not operating anywhere near the level of, can we accelerate his time to performance, his ability to get to be more at that mastery level, and if we got Guy and the rest of them there, what’s the end result, what’s the worth, what’s the value of doing that? Then we can


of 109

look at what the costs are for getting Guy and the other non-master performers to that level to complete an ROI projection.

Bill: A couple of comments, Guy. I think many people who read this interview series may not be familiar with the type of performance improvement you perform. I know many people believe that the human performance aspect is too often ignored. In order to help me and maybe others, can you talk about the types of applications and organizations where you have performed this work?

Guy: My client list is over 60 firms, and more than 40 are Fortune 500 firms. My clients are usually from the HR, training and learning worlds. At other times I’ve been brought in by engineering organizations. Their terminal goal is usually to put the training in place that is needed; the learning and development if you want to use the current language.

I come from the vantage point of looking at the human element of process performance, and how to do things for the humans. What I’m trying to do with this methodology is to help my clients avoid spending money on training or other things to affect the humans, when the root cause is elsewhere, and you can’t fix it through training. If you’ve got incoming materials and upstream supplies that are defective, training the humans won’t really fix it.

There are a lot of parallels, I think, with the quality movement and the folks at ASQ and such. But my professional home is ISPI – the International Society for Performance Improvement. They are coming at improvement from a training, instruction, or learning perspective, recruiting/selection, Organizational Development (OD) and all the other things that affect the human element and performance capability.

Bill: It also parallels some of the approaches others in this interview series have talked about. Instead of coming in and applying a methodology, they’re spending more time uncovering or finding that person or people in the organization who have the best practice and way of doing things. They're finding those people, finding out what they do and highlighting it and saying, “This is how we need to do it. If you have a viable business that’s profitable, you’re doing something right, and here are the people that are doing it right. We need more of the people to do it right.”

Guy: Exactly. This performance modeling is about best practices. I use a group process – and this group process was first publicized in Training Magazine in September 1984 – and also in my professional society’s journal at the time, the Performance & Improvement Journal, in November of 1984. This approach has been used a lot since then, and it really is about trying to get a consensus -- not just looking at one individual and going “AHA” - I've observed and interviewed one person - and they’ve got a best practice here.

I use the group process to get a collection of master performers to say, “Well, that situation over there and this person’s situation here work because of this and that. However, it wouldn’t work in mine because of these other variables.” We don’t force a consensus.

What I’m trying to do by using a group process is much the same as when you bring a group of people together to model a process—whether that’s an existing as-is process or some greenfield process. You can use this performance modeling for greenfield efforts, too. You’re really trying to do the same thing as what the people who are doing process mapping are doing. You’re


of 109

trying to be very clear about what the process is, what’s one that works and produces products with tolerable variability, whether that’s two sigma or six or nine.

I come at this much the same as the whole quality world does. The IT business and the process management world all come in and look at how we improve performance. Everybody comes with their favorite set of methodologies, whether that’s Lean, Six Sigma, Theory of Constraints, et cetera. When you first look at a performance issue, a problem or an opportunity, if you were to stand back and say before you started thinking about applying Lean and Six Sigma to this thing, “Is that really going to uncover the cause of this issue? Is that the right methodology?”

Or is it just that people haven’t been told what the expectations are, and if you only told them what you really wanted in the first place, and gave them corrective and reinforcing feedback, you'd solve all your problems; maybe then you don’t really need to Lean the process, and you don’t need to bring the variability down to Six Sigma levels. The fact is the above approaches might be overkill. My methodology will uncover the fact that you do need to get that variability down, and that it’s not just about the human beings and their capabilities. It’s maybe more about the process; it’s about the machine tolerances, et cetera. It’s elsewhere – it’s not the humans.

So rather than playing Whack-A-Mole with the variables of process performance, you’re really trying to understand what is ideal and where the gaps are and which improvement methods are appropriate.

If the ideal current state isn’t good enough, how do you then step that up to cause a “step increase” to get it where you really need to be? You need to bring in the people who have some perspective on that. Master performers would have one perspective, and other subject matter experts would have another.

I had one effort with Alcoa back in the '80s where they said, “Well, this is a great methodology here, but we don’t have any master performers.” And I asked them, “Who knows what you’re talking about, what you're trying to achieve?” They responded that there’s only person, a professor in Scotland. I said, “Well then you need to bring him in here and have him talk about this ideal state, and how he would do this. And you also need to include your other master performers, your engineers here—because you’re talking about casting aluminum in mid-air—to improve all the various qualities of that aluminum ingot in your context; and so that’s who you need to bring together.” The professor can talk about his ideal Blue Sky, that this is how you do that, and the others can respond, “Well, in our real world, with gravity we have these issues.” And they can decide if and how to meet somewhere in the middle between the theoretical ideal and the real.” They can plan to do continuous improvement after doing some discontinuous improvement if needed.

This approach has been used after Six Sigma projects have been completed and where a process was globally standardized. We used this performance modeling methodology to take the initial articulation of the process from a Six Sigma effort, and further detail it out in terms of what all of the micro tasks were and then systematically derived the enabling knowledge and skills that were needed to perform each process step.

These are some examples of what performance modeling methodology can be used for. It’s really aimed at trying to figure out what do people need to be aware of or knowledgeable about,


of 109

and/or skillful in, in order to perform within that process. It’s also important to define the other enablers that might be probable causes for any gaps in current state performance.

Bill: Guy, thank you for taking time to talk with me today and sharing with us how you help your clients improve. I think you’ve shared some very interesting approaches that people may want to consider applying to their existing improvement efforts.

Guy Wallace – [email protected] Guy has worked as a consultant on over 250 projects for over 60 clients including over 40 Fortune 500 firms. His work has won numerous awards and recognition – and his clients staff have won awards for the work they’ve done after he trained and developed them, including in project planning and management, instructional and performance improvement analysis, design of ISD in the CAD and MCD levels of

design of the PACT Processes for performance-based Training, Learning and Knowledge Management.

Guy’s specialty, since his first back in 1982 and with Exxon Exploration USA for their Geologists and Geophysicists, is Curriculum Architecture Design – CAD - which is used for the development of performance-based Training Paths (Learning Paths, Development Roadmaps, etc.) that reconcile the performance requirement needs with the existing content to identify gaps and overlaps of content – to create a holistic approach to both On-Boarding and On-Going Development – for Performance Requirements Competence.

Guy has conducted 74 such CAD efforts since that first in 1982. His and client staff that he developed have also produced hundreds and hundreds of additional efforts.

He co-authored the first article published on Curriculum Architecture – in Training Magazine in September 1984 – and was the first to present nationally on the topic – at an NSPI Conference in 1985.

He has been teaching others on his staff and on his corporate clients’ staffs these ISD – Instructional Systems Design’s analysis and design methods for CAD – and at the course development level – since 1983.

He may be reached via his web site at: www.eppic.biz


http://eppic.biz/about/guys-awards-recognition/

http://www.eppic.biz/


of 109

David Anderson

Kanban Systems: An Evolutionary Incremental Approach to Improvements

Bill: I’m talking on the phone today with David Anderson. David is President of David J. Anderson & Associates, and also Vice President at Lean Software and Systems Consortium. I first became aware of David and his pioneering work in Kanban when I attended his session at an SEI Software Engineering Process Group conference in Porto, Portugal. Since then I have been following David on his Kanban adventures around the world on Twitter. I’m also planning to read his books in the coming year. With that introduction, I’m excited to have the opportunity to talk with David today. David, I’ll get right to the question if I may: “What is your best process improvement strategy or tactic that has worked really well for you or your clients?”

David: I developed the use of virtual Kanban systems for controlling the work that people have in progress. That has evolved into something that gets referred to as the Kanban Method for catalyzing incremental improvements. You find the number one problem, fix it, then the number two problem gets promoted. This evolutionary incremental approach to improvements is my number one process improvement strategy. The number one problem I’ve seen with clients and in places I’ve worked is that people resist change. So finding an incremental, evolutionary approach to change has been the one best thing that I have in my tool box. And currently my favorite way to create such change is through the use of virtual Kanban systems.

Bill: David, because I have a manufacturing background and I’ve worked with clients who used Kanban in manufacturing operations, I never imagined it would get applied to this environment. What were the challenges? How did you get to point of using Kanban? Were you familiar with it from manufacturing?

David: I wasn’t particularly familiar. There were a number of other things that led up to having this ability. The key insight was recognizing that we could track the flow of knowledge work activities, like software development, by identifying different states of completion of the work. These could be tracked in something called cumulative flow diagrams, which are a way of visualizing the quantity of stock or inventory that’s in a factory at different stages of manufacture. That technique wasn’t necessarily, at that point, using the idea of a virtual Kanban system. With a Kanban system, there is a fixed limit to the work-in-progress, which is controlled by the number of Kanban cards in circulation. However, tracking flow and mapping it using cumulative flow diagrams was the enabler and the recognition that if we could visualize and manage the quantity of work-in-progress, then it was just a small step to actually limiting it (with a Kanban system.)

The key insight is that in knowledge work problems, the Kanban are not physical; it’s just a virtual concept where you agree to limit the work-in-progress to some quantity of something, and that sounds very ethereal because it’s hard to pin down what these things are because they’re not physical. So for example, the requirements for a software system; each individual

http://en.wikipedia.org/wiki/Kanban


of 109

requirement would be treated as a unit of inventory or a piece of work-in-progress that’s limited by Kanban. There were a number of key insights that made this possible: the idea that you can identify individual items of knowledge work in some way and map them as if they’re inventory in a manufacturing system; then track the state of completion and map that flow; and then restrict it at different stages of completion using a virtual Kanban mechanism. All those things came together, but that in itself doesn’t sound very interesting; it doesn’t sound like it would be worth anything. Why would you want to do it? The results are really very counterintuitive.

Bill: A question that’s occurring to me based on what you just said is that this sounds very similar to Lean and Agile types of methods. How would you contrast Kanban with Lean and Agile methods? Does it belong in that camp or is it something different?

David: I see it as something different! This is because I came to discover this technique as I perceived that people, companies, and organizations were resisting the adoption of Agile software development methods. The idea that you try and persuade people to switch to some defined method that’s written in a textbook, and make that switch all at once, was prevalent particularly in the earlier part of the last decade. This approach is what people were resisting.

Agile methods were really sold as an all or nothing bet. They were marketed as fragile ecosystems where you had to, for example, do all 12 practices in Extreme Programming or it wasn’t guaranteed to work. So adopting all 12 of those practices all at once was very challenging, and there was really no guidance on how to incrementally adopt the practices in Extreme Programming in those early days. To be honest, even today, there are very few Agile coaches and consultants who are capable of correctly assessing a context and advising a client on incremental adoption.

The critical difference is that Kanban is not a method, like an Agile software development method, or a project management method. It’s a way of provoking and catalyzing changes in an organization. What those changes might be is contextual, situational and will be unique for each different organization that tries it. Some people have used the term meta-method. I’m not particularly comfortable with it because I prefer plain language, but the idea that Kanban is a meta-method for incremental evolutionary change, maybe that’s accurate! In comparison, a typical Agile software development method is a way of doing software and you have to switch from what you’re currently doing to adopt it, and that’s clearly a whole different thing altogether.

Bill: I’d like to ask about the provoking and catalyzing change part of Kanban, David. I’m fascinated by that. What is it about Kanban that makes that happen or allows that to manifest?

David: It’s primarily the virtualization of the invisible knowledge work combined with the work-in-progress limit that exists at any one stage in the development of a piece of that knowledge work. The reality is that there is a lot of variability in the work that we do. Every requirement is unique and different, involves different technical complexities and different risks, and perhaps involves different people. There are lots of dynamics going on in the workplace, and the result is that the flow of work ebbs and flows, and when there’s no limit to the quantity of work people are doing, if they have some sort of impediment or some slack, they just go and


of 109

start something else, and gradually, the quantity of work in progress grows and grows and a lot of it gets stale.

Another critical insight that I didn’t mention earlier is the idea that knowledge work is perishable. The faster you can turn an idea into something that works and is complete, generally, the better quality it is, and the more demand or need for it there is with the market or the customers or the users of the system. Unlimited growth in work-in-progress is bad, and what a Kanban system does is it prevents people from starting things when they experience variability from impediments, or simply the natural ebb and flow of things, causes them to be idle.

Because people can’t start something new, it seems to have the effect of provoking the inquisitive nature of knowledge workers and particularly software developers. They will start asking questions about, “why it is I am idle, other than the fact that the Kanban system is preventing me from starting something else? What is it that caused us to reach the limit and for me to be unable to start something new?” So that makes them inquisitive and they go ask or start studying the dynamics of the work that they’re involved in. This tendency to reveal things which have always been there if they’d troubled to go and look. The effect is that they start discussing it with their colleagues, and improvements get suggested and introduced. The work-in-progress limit is what causes the conversations to happen. It causes this inquisitiveness, and in turn, it causes conversations, and those conversations turn into process changes.

Bill: David, I’ve learned a lot of unexpected and valuable things about Kanban in the past few minutes, and I’m sure many readers will have the same reaction. Where should people go to find out more about Kanban? Would you recommend they read your book or go to your website first?

David: There are a number of good resources. Certainly, reading my book is probably the best and most definitive, but there is also a website that I jointly own with Alan Shalloway called Lean-Kanban University. And there are a number of resources on there, and that site is emerging as a resource for companies around the world that offer consulting and training in Kanban. If someone was interested in learning about Kanban, LeanKanbanUniversity.com, or certainly my book, is available directly from DJAndersonAssociates.com.

Bill: David, I really appreciate your time. Thank you again!

David Anderson – [email protected] David Anderson is a thought leader in managing highly effective software teams. He is President of David J. Anderson & Associates, based in Seattle, Washington, a management consulting firm dedicated to improving leadership in the IT and software development sectors.

David has been part of the agile and lean methodology movement since 1997 when he participated in the team that developed Feature Driven Development at United Overseas Bank in Singapore. He has 26 years of experience in software development starting in the computer games business in the early 1980’s. As a pioneer in the agile software movement, David has managed teams at Sprint, Motorola and Corbis delivering superior productivity and quality. At Microsoft, in 2005, he developed the MSF for CMMI

http://www.leankanbanuniversity.com/

http://leankanbanuniversity.com/



of 109

Process Improvement methodology - the first agile method to provide a comprehensive mapping to the Capability and Maturity Model Integration (CMMI) from the Software Engineering Institute (SEI).

His first book, Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results, published in 2003 by Prentice Hall, introduced many ideas from Lean and Theory of Constraints in to software engineering.

David was a founder of the APLN, a not for profit dedicated to promoting better standards of leadership and management in the technology sector.

David is a popular and entertaining conference speaker. He has written or co-authored many articles and papers and is best known for his Agile Management blog. Most recently, David co-authored a Technical Note from the Software Engineering Institute titled, CMMI and Agile: Why not embrace both!

He holds a degree in Electronics and Computer Science from the University of Strathclyde, Glasgow, UK. He has six U.S. Patents and another five pending for his work in telecoms and the Internet. He lives in Seattle, Washington, USA.


of 109

Next Steps and Acknowledgements

Please Let Us Know What You Think

As the reader of this paper, you are our most important critic and reviewer. The publisher and contributors to this paper want to know what you think about the information presented, what we could do better, what additional topics you’d like to see published, and any other comments you’re willing to share.

Our Contributors are Available to Answer Your Questions

We hope this paper has provided you with helpful information to get your process improvement efforts headed in the right direction and on track for 2011. However, if you’d like additional information on any of the topics presented, our contributors are available to answer your questions. Please feel free to visit our contributors’ web sites or reach out to them via the email address provided in their bio. This Paper Will Continue to Evolve

This paper will continue to evolve and will be continuously expanded and updated. Please make sure you have submitted your contact information at the 5 Minutes to Process Improvement Success website at www.5minutespisuccess.com to be notified when updates are released.

Recommend Someone to Interview

We are interested in interviewing anyone who is achieving uncommon success and leveraging process improvement to achieve real performance gains. Please email your recommendations to Bill Fox at [email protected] or by phone at 540-454-6986.

Acknowledgements

This white paper never would have been published without the enthusiastic support and guidance from a number of people. Karen Base, CEO of KLB Solutions, LLC, provided strategic direction on content focus and guidance on the selection of the initial interview candidates. Kevin Schaaff, Project Manager with Booz Allen, and Mario Hyland, Sr. VP with AEGIS.net, provided frequent feedback on various aspects as the paper evolved. Hillel Glazer, CEO of Entinex, was a strong supporter and provided guidance on future direction. Sagar Sawant, CEO of Cyquent, Inc., provided enthusiastic support and supported my continued growth and involvement in process improvement. Lauren Fox, student at Gettysburg College, assisted with editing services.

http://www.5minutespisuccess.com/


mailto:[email protected]?subject=Transcriber%20and%20Editor%20for%205%20Minutes%20to%20Process%20Improvement%20Success

Download - 5 Minutes to Process Improvement Success

Top Related