Craig Tadlock (over at the Tadlock Enterprises Blog) made a couple good posts recently about Team Foundation Server and Team Build 2010:

Work Item Classifications
Work Item Relationships

He also came across this great blog that is focused on doing automated testing:

http://blogs.msdn.com/vstsqualitytools

as well as this link discussing custom workflow items:

http://blogs.msdn.com/jimlamb/archive/2009/11/18/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx

I’m setting up a local TFS test environment for myself now and hopefully soon should have some interesting information on setting up Lean build systems using this great platform.  I was lucky enough to work at a company that used the previous incarnation of Team Foundation Server and I have to admit I’m pretty excited to see what goodies Microsoft is giving us on this go-around.

“It’s like déjà-vu all over again” Yogi Berra famously once said, and yes, it is. We’ve been here before.  The promise of a new technology the will create so many efficiencies – too many to count.  It will make everyone’s life so much ‘easier’ and allow the organization to make unprecedented gains.

Enterprise Resource Planning (ERP) systems, and the consultants that sold them, promised us the moon.  While a few (and very few) made their mark, most would fall into the ‘failure to launch’ category.  If they did get off the launch pad, they didn’t make it very far.

While everyone generally accepts the definition of insanity as ‘doing the same thing over and over again and expecting a different result,’ organizations and leaders of organizations continue to repeat mistakes from the past despite warnings from many.  They rationalize it to themselves by saying, “our industry is different.”  The only thing to say to that is, “Yes, you’re different – just like everyone else.”

They then make the same mistakes done by those in different industries, but implementing the same concept, and wonder why the new technology failed to meet expectations.

So now, we have Electronic Health Records (EHR) [Electronic Medical Records (EMR)].  We’ve been told that this will help solve some of the issues that create so many problems in healthcare, and improve patient care, efficiencies, eliminate medical errors, etc.  Sounds a lot like the ‘moon,’ and if any industry feels they are ‘different’, it’s healthcare.

But the question is – what are you going to do different?

The traditional approach to implementing new technologies (like EHR) has been to focus on the Technology, glance at the Process, and be blind to the People.  We have traditionally centered everything we do around the new technology, treating it as a panacea; all we need to do is install it, and our problems will be solved.  To this end, we may take a brief look at how the process will be with the new system (rarely ever at how we currently perform it), and typically ignore the people who actually perform the process (we interview and train them, but do we listen to them?).  This approach has produced less than stellar results, with some pundits claiming up to 75% of technology project fail to meet expectations (this approach being only part of the many reasons for failure).

To approach an EHR in this manner would be doing the same thing over and expecting a different result.  A different approach (which I continue preach) would be to focus on the Process, while involving and engaging the People to prepare for the Technology.

By focusing on the process, we can get a true understanding of the way things really get done – how the people actually perform the tasks that move the organization each day.

With the people engaged, involved, and focused on the process, the organization will get a solid understanding of what needs to be improved, and have created the buy-in and ownership of the people who perform it each day to improve the process.

By cleaning up the current process, the organization will be prepared for the new process the EHR will bring and fully understand how to effectively integrate the technology and the process into a new way of operating.

So, are you going to repeat the mistakes others have made in the past when implementing technology, or are you going to try a new approach?

Let me know your thoughts!

Glenn

Today’s front page of the Toronto Star (Monday 22-Nov-09) featured an article on Coke’s new Eco-Bottle. The revolutionary plastic made from sugar cane byproducts is not biodegradable but can be 100% recycled.

Are companies beginning to understand how their product or service may be impacting the environment?  Coca Cola has taken corporate leadership to the next level.  For Coca Cola, understanding how the “complete” product affects the environment has driven tangible change to make a difference.

While Coke’s new eco-bottle is welcomed news, environmentally friendly or Eco-Friendly products are only one aspect to consider in terms of impact to the environment.  Other considerations include how and where the product is manufactured and end-of-life disposal.  At least Coke has addressed the end-of-life disposal aspect.

An extension to the manufacturing process is supply chain management from origination to the final consumer.  The transportation required to supply raw materials, produce, package, and distribute the final product  is as much a concern to the environment.

There is as much activity, if not more, in waste management and recycling than in the manufacturing and distribution processes.  Every stage of phase of a product’s life cycle generates waste in various forms.

Waste management companies are subject to the same environmental impacts through their own supply chain and distribution management, the recycling and disposal processes, and packaging of the product whether or recycled or deemed true end item waste.

Coke at least has demonstrated how large companies can take responsibility for the products they sell.  As consumers, we still have to do our part by making sure the bottle makes it to the recycling bin.

When you are the leading softdrink company in the world it follows that if you can’t improve your product then improve the packaging. We’re sure this will be part of a new marketing campaign to promote Coke as an eco-friendly company – and so it should.

From a Lean Manufacturing perspective, Coke has clearly demonstrated that Lean extends to every facet of the business – inside, outside, and beyond.  This is improving relentlessly.

Until Next Time – STAY Lean!

We are not affiliated with Coca Cola, Coke, or it’s products and services.

