• http://business901.com/wp-content/uploads/2013/07/Reality2.png

Managing Scrum of Scrums

Jon M. Quigley PMP CTFL has nearly twenty five years of product development experience, ranging from embedded hardware and software through Jon Quigleyverification and project management. He holds multiple degrees, seven patents, has authored and contributed to numerous books and magazine articles as well as teaching and speaker at technical schools, universities and conferences on a variety of business and product development topics. Jon is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. Several of Jon’s books are listed below:

Download MP3

Business901 iTunes Store

Mobile Version

Android APP

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Data: Your Nearest Neighbor is Nano-Seconds

Kim Robertson started his first company at the age of 18 and has an extensive background spanning forty years in all aspects of business and aerospace. He is the author of over 100 discipline specific training packages, 3 fiction books and articles for CM Trends and various other trade publications from industrial arts to Configuration Management. His latest collaboration Configuration Management: Theory, Practice, and Application is available for pre-order on Amazon.com. Configure ManagementContact Kim through LinkedIn or Kim.Robertsonatvaluetransformdotcom.

Kim is the guest on the Business901 podcast tomorrow.

Joe: A lot of people want to control their own data. They want control of it. They’re generating it, and can they have ownership. Is that ever really going to be feasible?

Kim:   It depends on how you define that thing that you’re trying to control. I’ll give you an example. I have intellectual property that I feel is mine which may be photographs of family; it may be the types of things that you would share with people on your Christmas card and that sort of thing. If you are putting that information on Facebook for example, I believe a clause is still in the Facebook use agreement that as soon as you post something, Facebook can use that information anyway they want to including sell it to somebody else. So once you do that and sign up for that agreement, you have lost control of your personal IP. When it comes to things like patented technologies and trademark type technologies, countries have different ways of looking at it. For example, some companies say, we don’t care who built this IC chip; we’ll give a patent to every new application for it. So if you originally built it for a cell phone and now all of a sudden somebody has it saying, oh we’ll use that same technology for your garage door opener so you can open your garage from your cell phone; that would be two patents.

Once we get to some sort of international standard for what that IP means worldwide, it’s going to be a lot easier to protect it. Right now, you’ll find it’s kind of anybody’s game but it has been for years. Back in antiquity, for example, intellectual property and data encryption took different forms. There is historical records of this fellow who wanted to get information about a city out to the people that were going to invade the city, and so he had some trusted servants and he shaved their heads and he tattooed the instructions on their heads, let their hard grow and sent them out. It was a very early form of IP security. In Sumner, they used to have little clay balls that they put tokens inside. In the token maybe here’s three measures of wheat, two measures of metal, and four measures of beer, and once those were put inside the clay ball and both people’s seals were put on it, that was a binding protected piece of IP until that clay ball was broken. You could say, oh okay, you’re Fred, you’ve worked for me a week, so you want me to pay you your metal and your wheat and your beer.

The idea, that all of this is new, is not true; it’s just become more critical as we reach the population densities that we have. It was much easier to control when your nearest neighbor was 20 miles away. Now that your nearest neighbor is nano-seconds away in the electronic world, it gets very hard to control. I don’t think we’re ever going to really get there. I think that we’re making great strides, but a lot of that is based on trust, and some of the problems we find is based upon different definitions of what IP really is. For example in the US, we say we patented this design wherever you use it. In Japan they say, we patented this usage of that design, whatever it is. So, of course, there’s going to be disconnects until we come to a common language.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Two steps to Changing Culture

Larry Rubrich of WCM Associates LLC wrote one of the most straight forward books on Hoshin Kanri that I have seen: Policy Deployment & Lean Implementation Planning: 10 Step Roadmap to Successful Policy Deployment Using Lean as a System. I had a past podcast on Lean Construction with him,  An Overview of Lean Construction and could not resist diving into a few Hoshin type questions.

An excerpt from the podcast:

