project management

Implementing Change Using Kanban- Part IX

Team Kanban

Ultimately, Kanban is about people. Its not about me and my cool board. These are the good folks who helped me with the project and used the board. THANK YOU!

This is the last install for the Kanban board. The project has ended. Lessons learned have been gathered. A new project has begun with its own board.

Recent Comments

  • “Have you seen his board? You have GOT to see his board.” ~ One of our PMs to our visiting PMO managers.
  • “I love coming over here. It inspires me.”~ One of our PMs referring to our board.
  • “You must fear the cleaning crew.”~ One of our PMO managers after seeing the board.
  • “This is one of the most innovative things we are doing here.”~ One of our employees showing the board to visiting students.
  • “I was skeptical about using the board and the post-it notes, but it worked out pretty well.” ~ One of our team members during Lessons Learned.

Observations

  • I’ve gotten better at explaining the board to people. My go to explanations:
    • “It allows me to sleep at night.”
    • “It leverages the concept that the project is a system and this is a visual representation of it.”
    • “It allows me to easily identify bottlenecks and recognize areas of concern.”
    • “It leverages psychology in that human beings are visual creatures and we process visuals or patterns quicker than text.”
  • I suspect people know I’m busy because they can see the board. Another project manager made this same observation recently. People don’t have to ask if I’m busy. They can SEE I’m busy.
  • Board discipline can be difficult—especially when you are getting overwhelmed with so many demands. I have to be careful not to let it get behind.
  • We had a situation where the board and a spreadsheet were not in line. While neither were exactly correct, the board was more accurate. In some ways, this didn’t surprise me, I’ve noticed the board is often more accurate than any spreadsheet. I’ve often said, “the board knows all.”
  • Our process can be extremely complex. I would need an entire room to create “In Progress” and “Done” columns. I’ve had to consolidate some of these.
  • The board seems to have become a part of the IT department. It doesn’t get the skepticism it once did. People have come to accept it for what it is and understand that it works. Its not a fad.
  • All in all, I would guess 10% of the people think the board is cool, 10% don’t like it, and the remainder are somewhere in between.

Lessons Learned

  • Sometimes your work can take a different path than the one you have created on the board. This can be frustrating. This is usually due to variation and complexity built into the overall system. You have to learn to roll with these, get creative, and adjust.
  • ALWAYS include the team. When I finished the project, I took a picture of just me with the board. Wrong move. Maybe I worked on it the most. Maybe I championed it the most. Maybe most people didn’t quite get it. But we all used it. I took a picture of all involved later and posted it on our company Yammer page. I was told they appreciated it. I should have had them help me take down the post-its and the board. Opportunity lost.
  • You never know how your work can influence others. The team that assisted me is now using their own visual management board. I was more than happy to help them come up with something. I must keep doing this.
  • Share the wall. I want the team next to me to enjoy the “easier-to-sleep-at-night” feeling when using a visual management tool. That means I will gladly surrender some of the wall (they get half!). I’ve started using OneNote to track things where I don’t have enough wall space. I just put on the wall what management wants to see.
BAU Wall

The team that helped me has started their own visual management system. I love this picture. To see Patty taking so much joy in her work and knowing it helps her better understand her workload might be the project’s biggest accomplishment. I’ll ALWAYS be there for you guys!

Experiments

One experiment is posting on the company’s Yammer page. I’ve been inviting people to share in the experience of using Lean and Kanban concepts. I’m going to sneak Deming in there as well. I have one follower so far. Heh.

WIP Limits

Toward the end of the project I was getting more into experimenting with WIP limits.