We bought a new kitchen table yesterday and found an interesting mistake proofing system for all the nuts, bolts, and washers that are needed for assembly.  They were in a bag that was put inside a bigger red bag.  The top of the red bag was twisted into a strip and then the was stapled on the outside of the box.  You could easily see before shipping if the hardware was included or not!  Simple but very effective.  Nothing worse than getting something home and getting ready to assemble and something is missing!  I’m sure we have all experienced this frustration.

Unfortunately, all the tables in the store were made in China or Thailand (the one we bought).  Anyone know how the furniture industry is doing with lean implementation?  I know 8 years ago we were able to buy a crib from an American manufacture.  Didn’t have a choice this weekend with the table.

Bryan

For nearly one year, we keep hearing the term recession. The fundamental question is whether it’s over or not. Not many of us are looking how to manage our supply chains during this period, trying to do the best under these circumstances.

Last week I was in Kuala Lumpur and Singapore and had the opportunity to discuss this subject with several Asian CIO’s. Most of them had gone through a rough year where budgets have been cut due to reduced business. Top of their agenda were three objectives, reduce costs, increase revenues (which in a downturn means taking market share away from the competition) and mitigate risk.

As Martin Christopher from Cranfield pointed out a number of years ago, “Companies are no longer competing with companies, but supply chains with supply chains”. Looking at the end-to-end supply chain is critical to address those three objectives. I argued companies need four key elements to truly operate an effective supply chain: visibility, responsiveness, collaboration, and risk management. I’d like to address these points in a series of blogs I hope to post over the next couple weeks, but before that I’d like to emphasis the importance of operating as an integrated supply chain.

Let me take a practical example. The Japanese invented the concept of “lean”, and worked a lot at making their factories and operations lean. But in their traditional, collaborative manner, they worked at the same time to help their suppliers and partners to also become lean. While having the end-to-end supply chain in mind, they also look at developing a collaborative relationship with their partners. The whole supply chain quickly became lean, despite the fact each company was focused on its own operations. I believe this to be one of the key reasons of the success of companies such as Toyota and others.

European and American companies have taken a different approach. Yes they have been working hard at making their factories and operations lean. They learned all about it from the book “The Machine that changed the World”,  but they often became lean through pushing the “waste” up and down the supply chain. Unfortunately, we, as the end consumer have to pay for the waste, regardless of where that waste is along the supply chain. The lack of close relationships with their suppliers, and of visibility of what happens across the supply chain, did not allow them to spot the problem. They keep asking themselves why they cannot make a given product at the same price point as their Japanese counterparts. To solve the problem, they outsource manufacturing to Asia, to take advantage of the lower labour costs, but do not realize they have not solved the real problem. As manufacturing costs increase in Asia, they will be confronted with the same issue, except if they take notice, and change their approach.

I used this argument in the discussion and was actually surprised how much agreement I got from the audience. To me this sounds obvious, but it seems many companies have not thought about it, nor have they looked at how they could address the issue and improve their competitiveness.

In the next post I will discuss the importance of a win-win collaboration for the success of the relationship.

In Jim Easton’s recent article in the Health Service Journal he relates the four leadership principles that the Department of Health want NHS organisations to align to as they try to improve quality and efficiency. These four principles are summarised as:

1. To work together to design new solutions

2. To manage improvements at the appropriate level

3. To value clinical leadership and engagement

4. To pull in the same direction

These are worthy principles but lack any indication as to how to do them, or substance to explain what actions this means in practice. The fact that these four principles lack any substance will mean their impact will be extremely limited. 

From a recent article we have produced on creating the right environment to ensure organisations are able to implement change successfully, we identified six key principles that differentiate those organisations who will be successful from those who will struggle and these are;

• Link improvement activities to things that really matter
• Make improvement is everyone’s responsibility
• Be responsive and flexible
• Celebrate and communicate every success
• Constantly adapt and evolve
• Build partnership within and outside the organisation

For each of these principles we have identified some of the key things that leaders actually need to do to ensure success and to find out more visit our website, join our network and be amongst the first people to receive a series of 3 white papers on how to create and effective environment and effectively manage organisational performance.

Just visit www.amnis.uk.com or ring 0870-446-1002 for details of how to sign up to our newsletter.

Second in my series of people photography!!  Now, I know I said that the Mexico series was done with, but, surprise!  More Puerto Morelos pics!  Were these strategically saved for this series or did I just forget to put them with the other series?  You’ll never know.  Anyhoo, its fun to photograph kids doing their kid-ly things.  They always seem so completely absorbed in what they are doing and bring such a fun, carefree-because-they-don’t-have-bills-to-pay  feeling to the photo.  I find that looking at pictures like this always makes me remember how much I liked to do (blank) when I was (blank) years old, long before medical school sort of owned my soul.   

So, this boy and girl were playing in the sand on the shore by the Puerto Morelos pier in Puerto Morelos, Mexico.  They are in front of the original lighthouse that was transformed into the Leaning Lighthouse of Puerto by Hurricane Wilma.  Since it’s more or less non-functional now, there is a new lighthouse a bit further back from the shore.  It is much taller and, personally, if I were a sailor, I’d be glad Wilma killed the old short lighthouse so that I could guide myself home with the more modern upgraded model.