Joe:  You talk again about changing culture. In any organization, it’s really tough. You just don’t wave a wand and change culture or make an edict that we’re changing culture today. Can you tell me how to do it, a short synopsis of it?

Larry: This is really a great question. The difficulty for most organizations, whether you’re talking about manufacturing, health care or construction and service, is nobody’s focused on culture. They let the culture develop on its own, unguided, and then they wonder why they have people in their organization with bad attitudes that don’t care about the organization. So ultimately, where you have to start with culture is you got to start with an understanding that organizational culture is a learned process and it’s developed by the organization in response to the working environment established by the organization’s leadership and management team. So what you have for culture is based on the reaction of everybody to the environment that’s been created by the leadership team.

So if you’re going to change that culture??and most organizations require culture change to support Lean??you have to do this in a couple steps. Ultimately, culture change takes a long time, but you can get it started by doing two things.

First, about the leadership team creating a values and behavioral expectation statement, a little pocket card that says, “This is how we will operate. These are our behavioral expectations, not only for the leadership team but for everybody in the organization.”

So creating these value statements and then, essentially, instituting them and enforcing them within the organization becomes a powerful part of getting that culture change. Obviously and ultimately, the leadership team has to be willing to follow those 100 percent.

So creating the values and behavioral expectations are the start of it. Now, for construction organizations, this can be a difficult flip because many construction organizations already have value statements. But they’re not being followed, and ultimately, they’re meaningless. So we have to re-institute them in some cases and give them some teeth.

When I say, “give them some teeth,” ultimately, for organizations that really change ??a reference: one organization, the leadership team agreed that you get two violations of the value statement, and you’re out of a job; you’re going to be terminated. So that can reinforce what needs to be done.

Once, you’ve created the values and behavioral expectations statements and we’ve got that within the organization, next you have to integrate the values and the Lean activities into associate performance evaluations, promotion opportunities, hiring, merit increases, bonus activity, and new?employee training. All have to be integrated with what you’re looking for from a Lean standpoint and your goals with Lean and also the value statements.

The first time in the organization that somebody gets promoted or rewarded and they’re not a 100?percent supporter of Lean activities, or they’re a violator of the value statement; your culture change is done. So those are very important activities to get started, and then all of that has to be followed up with communication, empowerment, and the teamwork part of creating a Lean culture.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Conversations in Project Planning

Alan Mossman of The Change Business trained as an architect and worked for many years in management and organization development. He only returned to construction in 2000 building on his knowledge and understanding of collaboration, systems thinking, quality and lean. I asked Alan about the promised conversation cycle.

Related Podcast and transcription: A Lean Project Planner

Joe: One of the things that you mentioned in a very good PDF that you put out. I think it’s called “The Last Planner: Collaborative Short Term Production Planning,” is the promise conversation cycle. Can you explain to the audience what that is?

Alan: Think of a customer and a provider, or a potential provider. The customer makes a request to the potential provider. That request, in a well-run system, will initiate a conversation, a negotiation about the conditions of satisfaction of that request and the date by which those conditions of satisfaction ought to be met. As part of that conversation, the provider may need to go and talk to other suppliers of their own and have a similar conversation to this conversation that we are talking about.

If I’m the provider, I might need to go to my material’s supplier and say, “Can you supply?” Make a request and the material’s supplier then wants to clarify conditions of satisfaction, the delivery date and so on.

We get to a point where one of the three useful things can happen. The first is that I as a provider say, “Yes, I can do that.” The second is that I can say, “Yes; I can do that, provided you let me have the specification or the drawings or whatever it is that you want me to work with by this date.” There’s “yes,” “yes, if.”

The other useful response is “No; I can’t do it.” Because that’s a very clear signal to the customer that they’ve either got to change the deadline, they’ve got to change the conditions of satisfaction, or they’ve got to find somebody else who can do it. I’ve got early warning as a customer that something needs to shift.