My biggest experiment was limiting WIP. It got to the point late in the project where I was pretty much the only one working on the project, so I didn’t have to struggle convincing people to limit their WIP. I just did it. I also realized there was much I didn’t realize about why it was important limiting WIP. Things I learned:

  • Dependencies is a huge problem. In one instance, I have a WIP limit of two. Its full. However, I’m waiting on a dependency before I can move both of them forward. This is very common.
  • Because I am waiting, my instinct is to take on more. But what happens is I soon have so much in progress I can’t remember what all I was working on and the problems of context switching sets in. It takes discipline to limit WIP. Fortunately I didn’t have any outside pressure to increase it otherwise I would have.
  • When I find myself waiting, I go work on something else—for instance—that 30 minute side project someone asked me to complete two weeks ago—I can go work on that now.
  • WIP can mysteriously increase. For instance, I had a team member tell me something they were working on needed my help. Suddenly, my WIP increased by one. About an hour later, something we thought was fixed wasn’t fixed at all. It came back. My WIP increased again. This is a challenge and I’m still figuring out how to handle this.
  • I’ve been increasing and decreasing WIP limits. Because of the external dependencies, you have to try to find a balance. Because of variation, these can shrink and expand regularly. I don’t think one should ever set their WIP limits in stone (unless their system has little variation).
  • I now understand the importance of limiting WIP. Its really quite simple and what I was told in the first place—it reduces context switching. If you reduce context switching, you get more speed. This is a hard concept for folks to grasp. Even me.
  • The tendency to start something else without finishing another is very strong. Especially when you have a line of people wanting something from you now. The problem is, you are actually making them wait longer by starting them early. It might make them feel better that you have started them, but ultimately, you will frustrate them because they have to wait a long time and they will begin to wonder, “WHY DOES IT TAKE SO LONG?” Best tell them to wait. They will be better off for it. This takes tremendous courage and discipline.
The Last Pic

The board just before I took it down. Post its to the right! All done! Pinks are external dependencies. Those still in progress go to the next project.

Links to the rest of this series:
Part I
Part II
Part III
Part IV
Part V
Part VI
Part VII
Part VIII

Implementing Change Using Kanban- Part VI

20170118_191033

Our board. Note the graphs to the left indicating trends. I’ll post about those soon.

Here are some recent goings-ons with the Kanban board.

I’ve told this to others in my organization and I’ll continue to say it, this board is central to the project’s organization and understanding. It saves my bacon daily–simply because I know what the heck is going on. I highly recommend one.