The photo was taken with the Canon Powershot G7.  I used Adobe Photoshop CS3 to adjust the contrast a bit and to bring out the slightly sepia tones in the picture to help create a more nostalgic feel and to highlight the angle of the sun.

In my previous post, I described how pull systems work. I made the statement that work is only done in a stage in a pipeline when there is a request from the downstream stage. I.e. I only develop some code when QA has asked me for some artifacts to test. I also made the statement that if there is a request from a downstream stage, and no work needs to be done to fulfil that request, then the ‘conversation’ should ‘return’ immediately.

I contend that test-driven development (TDD) is a pull system. I make a request, and I then fulfill that request. I write a test as a specification of what I want to achieve, and I then write code to fulfill that request.

According to TDD best practice, I write code only when I have a failing test. This is indicative of a pull system. I write the code only when I need to. This need is represented by a failing test.

TDD ensures that you don’t waste time writing unneeded code. All code written must be justified by the ‘failing test’ rule. Otherwise it is considered superfluous, and does not contribute to satisfying the request from the downstream process.

If you write more code after all your tests have passed, you are not adding value and you are being wasteful.

Think of TDD according to this example: instead of producing an engine and then trying to fit it into a car (a set of requirements), rather start off with the car, and have the test ‘does my car go?’ You only need an engine to make a car go. If the car goes without an engine (highly unlikely), you don’t need the engine. Production of the engine can be justified (ie represent value) only when there is an explicit need for an engine. Code is only needed when you have a failing test.

You may refine your test to include economy and performance requirements etc: “My car needs a certain maximum speed. To achieve that, I need an engine which produces 100kW. Does my engine produce 100kW?” If your car needs an engine that produces a maximum of 100kW, it is wasteful to design an engine that produces 120kW. When designing the engine, you have explicit requirements  you need to satisfy. Producing more than what is required is wasteful, and is not ‘pull’. If your tests aren’t failing, don’t write more code.

Similarly, if you are designing a new car that needs an engine that produces 100kW and  you already have one sitting on the shelf, don’t design another one – if you add a test which passes without any new code, don’t write more code.

TDD simply provides a philosophy for specifying your requirements, and a mechanism for evaluating whether you have satisfied those requirements (i.e. does my engine satisfy all my requirements?). It provides a means for simulating requests that the code’s production clients will expect to be satisfied (e.g. drive-train and throttle interfaces). TDD makes those requirements explicit and measurable.

To conclude, TDD is a pull system. When practicing TDD correctly, code is only written when there is a failing test, signifying an explicit need for some work to take place. There should be direct traceability from each line of code to a TDD test, from each TDD test to a user story/MMF/BDD test etc, and so on up the line. The value stream then becomes explicit. Any code which can’t be traced back to a test (requirement) can then be considered waste and should be eliminated. (Obviously there will be some infrastructure code etc).

Some more notes on TDD as a pull system:

- A failing test is usually signified by ‘red’. This red serves as a visual trigger for action: we need to write some code. ‘Red’ is therefore a Kanban.

- The ideas discussed here don’t address the problem of how to arrive at TDD tests. In the car example, the tests are put forth as natural langauge: “Does my car go”?, “Does my engine make at least 100kW?” In reality, it is often difficult to translate user requirements into low-level unit tests required for TDD. Techniques like Doman Driven Design (DDD)’s ubiquitous language and Behaviour-Driven Design (BDD) can help towards this.

If we’re talking about engines, unless we can agree what ‘100kW’ means and how we measure it, we can never be sure that we’re actually satisfying our requirements, and we will fail only when we try put the engine in the car and drive away. At this point, it becomes very costly to try change the engine or the car.

- We are lucky that we can use these self-same tests for automated regression testing.

These are my thoughts on Lean systems from a pull perspective, and how Kanban Boards can be used to facilitate a pull instead of a push system in software development. I don’t go into the pros and cons of pull systems in software development.

Imaging you want to order a  new from Toyota. In a push system, Toyota would try anticipate customer demand, and would produce a certain number of cars per period. These cars would then sit in a lot somewhere until they’re sold. This is wasteful. In the ideal, what should happen is that your order gets passed down the line, through successive levels in the business until the order is fulfilled. It should look something like this: The sales person passes on the order to the manufacturing plant;  the order is directed to the appropriate manufacturing line (car model) etc etc until it gets to the person making the wheels, doors etc for the car (including the suppliers).

This can be illustrated by the following conversations:

Me: “Salesperson, I want a 1.6 liter Corolla!”
Saleperson: “Factory, we need a new Corolla for this customer!”
Factory foreman: “Corolla line, we need a car with these specs for this customer!”
Corolla Line Manager: “Engine supplier, we need a new 1.6 liter engine for this car!”
…
Engine Supplier: “Corolla Line Manager, here’s that engine you asked for!”
Corolla Line Manager: “Factory foreman, here’s that car  you asked for!”
Factory Foreman: “Salesperson, here’s that Corolla you asked for!”
Salesperson: “Customer, here’s your car!”

Each lower level in the process is only asked for something when there is a need. It is obvious that the conversation at a specific level cannot be ‘returned’ until it is satisfied. That is, a car cannot be produced without an engine. Note also the symmetrical nature of this series of  conversations, it starts and ends with the customer.