But, let’s suppose I said, “Yes.” I then go ahead with production. I’ve made a promise, and now I set out to fulfill that promise. Once I’ve delivered on the promise, it’s important that I declare completion. When I’ve declared completion, it is a signal to the customer to show him or her that I have done what they wanted done. Hopefully, at the end of that process they will declare satisfaction.

Now, this promise cycle is completed entirely in language. There is a request, there is the negotiation, there is a promise, there is a declaration of completion, and a declaration of satisfaction or dissatisfaction as appropriate.

What is missing, in my view, in a lot of construction, is that because of the critical path method, there is not enough time spent on managing promises, managing commitments. It’s all coming from directives. You will do this. You will do that. So that the project manager is telling people what to do rather than ensuring that the people on the project understand what needs to be done, so that they are in a position to make offers and to make promises about what they will do.

The collaborative planning, collaborative programming, make ready, are foundations for Last Planners to make promises about the work that they will do next week, because they’ve got direct involvement in preparing the work to be done.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Making a Kaizen Event Sustainable

Mark R. Hamel has played a transformative role in lean implementations across a broad range of industries including aerospace and defense, automotive, building products, business services, chemical, durable goods, electronics, insurance, healthcare and transportation services. Mark has successfully coached lean leaders and associates at both the strategic and tactical level. A National Shingo Prize examiner, Mark assisted in the development of the Society of Manufacturing Engineers (SME)/Association for Manufacturing Excellence (AME)/Shingo Lean Certification exam questions. Mark is the author of the SME published, Kaizen Event Fieldbook: Foundation, Framework, and Standard Work for Effective Events and blogs about Lean at Gemba Tales.

In this Podcast (Complete Transcription and podcast: Kaizen to Standard Work) Mark gives some great tips on moving from Kaizen to Standard Work.

Joe:  Well you mentioned one thing, and I am always inquisitive about this because seems to be that every time I read a book it always tells me how I am supposed to do the preplan, what I am supposed to do, what I am supposed to do during the event. Then you get to the sustainability part of it, and that’s the shortest chapter in the book and it’s over with but that’s the toughest thing to do.

The question I have is: “What are some of the key things that you need to do to make a Kaizen event sustain?”

Mark:  Good, good question! So within the event, when you’re in the execution phase, certainly by the latter portions of the event ? and we know it is a plan, do, check, act, type of approach ? but as we come up into taking our improvement ideas and developing the post?Kaizen situation, we need to validate that new standard of work within the events. So if you are doing an industrial application, often times it is pretty easy depending upon the cycle times to actually implement, apply the standard work, train people, and run the line, the cell, whatever, for multiple shifts. And in doing that plan, do, check, act, make the adjustments and fine tune that standard work so that we can leave the Kaizen event knowing that it works and that it is explicit and that it is properly documented, as well, on the standard worksheets, and standard work combination sheets, and that type of stuff.

In a transactional environment, the format might be a little bit different if you are dealing with really long lead times. For example, like a bodily injury claims process, you might end up doing tabletop simulations but you definitely want to test it and keep adjusting it.

Another big thing is obviously communicating and training the folks in the new way. Then on the follow upside, you can’t just introduce it and let it flop there. So this is where the lean leaders really need to come into play to make sure that there is process assurance with the new standard work, and also checking process performance.

We can do that through a number of different ways, primarily the lean management system, which is comprised of the leader’s standard work. So actually physically going somewhere and observing reality, hopefully, aided by good visual controls to tell if they’re getting a normal condition or an abnormal condition, to know whether or not there is process assurance.

And also, from a daily accountability perspective, “Am I getting the performance?” whether it is a plan versus actual chart or whatever to give you that feedback, and then to respond to that.

So you end up going from really a plan, do, check, act situation to a standardized do, check, act, where I’m checking the standards to make sure that they are being applied, to make sure that they are sufficient and if they’re not then I make adjustments to those. The rubber really meets the road; people happily get into lean implementation. The rubber meets the road often when it’s like, “OK we got some new standard work and this is in many ways a test of whether or not people are going to live and apply standard work.”

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