Just to remind my readers—my organization does not embrace Kanban, Agile, or any type of improvement methodology or philosophy. This series documents the challenges, failures, and triumphs of trying something different.

  • There are many who still just don’t get it. I still get teased:
    • “Watch out! Don’t knock off any post-it notes!” as a group of people walk by.
    • “What if someone just comes along and . . .”  Person moves post-it note to elsewhere on the board (actually, I can figure out where its supposed to go just by looking at it).
    • “What if there is a fire?” often said with a smirk. (“Everyone grab a post-it note!”
    • Of these comments, I know some of its just good ribbing and some its genuine disbelief. Regardless, this is something I’ve learned just comes with the territory. For the most part, I feel people have come to respect what I do even if they don’t quite get it.
  • The series was featured on the Deming Institute! One of my team members, who had lived in Japan, immediately understood the significance of this. “Everyone has GOT to know about this!” he said. This is about as far as the excitement went, though. I told my supervisor, and he seemed to think it was cool, but didn’t say much about it. When I told our PMO lead, he asked, “Whose Deming?” After I explained, another colleague laughed and said, “It sounds like a cult.” This sucked some of the wind out of my sails.
  • Team members are starting to interact with the board after some encouragement. I’ll be at my desk and here the pop and soft rattle of a post-it note moving on the board from behind me. Its a good sound—the board removes me as a bottle neck. The board is showing the team what needs to be worked on without me telling them!
  • One of our team members, a former navy man, compared the board to boards they use in the navy to monitor ships that are all over the world. He said he likes the board.
  • I’ve said this before and will say it again—it would be better if all those who use the board were right next to it. Those who are at my location work in another room. They have to get up, walk out of their room, down a hall, and in to my area to see what is going on. Up to a hundred feet. I can understand why they might think the board is a pain. I also think this causes the board not to always get updated like it should.
  • Related– it would be better if all our remote partners could see it. I believe one of our partners suffer from cumbersome internal processes and systems and I think our board could give them some clarity. There are things I regularly see that I have to keep bringing to their attention, but if they could see it themselves, they wouldn’t need me to point it out. Ideally, the board would be electronic so all remote team members can see it, but also retain its current size so those in its presence can read it and discuss it.
  • We’ve had new people come on board to help me with the project. I asked them to use the board. There was some resistance to it, including from their manager, at first. This company is used to working in spreadsheets (which I’m seeing more and more of the problems of). One member openly said, “I’m not going to use this.” I think she was intimidated by it, but once I told her why it was important to the project and I showed how it worked and told her not to worry about all the nuances, she chilled.
  • One of the new team members seems to really like the idea. I think he may become a champion of convincing others of the board’s merits. I think a board like this would help them with their own work. I’m wondering if he is starting to see this.
  • The new people have been taking the post-it notes back to their desks. I allowed this because they needed the information on the notes to complete their work. The negative– sometimes I’m looking for a site and can’t find it. I’ve started wondering if this was a good idea. I’m worried the post its will get lost. This again drives home the point that it would be better if we were all in the same location.
  • While everyone knows I’m very aware of what is going on with the project, they are not happy with the results they are seeing (the project has been behind schedule since the first week). This make me concerned that people will conclude that a board like this does not help get a better result. My argument—what type of predicament would we be in without it?
  • Its official. We are moving to a new location and there seems to be some disagreement on if there is room for the board. My supervisor and teammate think so, but others have told me there won’t be any room. I wonder sometimes if I am going to be made to conform. I wonder if anyone has any idea how important this board is to understanding a very complex project and how its central to the project’s organization. Of course, if it can be accommodated–all who currently use the board will be in the same location and that would be very, very good. We’ll see what happens!
  • Someone told me that one of the manager’s admired the fact that I did what I believed to be right despite strong pressure not to. He said we needed more people to do that. I believe they were referring to the board.
  • As I study Lean, I’ve come to the conclusion that the board actually duplicates effort which is wasteful. I have to write information from an e-mail or spreadsheet onto the post-it note. This is the downside. The upside, it puts the information in a form where I am able to synthesize it. I am unable to do this when its in its original form. I wonder if there is a way to get both worlds?
20170112_193705

See the column on the far right? That’s how many we have actually completed! Conclusion- we have plenty of starting and not enough finishing. See those blue notes? Those are things we have to revisit. That’s a lot of rework and only adds to the WIP. I’m not certain how to convince others that this is an issue.

  • This company does not believe in (or understand the importance of) limiting work limits and finishing before you start something else. As a result, the board is getting cluttered with tons of post-its and its getting harder to find specific posts its. There has also been times where I have duplicated a note.
  • During my last post on this series, I wished our partner would start sending over smaller batches at more frequent intervals so we could create flow. I was able to convince them to do that. However, we are still not getting the results we want from them. Because I don’t have a clear insight into our partner’s processes, I’m unable to understand where the bottlenecks are and where to help fix them. Management is getting frustrated. We asked the partner to double their batch size, but because still don’t see good results, leadership has insisted they do them all at once. So much for the concept of flow. . .
  • Because management has asked for everything to be released at once, I predict our board is going to get very crowded and our WIP is going to explode. I wonder sometimes if the board will be any of any use at that point. I might be spending all my time just updating it and that’s not going to help us get any work done. That could just be the fear talking, though. Who knows?

What I wish for

  • I wish management would visit our area more often to understand what is going on and help us solve our issues. The board (and all the charts I display) is just as much for them as it is for our people. They don’t come by, though, and we usually only talk during reporting meetings (which often results in their frustration). Without management being able to ‘see’ what is happening they have to revert to my interpretations. They aren’t getting the results, though, and as discussed, they are very much getting more and more frustrated.
  • I wish there was some way (technologically) for everyone involved in the project to see this board without us losing its size and “physicallness” it currently has. Even if I were to create this board in OneNote (which would be a large undertaking) so everyone could see it, I’m not certain everyone would use it and I would lose the benefits its currently giving the project. This is a risk I’m not willing to take.
  • I wished people at my company would read my blog. Maybe I’ll get ballsy and send my blog to our IT director. Hmmm . . .

Links to the rest of this series:
Part I
Part II
Part III
Part IV
Part V
Part VI

Making Promises We Can’t Keep

promisesAt my last company, our team was  behind in our work (we had been since I first arrived there). What was left was overwhelming and would require an enormous effort, sacrifice, and possibly working ourselves to the point of exhaustion to get it completed (people were already getting sick or leaving the team).

I told one of the managers we needed to reduce our scope. The reply was the scope had always been what it was and would not change. When I protested, I was told quite flatly– “We promised our customer this and we honor our commitments here.”

This stung. It made me feel like if we didn’t follow through, we would be dishonored by breaking a promise and lose the trust of our customer.

But wait one damn moment.

“Hold on,” I said. “I didn’t promise this and neither did the team, our executives did. Our team was not consulted on if they would be able to do deliver all of this in the time allocated.”

I was told if I didn’t like it I could talk to the execs about it.

For the rest of my time at the company, I’d hear off and on about execs making promises or commitments to our customer and then hear about those expected to deliver being unable to make good on the promise. The execs couldn’t understand why we were always behind or why the quality was poor. “We’re going to lose our contract!” they would say.

So they came down on us. We were told to work harder and were often made to feel like pussies if we couldn’t keep up. I remember one exec prowling the room, looking intimidating, and criticizing us for having the audacity to laugh during a critical time. Fingers were quick to point. Overtime became common (though we remained behind). Burnout, frustration, and people quitting often followed.

One project manager told me this was just our lot in life. The execs promise and we have to figure out how to produce. Really? Does this really have to be the way it works?

This happens not just with our own companies but also our partners and suppliers. I recently had our director tell me that because one of our suppliers is unable to keep up with our demand like they had promised, we would go with a different supplier. I asked how we would know if this new supplier would keep up with the demand? He said they would if we gave them the proper incentive. I replied, didn’t we offer the same incentive to the current supplier? How do we know we won’t just get the same result or perhaps something worse?

 

patton

American mythos on accepting a challenge. Is something wrong with you if you don’t accept? Many would say yes. Are they right? Is this mentality one reason we continue to fail and destroy trust?

So why are we making promises we can’t keep? I can think of a variety of reasons. Some will make all kinds of promises if offered enough money or incentives (is this a form of prostitution?). Also, its part of our mythos–Americans simply don’t back down from a challenge. We just roll up our sleeves and get to work no matter how big the obstacle. Perhaps the decision makers are just ignorant or overconfident in what their organization is possible of producing. Its also possible the folks making the promise have the skill, knowledge, and wherewithal to do it themselves, but forget they are surrounded by mere mortals or forget they haven’t given their people the resources or skills or knowledge to complete the task. Much of it could be fear related–we don’t want to look like pussies in front of our superiors or peers or we are afraid of losing business or losing our jobs by saying no. Perhaps its a combination of all or any of the above. Regardless, this greed, arrogance, bravado, ignorance, fear, and lack of candor is destroying our trust with both our employees and our customers. Something must be done.

But what?

Two things–data and character.

We must be keenly aware of our capabilities. What does the data say? Have we done something like this before? How did we do? What does our current quality look like? What are our lead times? What rate of quantity can we produce? What is our defect total? Is it reducing? Are we making every effort to reduce variation? Are we committed to improvement and do we make good on that promise? What does the team who will be performing the work think? Have they been given the opportunity to speak candidly on their ability to produce? We have to ask this of ourselves but also of our partners and suppliers as well.

 

just-say-no

Be like Nancy!

Once we know this, we can better evaluate our customer’s needs and rely on our character to give a solid yes or no. Only the wise and honest will know when to say yes. It will also require courage when its time to say no.

If we currently don’t have any influence at the management level for these types of decisions, we can at least practice our own ability to say no within our sphere of influence. If you haven’t the capability to make good on a promise, have the courage to say, “NO.” Perhaps you will start a new trend in your organization and begin a much needed revolution.

BOOK REVIEW: Out of the Crisis

out-of-the-crisis-by-w-edwards-demingDAN’S SCORE: Stars 3.5
Out of the Crisis
by W. Edwards Deming


Agh. I hate giving my hero’s book 3.5 stars, but let me explain.

This is Deming’s first book published on his management philosophy (1982). I understand, of the two books he wrote on the subject (the other being The New Economics), this one is the most difficult to read. My feeling is Dr. Deming wasn’t used to writing toward the management audience (his previous books were geared toward statisticians) and was so darn brilliant he didn’t know how to ‘dumb’ down his message yet.

I was able to understand about 66% of it. However, I got lost when he delved into statistical analysis and when he gave examples from manufacturing. His style is also a little unusual: a mixture of dryness with flashes of absolute brilliance. Still, I can see why many people would just put the book down or not even bother. They would think its too hard or it doesn’t apply to their line of work. It might be a reason why many just don’t get the Deming message.

Don’t get me wrong. I got a lot out of this book and I did enjoy it. Here are some of the big take aways:

The report on Japanese Automotive Stamping was a very interesting read. It was cool to see what the Japanese manufacturer thought was important to their company (cleanliness, obsession with quality control, importance of training, belief that people are their most important asset, visual communication, etc.)

I enjoyed reading about Deming’s thoughts on goals, focusing on specifications vs. reducing variation, what an incoming manager must do (he must learn), how management tries to implement techniques instead of focusing on improving people, the concept of an immediate customer and an ultimate customer, the importance of learning from a master (and not a hack), why a customer may not have valuable feedback on a product until after using it for a long time (for example, an automobile), how some specifications are beyond the capability of a process (I started using this phrase), the importance of finding vendors and partners committed to continuous improvement, his emphasis on training, his warning against learning something solely by reading a book, and how its natural for people in a company to be suspicious of outsiders telling them how to improve their work (yet he stresses the importance of having outside help).

He introduced me to some new quotes from himself and others. One of my favorites was this one: “They will have courage to break with tradition, even to the point of exile among their peers.” I’ve felt this a lot since my Agile ‘conversion.’

Some of his points hurt. It made me realize how far I have to go. For example:

“Today, 19 foremen out of 20 were never on the job they supervise. . . They can not train them nor help them [their staff] as the job is as new to the foreman as it is to his people . . . He does not understand the problem, and could get nothing done about it if he did.” Ouch. I’m one of those foremen.

He bemoans the fact that the educational system is putting out math ignoramuses. I’m sure Deming would think this would apply to me. I’ve always found Math difficult. I actually have a fear of it.

I was surprised to hear him say that teamwork isn’t always the answer for achievement. He said there are some who are fine doing work by themselves, contribute to the organization, and should be supported. With agile being so team oriented, this idea made me think.

Something he said didn’t sound right: “A pupil once taught cannot be reconstructed.” Is he saying that once a person is taught how to do something, they are stuck doing it that way forever? I’m not certain I agree.

One of the things he talks about is how quality control circles must have management involvement and will eventually fail if they don’t. It made me think about retrospectives in scrum. By rule, management is not to come to these. The thought is that the team will not be open with each other if management is there and management will tell the team what they did wrong or fault the team for what they believe needs to be fixed. However during most of the retrospectives I’ve participated in, the team discussed things that were beyond their control and what frustrated them the most—i.e. things only management could fix! I think, ideally, a retrospective SHOULD have management involvement and would greatly benefit the team and the organization. HOWEVER– in order to reach this ideal state, a great deal of trust must exist between manager and employees. Fear must be completely driven out so the team feels comfortable speaking up. Management would also have to have a great deal of humility to listen to the lowly workers. Admittedly, this would have to be a very mature agile model for this to happen, but I think the agile community needs to promote this line of thinking.

Although, I learned a lot, I would not recommend this book for someone who is new to Deming. I’d recommend The Essential Deming, The Deming Dimension, or Fourth Generation Management instead. However, I think this is essential reading for any Deming disciple. Just wait a little while in your understanding before you pick it up.

Out of the Crisis can be bought here.

BOOK REVIEW- Winning

jack-welch-winningDAN’S SCORE: Stars 4
Winning
by Jack Welsh


My wife, god love her, rolled her eyes after hearing me going on and on about the virtues of Agile and Deming-style management for the millionth time.

A manager herself (and often my sparring partner over the best way to manage), she was growing tired of my pontification. “You know,” she said with a frown, “there’s other management styles out there.”

I decided to take her up on this and look at a contrary style.

Another reason I selected this book is because one of my fellow employees, after eyeballing the library on my desk, told me, “I’d prefer to take advice from people who have actually ran a business.”

Ouch.

So, I selected Jack Welsh’s book, Winning. Welsh is probably one of the biggest influences on management in the last decade. Warren Buffest said Winning was the only management book that was needed. It’s hard to argue with Welsh’s advice. After all, he grew GE by 4000% during his stay as GE’s CEO and made it the largest company in the world.

I’ll admit, this book rattled my confidence. Welsh’s ideas would certainly better resonate with the circles I’ve worked in than any of the Agile exhortations I’ve spouted. Many would say his management style is superior because the proof is in the pudding, and despite Deming’s belief that there is no instant pudding, Welsh has a hell of a lot pudding. It’s hard to argue against.

Overall it was an interesting read and I learned a lot.

At first, I was calling Welsh the anti-Deming. But as it turns out, Deming and Agile have a lot in common with Welsh. Here are some of the thing I saw:

Welsh

Deming/Agile

“There is no easy formula (for success).” “There is no such thing as instant pudding. (i.e. no recipe for success).”~Deming
“Variation is evil and must be destroyed.” Welsh is a huge supporter of Six Sigma. “If I had to reduce my message for management to just a few words, I’d say it all had to do with reducing variation.” ~Deming
You must develop a culture of trust in order to develop a culture of candor. Trust is important in both Agile and Deming philosophy. Deming often talks about the importance of driving out fear.
Believes an organization must have a culture of learning. PDSA, an appreciation for knowledge, kaizen and retrospectives are at the heart of Agile and Deming philosophy.
Believe culture is very important. It’s just as important as strategy. Also believe culture is important and the key for successful change or the biggest obstacle for change. “Culture eats strategy for breakfast.”
Change is important. Also embraces change.
“Don’t get the mentality of ship it then fix it.” Build quality into the product the first go around.
Does not like quotas. He said it ruins a meritocracy. Also hate quotas.
Believes management must change in order to succeed. Interesting enough, he brought up the post war Japanese miracle as an example (though did not mention Deming). “It would be a mistake to export American management to a friendly country.” ~Deming
Doesn’t like the concept of the boss needs to knows it all. There needs to be a culture of employees coming forward with opinions and ideas and the boss needs to listen. Every voice needs to be heard and everyone needs to feel like they can come forward and speak their minds. Hate command and control. Absolutely hate it.
People are important. So important he believes the HR director should at least be equal to the CFO. Lots of focus on understanding people and what motivates them. Respect for people underlies Agile concepts and is core to Deming’s teachings.

That being said, there are some key differences:

Welsh

Deming/Agile

Differentiation or 20-70-10 or ‘Rank and Yank’ is critical to his philosophy of success. He says it creates a meritocracy and is fair for everyone. Welsh admits this is the most controversial of his philosophies. Deming hated ranking. He called it a destroyer of people. Ironically, this was also the most controversial of his philosophies.
Emphasis on the individual and heroic effort. He believes stars are critical to success. He talks about undaunted individual effort a lot and chalks it up to much of GE’s success over the years. Both agile and Deming emphasize teamwork over heroes. Jeff Sutherland said if you need heroics it’s a sign of poor planning.
Results is the best indicator of success. Deming said beware of management by results (MBR) or management by objective (MBO).
Does not mention the importance of a system. Systems are key in both Deming and agile thinking.
Rely on leaders who have a sixth sense—i.e. “the ability to see around corners,” trust their gut, are intuitive, have an uncanny ability to see things others do not, people who just have a ‘knack,’ people with natural abilities (i.e. its something that can’t be trained) Emphasis on science to bring about improvement (PDSA, understanding of psychology).

I enjoyed reading this book and would recommend it to Agile and Deming practitioners. It gave me better perspective on what I think most people in the U.S. would prefer as a management style. Perhaps there is something there we can leverage to instigate change? After all, looking at the two philosophies, there are plenty of similarities. Perhaps we can build from there? I’m certainly going to borrow some of his ideas such as the importance of creating an organization that can be candid with one another.

I’m going to continue to study contrary points of view and post what I found on my blog. After all, Taichi Ohno told us, “We are doomed to failure without a daily destruction of our various preconceptions.”

You can buy Winning here.

Implementing Change Using Kanban- Part IV

Here’s some latest happenings on my wall charts. The last post is here.

  • The head of our IT department came by my cubicle the other week. My boards attract his attention whenever he’s in the area. We started discussing what was going on with the project. He could see from the board that sites were starting to move through the process which made him glad. He could plainly see the blocks. He was able to help me get rid of six. He seemed a little perturbed we hadn’t figured out how to get rid of them ourselves, though. He then looked at the burn down chart next to the board, pointed at the WIP which was still way above the sloping diagonal line and said he wanted the WIP on the line the next time I gave my report. That was unnerving. All I could say was I wanted it on the line too. Maybe he isn’t pleased how things are progressing, but I hope he appreciates the transparency I am trying to show. Its something he once said he wanted from the project managers. I actually wished he would come by more often so we could have more discussions. At the same time, if he did, I can’t help wonder if he will only blame me for not getting more work done.
  • My other team member gave input on how the board could be better changed– showing the sites that have been queued the longest from top to bottom. He also has becoming by more frequently to look what needs to be done. I wish he sat closer to me so he could have more easy access to it. I think it would help. The problem is, my project is just one of three or four others he has to work on and my supervisor who sits in the next room over, prefers my team member to be closer to him, also, I don’t sit with the rest of my department (which is sort of good, because there is no wall space there).

 

img_1076

My teammate’s contribution to improving the board. He wanted to identify how long our sites had been in provisioning.  Note the burn down to the left.

 

  • One day, this same team member came by to look at the board. I heard one of the other employees chiding him about getting into the whole post-it note thing. My team member replied that the board actually had its merits.
  • I had someone ask me how to make a Kanban board so they could use it for their own purposes.  I had to cram what I could in a 30 minute session because his time was limited. He’s used similar boards in the past but hadn’t thought of putting in ‘Done’ columns. I also explained to him the importance of limiting WIP but I’m not certain he understood. Since I went over with him how to make the board (a few weeks now), I’ve seen his board still lying on the ground next to his cubicle. He said he’s been busy. Whenever he comes by he still marvels at my board. Wish I could do more to help him.
  • This same person I helped said that one of these board would help one of the other teams. I had the same thought because what they do is similar to what I do. I know their manager has seen my boards, but she is one of the folks who doesn’t understand why I just don’t use a spreadsheet. Her team would have to want a board like this, and they haven’t shown much interest, and I’m not certain how supportive she would be.
  • There’s some talk of moving the department and there is a concern there won’t be any wall space for my board. I’m not sure what I’ll do in that situation. I could go electronic, but the board will lose a lot if its power if I do that. Its size and location is much of its strength. It will be more difficult to have conversations about it if its tucked away on my computer. It will also make it more difficult to read. Of course, since I’ve been here, there has been talk of moving and it hasn’t happened.
  • I had another project manager come by to view my boards. She really liked them and I could see the wheels turning on how she could create her own. It reinforces the idea that I need to make time to teach how these work. This same project manager said my ideas would find more acceptance and traction in her department than in mine. Maybe.
  • The board is getting more and more crowded with work. Its starting to look like a parking lot. My company does not understand or appreciate the concept of limiting WIP or flow. I’m thinking of ways to rearrange the board that will highlight where items are queuing. My concern is this will only cause people to get upset that we aren’t doing our work. We’ll see. Perhaps it will start more conversations about how having too much WIP is slowing us down.

The next post in this series is here.

Links to the rest of this series:
Part I
Part II
Part III
Part IV
Part V

BOOK REVIEW- Fourth Generation Management

4th-generationDAN’S SCORE: Stars 4
Fourth Generation Management: The New Business Conciousness
by Brian Joiner


This book appears often in the Deming circles and has been described as the best synthesis of Deming’s philosophy. I’d call it a good nuts and bolts book for those wanting to implement Deming’s principles in their organization. One of the reasons I got it was to better understand variation. This is the area of Deming’s message where I still struggle. Joiner’s explanation helped.

Takeaways:

  • One of the problems I’ve had with variation is that whenever I plot data, the level of variation is unacceptable or the results aren’t within the limits I want. He explained this is a common reaction. Glad it wasn’t just me.
  • He explained the strategies on how to deal with special and common causes. I’ll have to review these. He had some examples to see if the reader understood the differences and I kept getting them wrong.
  • He explained how to identify common causes and special causes without using a graph. This is something I’ve been trying to do in my own work now. Some things are difficult or can’t be graphed.
  • His story of the non-profit organization that had to work really hard and use brute force during its first year of existence but refined itself every year instead of continuing to rely on brute force really struck home. He explained some organizations never learn this lesson. Some just keep doing the same thing over and over because they like the adrenaline rush. I’d also might add that they believe this is what it takes to be successful. It reminds me of my last organization.
  • He said three system-wide measures that seemed to help organizations was overall customer satisfaction, total cycle time, and first pass quality. I had started to draw this same conclusion and this reinforced my belief. I’ll be using these to measure my own projects.
  • He lost me a little bit when he started talking about the importance of standardization. He may have hit the nail on the head when he said that many view implementing standards as adding red tape, stifling creativity, and made work boring. That’s certainly been my attitude. Agile teaches the importance of individuals and interactions over processes. He says its important to strike a balance with standardization. They must be used judiciously and be treated as living and breathing—i.e. always evolving. And no, they shouldn’t be stifling creativity and increasing complexity. In the end, I think he convinced me.
  • I liked the stories he used from real life situations. However, he never is specific about who the company is and I couldn’t help wondering sometimes if these were made up or real organizations. I think they are real, he just wasn’t specific so as to protect the innocent.

This is a good book and I’ll be recommending it to others. Its one I know I will have to revisit from time to time because it has a lot of depth. Buy it here.