What does not happen is that there is a pile of engines, gearboxes, doors etc waiting around to be used when an order comes through. (Obviously there may be lead times associated with each part, but this can be handled with Kanban and order points). The process to create each item is triggered or initiated only when there is a firm requirement for that part to be made. Parts are created just-in-time (JIT), only created when they are needed (and delivered to where they are needed).

The same process should be followed in software development. The conversation might be something like this:

Business (our customer): “Deployment team, give me this feature I want!”
Deployment team: “Quality assurance team, give me this feature to deploy!”
QA team: “Development, give me this feature to test!”
Development: “Business analysts, specify this feature for me to develop!”
BAs: “Business, explain this feature to me so I can specify it!”
Business thinks about it then, Business: “BAs, it needs to do this and this and  that!”
BAs specify it then, BAs: “Development, here is your specification to develop off of!”
Development develops the feature then: “QA, here is the feature to test!”
QA test then, QA: “Deployment team, here is the artifact to deploy!”
Deployment deployes then, Deployment: “Business, here is your feature in the live system!”

Each team in the process only does work if there is a request from the downstream team. The downstream team is notified when the work item is ready for their attention. If there is no request from the downstream team, no work happens. If there is a request from a downstream team, and no work needs to be done to fulfil this request, then it is simply moved downstream, and started on its return conversation journey. (If this case seems cryptic, I will explain it more in a later post.)

The term ‘Kanban’ has become invested with the meaning of a ‘visual trigger for action’. A task board becomes a Kanban board only when task cards signify some action, otherwise it serves only the purpose of tracking where in the process a task is. The typical trigger for action is the return path in the conversation above, something like: “QA, here is that feature for you to test!”. This is manifest by a developer moving a task card into the ‘Done’ or ‘Waiting for QA’ column on the task board. This is a visual trigger for someone in the QA team to pull this task into their personal queue. This can further be improved by imposing work-in-progress limits for each resource at each stage in the process.

The following occurred to me while writing this post:

At the moment, I don’t know if the forward conversation should be represented on a Kanban board, and if so, how. Perhaps with a different coloured card. I think it might add value to track this forward conversation, since it could still serve as a trigger for action. As in the case with the car and engine, a QA engineer can test a feature until it has been developed by a developers. Similarly, a developer cannot begin development on a feature until it has been specified by a BA. Perhaps it is necessary to represent this on the Kanban board. I.e. a visual trigger to a BA that he needs to do some work.

This could be achieved by having a ‘reverse’ stream on a Kanban board, representing the forward conversation. Thus, when QA is asked to present a feature to give to the deployment team to deploy, QA should put a card in the ‘waiting for development’ column on the board. This card is then passed upstream in the process until the first stage in the process (business in our case) fulfils it, then starts passing it back downstream. This could be used to discover bottlenecks in the upstream direction. I.e. our developers are sitting idle because the BAs cannot develop specification fast enough.

This can be discovered on a ‘normal’ Kanban board by the ‘to do’ column for development remaining empty for some time. Perhaps then the absence of work items in the ‘to do’ column for any stage indicates a bottleneck in the stage before.

After being around different systems, process, models, process tools, etc, etc   I wanted to try and see if I could design a model that would illustrate how it all fits together.

I have done a draft in Powerpoint,  this gives a good starting point  but I would love to get some feedback or other input – I will probably need to change from Powerpoint to another, more appropriate media soon.   The model is based around retail/distribution with a small amount of production.

Regards
Mark

Click here to see PPT Slide – >   Business Modelling

How does your company roll out its annual business plans?  Do you get a huge spreadsheet with every cost possible, including toilet paper usage, broken down by accountants after weeks of calculations?  Is there a 95 page Powerpoint presentation that rivals any insomnia methods that exist today?  I really despise those techniques, mostly because of all the waste our leadership and accountants put into a plan that was usually irrelevant by the time the starting month began.  But that was only after I was enlightened by  the lean 7 wastes.  However, even before that I was generally uninspired by this method.

If you lead a group of people and share the same view of uninspiring business plans, I encourage you to try playing “catchball” with your group. Catchball, as described by Pascal Dennis here, is the best method I’ve have found to truly engage your team and achieve astonishing business results.  It’s a crucial part of Policy Deployment that Bruce has been blogging about.  (here, here, and here.)

The name catchball comes from the concept of taking ideas and playing catch with your team, unearthing solutions to a problem.  Within policy deployment, this problem is the large business goal and the outcome is a series of activities intended to achieve that goal. 

The key is that the team members at the lowest levels are the ones developing the solutions.  This creates intensely motivated teams with unbelievable buy in to the business plan.  It increases morale because people are working on what they determined to be the important items.  It all rolls up into outstanding business results and a high level of personal satisfaction for the team.

The best way I’ve achieved catchball success is to start with an A3 with the background information that describes the business problem, like increase sales by 15%, and the gap analysis portion completed.  Then turn it over to the team involved to analyze  problem cause(s).  Let them work on it for a couple days then get back together to scrub the information.  I’ve used 5 why’s, stand in the circle, data mining, and other methods here to capture the causes of the problem.  Once a consensus is achieved on the cause, then send the team back to develop the corrective actions.  Give them a couple days and meet again to review.  Once again achieve consensus.  Complete the A3 with the chosen actions. 