When Do You Use Scrum Versus Waterfall

Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management. He holds multiple degrees, seven patents, has authored and contributed to numerous books and magazine articles as well as teaching and speaker at technical schools, universities and conferences on a variety of business and product development topics. Jon is my podcast guest tomorrow and below is an excerpt from the podcast.

Joe Dager:   When would you recommend that type of — when you use Scrum versus let’s say a Waterfall, is there a good rule of thumb where one fits? Not everything should be done in Scrum, should it?

Jon Q:   I think you’re right there. I would say definitely not everything is Scrum, just like definitely not everything is Waterfall. And it kind of irks me sometimes when I read that on blogs or hear people say that Scrum is the bomb or the thing to replace Waterfall. It’s not true, no more than Waterfall could replace Agile. There are certain attributes of your organization and your project that tell you whether you should use Agile or conventional. For example, if I’m working an automotive project that has a lot of tie-ins with heavy capital and manufacturing, distributed all over the world and regulations, I probably would consider that I might consider using a Waterfall approach. The logistics around that are kind of high, the regulations on those are very specific, and proof of conformance to those regulations are very specific, and if something goes wrong, you’re going to have to have some track record to traceability, and that might be a little difficult to come by in an Agile incarnation. If you have a team that’s a bunch of experts, they’re very seasoned that’s probably a good time to have an Agile project.

Joe:   So you’re saying that Waterfall would provide more structure of things for the inexperienced team, can I take that out of that or –?

Jon Q:   Yes, that’s one of the things you could take out of that and then the other would be the fact that it’s so structured gives you in theory a traceability and so at the end of the day, if the government came to call on you because your product may have harmed somebody, you have some track record or some traceability that you may not quite have that level of detail if you’re doing Agile. By definition, you forego detailed documentation.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

What’s the Limitations to Dialogue Mapping?

In last week’s podcast (Podcast and transcription: Shared Understanding with Dialogue Mapping) , I asked KC Burgess Yakemovic of Cognexus Group that question:

Joe:   One of the things that challenges me when I’m looking at it is that I’m not sure let’s say how often I would use it or what’s the limitations to Dialogue Mapping. Is it easier to explain when to use it or is it easier to explain when you don’t use it?

KC: You know that’s a good question. There are aspects of Dialogue Mapping and again, this is one of the benefits of having this sort of the step-by-step process to get up to the point of doing Dialogue Mapping. Because formal Dialogue Mapping used in its entirety, the places where the benefits exceed the work, that goes into it, are fairly limited. If you’re a professional facilitator, you may use it a lot more frequently. If you’re working in a business environment, there are aspects of Dialogue Mapping such as the capture of information during a meeting that can be used without being the person doing the facilitation and those skills can be used very, very frequently.

I have some corporate clients who have trained a number of their staff members just to the level of doing the capture and not to actually doing the facilitation piece. They train a limited number of people to do facilitation because they’re not just going to have a large number of meetings where the benefit of the facilitation aspect is sufficient. One of the places that it does come into play very nicely is anytime you’re doing strategic planning, where you have a number of different positions, people have different things they are trying to accomplish and you want to get all of that information out and make sure that the plan that you’re proposing covers as wide a variety of things as possible; complex, complicated things. I’ve used this method in the software design area a lot to deal with problems that keep recurring. You’ll be doing a piece of design, you think you’ve got an answer to how this is going to work, you get out and get started on it and discover, wait that breaks something else over here. And now you go and try to fix that problem and wait now that broke something else.

There was one situation that we actually wrote up in a paper that it turned out there were six interconnected questions that all had to be answered simultaneously to develop a solution that would really work. We would not have noticed this if we had not been capturing our information in an IBIS structure and realized these questions kept not getting — the answers to the questions kept shifting. We took those six questions, put them out in a room at the same time with all of the people involved in the design and when we saw all of these questions together and the answers we proposed, we realized that we didn’t have the right solution, but we were then able to clearly define a solution that solved all six problems simultaneously.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)