A crucial point here is to make sure that both the leadership and the team agree upon the path chosen and both take equal accountability for the outcome.  Now go to work!  This may entail creating additional A3’s and additional catchballs as you progress towards the goal.  Remember to get together and monitor progress on the A3 at frequent intervals once they are in place. 

A little warning is required here.  It all sounds great but it requires a huge amount of work and patience achieving consensus and playing catchball, but it is worth it.  You must fight the urge to just delegate the tasks to your team when you get impatient and the pressures are mounting.  You must “give up control” and fight the Amercian mentality of “I’m the boss and I’m the smartest person!”  You’ll also encounter team members that don’t want the accountability of developing solutions!  Don’t be discouraged by these things as you play ball.

If your business plans are uninspiring and you are looking for a better way, go through the LEI webinar with Pascal and give catchball a try.  You’ll be truly amazed at the results for the business and the personal satisfaction of your people!

If you decide to give catchball a try be sure to let me know how it works out!  zleanone@gmail.com

Bryan

Contingency Planning For Lean Operations – Part II

Putting together a contingency plan can be quite challenging when you consider all the things that could go wrong at any given point in time.  Contingency plans should not only be restricted to ”things gone wrong” and are not limited to operations or process specific events.  All aspects of an operation are prone to risk.  As such, contingency planning must be an enterprise wide activity.

Failing to understand and assess the risks that may impact your operation is a recipe for future failure.  If you fail to plan then plan to fail.  The same is true for contingency plans.  Effective risk management and contingency planning are critical to minimize or eliminate the effects of failure.

Natural disasters (like we’ve never seen before) continue to plague us without prediction.  Yet, we are able to respond immediately and effectively.  If you get hurt or injured, someone is there to help you simply by dialing 911.  Emergency units are ever present and available to respond.

Unfortunately the same is not necessarily true for business.  The recent turn in the economy caused financial markets to tumble and decimated corporations on every scale.  Millions of people are affected by the fallout.  The government “loans” were not crafted after the event.  Did contingency plans exist to even consider this level of change in the economy?

Although history may be the best predictor of future events, it is not exclusive or exhaustive to predicting unforeseen future events.  Even if history did provide a glimpse of potential future failures, we may simply choose to ignore the probability of recurrence – this isn’t the first time the financial markets have crashed, yet we can’t seem to determine or understand what key indicators existed that could have prevented this current situation.

Certainly new variables are introduced as technologies continue to evolve and become more integral in our operations.

In Part I of this series we suggested that contingency plans should be prepared to address potential labour challenges and more specifically availability.  Certainly, the recent concerns regarding the H1N1 virus have heightened attention with respect to labour shortages.

• Inclement Weather – Immediate effects of Snow Storm, Hurricane, Heavy Rain, Tornado.
  • Other considerations include:
    • Duration
    • Seasons
    • Cumulative Severity
    • Delayed Effects (flooding)
    • Property Damage.
• Accident / Injury:  Personal versus Workplace
  • Long Term
  • Short term
  • Considerations to reduce or minimize impact to operations:
    • Early Return To Work
    • Modified Duty
    • Restricted Duty
    • Reduced Hours
• Illness (Personal / Family / Extended Family)
  • Short Term
    • (Flu, Cold)
    • Emergency
  • Long Term
    • Surgical Care
    • Chronic Care
• Sudden Premature Death
• Parental Leave (Maternity Leave)
• Bereavement – Immediate Family, Out of Country
• Retirement / Attrition
• Training
  • Onsite vs Offsite
  • Duration
• Meetings – Department
  • Company Wide
  • On Site
  • Customer Site
• Quality Disruption
  • Containment Activity
    • Sorting
    • Rework
• Travel
• Vacation Allowance / Timing
  • Customer Driven
  • Company Mandated
  • Personal Choice
  • Season
  • Duration
    • New Hires – Zero Weeks
    • Senior Employees – Per “X” Years of Service
• Holidays
• Absenteeism (Culpable)
• Layoff and Recall
  • Short Term
  • Long Term
• Supply Chain Disruptions – Raw Material or Part Supply
• Planned Shutdown / Start Up Events – Holidays
• Leave of Absence – Short Term / Long Term
• Facilities
  • Loss of Utilities:  Water, Electricity
  • Fire, Suspended Services
  • Parking Availability
  • Locker Space
• Equipment – Breakdown / Malfunction (Major)
• Tooling – Breakdown  / Malfunction (Major)
• Skill Levels Required – Non-Skilled, Semi-Skilled, and Skilled Labour
•  Union – Strike
• Customer Decreases
  • Shutdown (Reduced Volume)
  • Slow Down (Reduced Volume)
  • Reduced Work Week (4 vs. 5 days)
  • Shutdown (Planned)
• Customer Increases:
  • Volume
  • Extended Work Days (Daily Overtime)
  • Extended Work Week (Saturday)

There are likely more areas of concern that may impact your labour pool, however, this does serve as a starting point.  Do all of the above elements require a contingency plan?  Not necessarily.  We still contend that it is good practice to document all potential concerns.  It is easier to add a note to document the reason for exclusion from the contingency plan by stating:

• The following elements were discussed during the preparation of this plan, however, specific contingency plans were not considered necessary at the time of review:
  • Training – Scheduled Activity
  • Culpable Absenteeism – Progressive Discipline Program
  • Add Elements to the List as applicable

This latter task may seem somewhat trivial, but consider who else may be reading the report.  Defining the scope of the contingency plan and adding a list of exclusions supported with reason(s) clarifies any ommissions from the core plan, will minimize the time required for review, and eliminates any assumptions regarding unintended ommisions.

Our next post will address the elements to be considered when developing a contingency plan.

Until Next Time – STAY Lean!

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod FM radio remote por dan taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

• Entrevista com Alisson Vale da Phidelis
• Entrevista com Alexandre Magno na Série Experiências Ágeis
• Entrevista com Carlos Barbieri sobre o MPS.BR
• Entrevista com a equipe da Ancar na Série Experiências Ágeis

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

• Uma Visão Geral Sobre Scrum
• Testes Automatizados
• Bancos de dados ágeis e refatoração de bancos de dados

Agile Toolkit Podcast
http://agiletoolkit.libsyn.com
Inglês

• Tom Goulet – Cucumber, Ruby and the transition to Generalizing Specialist (2009)
• Jim Miller – The Product Owner Role and Business Alignmnet
• Tips and Advice – Retrospectives

ThoughtWorks Podcast

http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

• Entrevista com Kent Beck sobre Extreme Programming (XP)
• Entrevista com Linus Torvalds, o criador do Linux e do Git
• Entrevista com David Heinemeier Hansson criador do Ruby On Rails
• Entrevista com Tim O’Reilly, fundador e CEO da  O’Reilly Media
• Entrevista com John Resig criador e líder do Projeto jQuery
• Entrevista com Jan Lehnardt evangelista do projeto CouchDB
• Entrevista com  Jacob Kaplan-Moss criador do Django
• Entrevista com Bruno Souza sobre o OpenJDK
• Entrevista com Ward Cunningham inventor do Wiki e grande Personalidade da Comunidade Ágil
• Entrevista com  D. Richard Hipp criador do SQLite
• Entrevista com Nate Koechley sobre o Yahoo User Interface Library (YUI)
• Entrevista com Junio Hamano, Mantenedor do Git
• Entrevista com Rasmus Lerdorf, criador do PHP
• Entrevista com Guido van Rossum, Criador do Python
• Entrevista com o fundador da Wikipedia, Jimmy Wales

Java

HorecaExpo - Java por bramloquet

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

• Rod Johnson: SpringSource and the future of Spring (2008)

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

• Entrevista com David Heinemeier Hansson (2005)
• Entrevista com Dave Thomas (2005)
• Entrevista com Chad Fowler (2005)
• Entrevista com Obie Fernandez (2006)
• Entrevista com Dave Thomas e Mike Clark (2006)

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

• Dave Hoover on Software Crafsmanship (2009)
• Obie Fernandez on the Rails Maturity Model (2009)
• Ola Bini on Polyglot Programming (2008)

JavaScript

jQuery Podcast

Português
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

• Chad Fowler on the Passionate Programmer
• Fred Daoud on Stripes
• Chad Fowler Finding the Jagged Edges
• Andy Hunt on Pragmatic Wetware

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

• Software Archaelogy with Dame Thomas
• Fearless Change with Linda Rising
• Learning as a Part of Development with Allan Kelly
• SQL with Jim Melton
• Continuous Integration with Chris Read
• Top 10 Architecture Mistakes with Eoin Woods
• Usability with Joachim Machate
• Introduction to AOP with Christa Schwanninger e Iris Groher
• Retrospectives with Linda Rising
• 10 years of Agile Experiences
• Joe Armstrong on Erlang
• Interview Dave Thomas
• Dick Gabriel on Lisp
• Jeff DeLuca on Feature Driven Development
• Interview Erich Gamma
• Gerard Meszaros on XUnit Test Patterns
• Static Code Analysis with Jonathan Aldrich
• Refactoring Pt. 1
• Refactoring Pt. 2
• eXtreme Programming Pt.1
• eXtreme Programming Pt.2
• Agile Documentation
• Interview Jutta Eckstein
• Interview Eric Evans
• Patterns

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

• Agile for Families
• Entrevista com Jim Wierich o Criador do Rake (Ruby)
• David Laribee on Lean / Kanban
• Uncle Bob Martin on Clean Code
• Alan Shalloway on Lean
• Entrevista com Jarod Ferguson
• Entrevista com Darrel Carver
• Entrevista com Scott Nichols
• Entrevista com Scott Schimanski

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por  Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

Se você quiser incluir algum outro podcast nesta lista, deixe um comentário. Espero que seja Útil!

After all the hype about how beneficial these methodologies would be in reducing costs and improving production, it seems it was all just that – hype. And now they have got to that critical point in their own life-cycle where they have become “the Norm” – If you are not using them, supposedly, you will fail or be shipping out cash by the truck load in inefficiency and waste.

Then again there are attributes that are worth using, they worked for Toyota and GM – that must carry some weight.

It seems that the old adage “…all your eggs in one basket” can be used here too. If you put all your resources into improving the systems, you are probably missing the people aspect. Does your company have someone that integrates all improvement opportunities or is this left for the CEO,Dir,GM?

Has your company had issues with processes and wondered why the Improvement Plans did not work? Did your company have people that feel dis-enfranchised, or have a grudge or actually want to feel they own their job but the process has taken it away.

Any improvement program must FIRST deal with the staff, the workers, the ones that can make it work – or fail. Yes the improvements are to all about making money but this can only be done with the staff on your side.

If all improvement plans are coordinated and integrated including staff participation and engagement to the full then culture changes, improvements happen, customers come back.

So the point is: tools do work but you need to ensure the workshop has the right culture and the right people are taught how to use the right tools – from the top to the bottom.

Get the right change for your dollar.

Cheers
Mark

Contingency Planning For Lean Operations – Part I

Lean operations are driven by effective planning and efficient execution of core activities to ensure optimal performance is achieved and sustained.  The very nature of lean requires extreme attention to detail through all phases of planning and execution.  Upstream operations simply cannot tolerate any disruptions in product supply or process flow without the risk of incurring significant downtime costs or other related losses.

Effective risk management methods, contingency plans, and loss prevention strategy are critical components of successful operations management in a lean operation.  Risk management and preventing disruptions is the subject of contingency planning and requires the participation of all team members.

Successful contingency planning assures the establishment of an effective communication strategy and identification of core activities and actions required.  Contingency plans may require alternative methods, processes, systems, sources, or services and must be verified, validated, and tested prior to implementation.

Understanding and assessing the potential risks to your operation is the basis for contingency planning with the objective to minimize or eliminate potential losses.

Inventory represents the most basic form of contingency planning.  Safety stock or buffer inventories are typically used to minimize the effects of equipment downtime or disruptions in the supply chain. 

The levels of inventory to maintain are dependent on a number factors including Lead Time, Value, Carrying Cost, Transit Time (Distance), Shelf Life, Minimum Order Quantities, Payment Terms, and Obsolescence.

Why is this relevant?

Material and Labour represent two key resources that may be influenced by external factors that are beyond the control of any company policy or practice.  Internally controlled or managed resources such facilities, equipment, and tooling are less susceptible to unknown elements.  For the purposes of this discussion, we will examine Labour in a little more detail.

The H1N1 virus, originally known as the Swine Flu, is the latest potential health pandemic since the outbreak of SARS only a few years ago.  The government has been struggling to organize mass immunization clinics and to engage the media to aid in the cause.  In the meantime, the potential impact of the H1N1 virus on your operation remains to be an unknown. 

Experts have commented to the media that the lessons from the SARS outbreak have still not been learned.  One would expect that past practices would have already been adopted into new best practices from our experiences with other similar events in our history.

Government agencies at all levels (Federal, Provincial, and local) have mismanaged the activities required to procure and distribute the vaccine, and failed to provide an effective communication and immunization strategy to ensure the risk to public health was minimized and the at the very least understood.

The lack of coordination and accountability for the success or failure of the communication strategy, procurement and distribution of the vaccine, and other related activities are strong indicators that the planning process did not consider the infrastructure requirements and relationships needed between levels of government.

The lack of an effective communication strategy introduced confusion and speculation in the media and the general public.  Mass education only seemed to become more aggressive as incidents of severe H1N1 complications and related deaths were reported in the media.

If this really was a pandemic event, many operations today would (and may still) be adversely affected due to direct or indirect (supply chain) labour shortages.  Do you have contingency plans in place to address this concern?

It could be argued that “if we are affected to this extent, then our customers will be as well.”  This is not necessarily true unless your customers and / or suppliers are located in the same immediate area or region of your business.

People travel all the time, whether they are commuting to work from out-of-town or traveling to or arriving from a foreign country on business.  The source of exposure is beyond your immediate control. 

What other elements can directly impact labour?  We will explore some of these in our next post.  In the meantime, keep your hands washed and remember to cough into your sleeve.

Until Next Time – STAY Lean!

Unexpected and Appreciated – Uncommon Courtesy:  This morning, a person cut into the drive through lane ahead of us – not realizing the gap in the line was there for thru traffic.  Recognizing the error in drive through etiquette and to make amends, we were pleasantly surprised by the ”free” coffee at the pick up window.  Thank you ladies!

Lean and Agile principles help drive the business and IT sides of an organization to effectively work together and foster mutual responsibility for meeting business goals.  But it’s important to note that the adoption of Lean principles is best achieved when it is done as an iterative exercise itself.  Creating a blueprint for broader rollout based on practical knowledge and planning is critical for understanding how to bring its benefits to the entire organization’s landscape.

This week, we’re talking publicly about the success one of emergn’s clients, British Airways (BA), has had with adopting Agile, and how we’re working collaboratively with them to build a blueprint for broader rollout across their organization.  BA began their Agile journey by seeding a few choice back-office project teams with emergn Agile coaches to build a foundation of Lean and Agile expert knowledge. With this initial effort, BA was able to learn how their teams would react and adopt to Agile, and use that knowledge as the basis for fostering adoption across more parts of the IT landscape. After successfully implementing methods for faster, higher-quality web site software development, BA is continuing to work with emergn to design and enable a set of program-wide operating processes to rationalize all of the airline giant’s global back-office functions.

Through emergn’s training of BA’s business and technology team members on using Lean and Agile principles like user story creation, continuous improvement, and retrospective planning, BA has realized significant productivity gains, higher quality, and much shorter ROI lifecycles that they want to spread throughout the rest of the organization.  BA has found an approach for Agile adoption that works for their people.  That they see emergn’s approach to Lean enablement as a way to make their entire IT landscape more efficient is indeed the crux of what emergn aims to accomplish with all its engagements.

its times when you worry

that you lose track of hope.

that we forget that faith is believing

even when we lose sight.

it’s fearful, and tiring

and it’s alright to slow down.

but know when you’ve got to take a break

I’m there at your pitstop.

If you read this, know you’re in my prayers. Know that you’re not alone, and won’t be on Dec 7th and the days that follow. Don’t choose to be alone, because we would be thankful to be there for you, just as you’ve been for us. To Jee.

When I was in elementary school I couldn’t stand poetry.  I didn’t mind reading it, but I absolutely despised having to write poems.  I found it bothersome trying to make everything rhyme.  Then the teacher taught me about haiku.  “Those kids in Japan sure are lucky for not having to make everything rhyme,” I thought.  I still find making stuff rhyme a pain, and being grown up I don’t have to do stuff like that just because the ‘teacher says.’  So I won’t.  I am going to ‘do haiku’ instead.

Haiku fits into the lean paradigm because only having 17 syllables to make your point forces a lot of thought, and reflection leading to concision (think fitting your story on one side of one piece of A3 size paper).  If you think about economy of effort and concision which is certainly the goal of, or the natural outcome of the lean philosophy, 17 syllables is certainly more concise than Beowulf.

So, all that being said I will bare my artistic soul to your literary criticism and share with you my first Lean Haiku. It’s called Fujio Cho on the Way to His Office.

The subject of the poem is Fujio Cho, the first president of the Toyota Georgetown, Kentucky plant.  It relates the first part of chapter 18 of Jeffrey Liker’s The Toyota Way. This chapter tells us of the importance of going to the actual place and seeing the actual thing (genchi gembutsu).  Mr. Cho would stop at various places on the floor of the plant (in the Gemba) on the way to his office and just watch stuff happen. The point of the poem is that Fujio didn’t just go to the gemba for morale’s sake – to show that he felt comfortable around the operators.  He didn’t talk to a bunch of people.  He just went and studied the work taking place looking for deviation from the ‘normal.’  He would watch to assure that standardized work was being followed, was material flowing as it should, how would people respond when there were problems, etc.

A few rules for genchi gembutsu:

1. Watch first, ask questions later.
2. When you see abnormality ask why, don’t correct, don’t judge.
3. Be intellectually humble.

What are your rules when you are in the gemba?  Do you feel that you do it enough?  What are some non-manufacturing gemba(s)?  Comments welcome.

Ed. Note – The presence of a umich.edu link in this post in no way indicates that the author condones, sanctions, or otherwise justifies any public praise for said university.  It remains the position of the author that beyond Dr. Liker not much of anything good has ever emanated from up there.  Go Bucks!

Like most people, I love Chinese food.  Also like most people, I have a really hard time going out (especially to the amazing, expansive buffets) and eating only supportively.  Given the fact that they drench, bread, pork fry, tempura, and duck sauce the heck out of everything, it’s really hard to go out and not cave to temptation.

I love, love, LOVE  beef and broccoli.  It’s sooo good, and really easy to make.  So, I created my own at home.  Instead of take-out, I call this my “fake-out”. 

Here’s my recipe:

First, I took some olive oil and softened one small white onion, a tablespoon or so of chopped garlic, a tablespoon of fresh, shredded ginger (you can use powder, or omit if you just want a savory, beef-brothy kind of “sauce”), and about 1/2 a teaspoon of cumin in it.  Once it was a little soft, I added a little broth (chicken worked for me because it’s what I had on hand, but you can certainly use beef; I just was using up something I had in the fridge), and started browning 12 ounces of 93% lean ground beef in it. 

Now, what I like best about this recipe is the SPEED!  It is SO fast.  Literally, from softening onions to plate time is 15 minutes or less.  Awesome, speedy, and delicious; what’s better than that?!

Once the beef is just shy of all-the-way-cooked-through, I put in a package of frozen broccoli (in this case, I used spears), and covered it until the broccoli was a bright, vibrant green, and the beef was totally browned.  I cut and freeze diced red peppers on the weekend, so I threw those in for some color at the end, again, just till they were bright and colorful, not to overcook them into mush.  Once they were done, I topped with peanuts and sesame seeds, and VOILA!  Chinese food at home for a fraction of the cost, as good tasting,  definitely better for you, and waaaay cheaper than you pay eating out. 

Here’s what it looked like:

Beef with broccoli

You can absolutely make this with shrimp, chicken, vegetarian or with tofu, scallops, beef strips instead of ground beef; whatever you have on hand!  Use what you’ve got, eat what you like, and enjoy your Chinese at home without the take-out box!