Poka Yoke – Mistake proof marketing

Definition of poka-yoke (as given in Wikipedia) is,  any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.   

Googling around on the benefits of Poka Yoke would throws up tons of results with astonishing numbers. People have reported nearly 98% increase in accuracy in their system , 0% error, 98% cost savings etc.

 

 

A very good introduction about Poka Yoke is available here. 

The popular methods in Mistake proofing include:

 

1. Contact Method
2. Fixed Value Method
3. Motion Step Method

You can get more details about each of the above methods here.

At the end of the day Poka Yoke is all about finding ways to stop mistakes or identify the mistakes before they occur.   Even though it was initially invented for the manufacturing industry, it is being applied to other industries like software too.

Some thoughts about applying Poka Yoke in Software development can be found here and here.  Automated software testing practices applied on Unit, Component and Integration testings are classic examples of Poka Yoke in software development.

Recently I came across this website where the author has offered some tips about  applying Poka Yoke for mistake proofing marketing.  One can also download free presentation about the concept on the same website.

This website is dedicated about Poka Yoke with wealth of materials about this concepts, certifications, etc. 

2 Minute Introduction to Lean and Kanban

Check this SlideShare presentation which gives a very simple and animated introduction about  lean and Kanban.

Attending the Java Oracle Open World 2010 Event

3 days of highly enriching sessions in Oracle Open World 2010 is keeping me occupied in San Francisco. Most of the sessions ending or beginning with Security, Scalability, Performance were sold out. It was tough to get seats for these sessions. Apart from attending Larry Ellison’s Keynote, I attended many sessions. I am listing a few of them here, and once I am back in India I am planning to blog about other sessions in detail on my architecture blog

1. Hadoop vs. Relational Database: Shout-out Between a Java Guy and a Database Guy.  This session focused on few tips around choosing Hadoop and when to choose RDBMS. Very interesting session

2. Mission Critical Enterprise Cloud Application

3. Journey to the center of Java Universe

4. Keeping your options open even if the cloud is not

5. More Best Practices for Large-Scale Websites: Lessons from eBay

 

 

and many more…

Nearly 41,000 developers from all over the world participated in this  event and as part of appreciation, Oracle had organized the Rock concert.  I enjoyed  listening to Don Henley and Black eyed Peas before heading back to the hotel late night.

How British Airways uses Agile

Here is a good article describing how British Airways IT department have started applying Agile methods and have started seeing a lot of benefits. 


Couple of points I liked in this this article include :

1. If you are interested in implementing Agile in your organization, start with a pilot project with a small team
2. Try to employ a coach to help you to begin the journey. They might be expensive but worth having them on board
3. Put people who are interested in Agile as part of initial pilot team rather than pessimists
4. Scale the Agile projects slowly to rest of the IT organization as opposed to scaling it quickly.

Scrum @ Home

Many scrummers have been implementing Scrum practices outside of Work but silently. 

My own example of

* Using  Information Radiators to track progress of tasks at home,
* Prioritizing the work,
* Retrospective with my family, etc.  

Recently I came across few blogs where Scrum practitioners are sharing info about applying Scrum practices outside work. 

Check them out here

*  Scrum For Kids
*  Scrum in Schools

You can also see few pictures of  how Saturday Chores could be handled in Sprints

. Don’t miss reading the details about how Sprint Planning was done, tasks picked by kids, etc just below the picture.

It is fun to see all this and at the same time good perspective of how Scrum can be applied outside work.

Are you getting any new ideas now to apply Scrum @ home ?

Google Wave, Innovation and Agile

The recent news that Google is officially shutting down “Wave” came as a shock.  Even though I never expected this to happen, I appreciate Google’s courage to shut down the product built with considerable amount of effort and money. This courage reminded me of the courage, one of the core values in Extreme Programming(XP).

 

Courage in XP is explained with as example as  :
Courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code

 

 

After re-reading the core values, I have been getting more questions than answers !
Do we really practice Courage in our projects ?  What fear do we have ?  Why do we hesitate to take risky decisions ? Who influences our decisions while we are on the project ? What do we need to change to practice courage ?

Coming back to topic of Google wave, the reaction to the Google Wave shutting down news has been pretty much mixed. Broadly the reactions were of 2 categories:

 

One really bashing Google for not thinking through  and finally shutting down the product

A

ppreciating Google’s courage and ability make quick decisions

I felt that these two reactions could be compared to Waterfall thinking and Agile thinking respectively.  The reason for this analogy is, Waterfall mentality is to force every one to think through all the possible things and create a plan engraved on stone. Agile being incremental and iterative in nature gathering constant feedback taking quick decisions every day. 

Even though waterfall way theoretically looks to work, it never does.  Agile thinking is all about quick action, getting the feedback and making course corrections, which I think Google did it as in the case of Google Wave.

Keeping the Google’s cue in mind, if one key value like courage is injected in Agile projects, then Agile teams will get an additional teeth to be more innovative. Without Courage, they would end up stuck with Waterfall thinking in the guise of Agile.

Agile Testing

I have come across many projects claiming to be Agile, however they are really doing nothing more than mini-waterfalls. They do the Requirements, design, coding and Testing incrementally and in a bi-weekly fashion. If you carefully observe, still testing is done during the last days of sprint/iteration.

What is not Agile Testing ?

Testing within Sprints in projects following Agile methods is not Agile testing. 

Developers have to do their own set of testing for “building the quality in” as per lean. However, the developer testing is not a replacement of traditional practice of testing. 

It is disheartening to note that, many people give a little or no value to the testing in Agile projects. According to me, Agile testing is important as a practice as Scrum Meeting or retrospective.

Myth around Agile Testing
There are still some myths around Agile testing.

* It is a myth that in Agile projects all the testing would be done by developers.  
*  Testers role would become obsolete in Agile projects

Additional factors that are given importance in Agile testing includes

 

1. Testers are no more reactive, they are proactive.
2. The testers are not in the project to identify defects but to build the quality in the product
3. Testers participate in all the activities of software development, right from Requirement analysis to design, architecture and till the end.
4. Testers play the role of Generalized Specialists taking one or two additional responsibilities  apart from testing. 
5. Test Automation is given importance than the manual testing

Agile Tester

With so many additional factors involved in Agile testing, is it really possible for traditional testers to switch gears quickly to accommodate the new changes ?    Answer is “NO”. 
It takes its own time and in the sense, it could take sometimes months. The rate of change depends on the support given by the management to the testing team.  More the support, smoother and quicker would be the change. 

 

 

Some of the mindset changes needed by Agile testers include
1. More stress on improving the communication skills
2. Courage to drive quality in by taking charge of projects
3. Proactive mentality rather than reactive
4. Eagerness to learn new technologies and framework to become generalized specialists.

In Summary:  Agile testing is all about change in mindset and focus on building the quality in the products.

Most Valuable Blogger

I have been awarded as the Most Valuable Blogger(MVB) by DZone. I am very excited about this news.

Emphasis on TDD in 1972

During the touring lecture in 1972, Edsger W. Dijkstra talked about the topic “The Humble Programmer”.  During this lecture he makes a statement, which I think is really revolutionary….

Those who want really reliable software will discover that they must find  means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging – they should not introduce bugs to start with.

Is he not talking about avoiding the wastes of Product development, one of the lean principles ?

Is he not talking about the Test Driven Development ?

 

Complete excepts from his lecture could be found here.

Even though such pointers to TDD has been propagated by thought leaders since 1970s, it is very sad to see hardly a few programmers follow this great practice even after 3 decades.

Science of Learning: My personal Experience

 

 

Recently  I read Mark Levison’s article Science of Learning:Best approaches for brain. He takes an example such as why many developers find it hard to grasp topics like Unit testing.
As trainers, coaches and mentors many people tend to use traditional way of  presentations(i.e. power point) to train people. However, these presentation ways of  coaching gets into short term memory.

In order to make an abstract idea stay in long term memory, several techniques are available. For example, making the training more visual, asking leading questions and sharing concrete examples that relate to what the audience already know.

In my Agile training programs, I have been already applying some of them concepts. For example, asking the trainees to think about solving the issues in their projects and then relating it back to Agile values and principles. 

Image courtesy : http://getfreeimage.com

Backlog Prioritization techniques

There are several ways to prioritize the requirements in the backlog. Some of the most popular ones include,

MoSCoW

                         
M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not effect anything else.
W - WON'T have this time but would like in the future.

Each requirement will have the priority which would be tagged to MSCW. “M” being the highest and “W” being the lowest.

This site gives a very good explanation about this technique.

Business Value Based

In this case, each requirement carries a business value it could potentially generate to the company. The business value would be decided either by the Product Owner or the Product owner team.

The requirement with highest business value is implemented during earlier releases .

Technology Risk Based

In this method, requirements are prioritized based on the risk associated in implementing it. The risk is typically based on the technology.

The requirement with highest technology risk is implemented during the earlier iterations.

Kano Model

In this method, the requirements are prioritized based on the customer preferences.

• 
  
• Attractive
• One-Dimensional
• One-Dimensional
• Must-Be
• Indifferent
• Reverse

You can read more details about this model here



Walking Skeleton

In this method, the requirements are selected such that minimal carefully selected end to end features are built within a short span of time.







Validated Learning

In this method, features are chosen based on the highest market risk i.e. some thing that is not experimented yet. Release it to the market, get the feedback and apply the learning onto the new feature.

This deck gives a good view about validated learning in the context of lean startup



mages acknowledgement: FreeDigitalPhotos.net

A few good quotes

  I have been reading

Agile Project Management: Creating Innovative Products (2nd Edition)  and in this book, Jim not only refers to a few good quotes by other authors but also has made many impactful statements.  The book provides views on Agile Leadership, Team Management and Agile Project Management. 

A few good quotes that I liked from the initial few chapters include

 

* Traditional managers view the plan as the goal, whereas agile leaders view customer value as the goal

*

Commanders know the objective;

leaders grasp the direction.

Commanders dictate;

leaders influence.

Controllers demand;

Collaborators facilitate.

Controllers micro-manage;

Collaborators encourage

* Leadership is what crosses the frontier between what we did yesterday and what we’ll do tomorrow. We’ll argue…that the real mark of a leader is confidence with uncertainty—the ability to admit to it and deal with it.”   - Phillip Hodgson and Randall White

* Agile project leaders help their team balance at the edge of chaos—some structure, but not too much; adequate documentation, but not too much; some up-front architecture work, but not too much. Finding these balance points is the “art” of agile leadership

Does it make sense to use MS Project in Agile Projects ?

 

 

 

 

 

 

 

It is a tradition to use MS Project as a Project Management tool in Waterfall projects. However, trying to use MS Project in an Agile project makes the lives of the developers more difficult than easy. 

There are several reasons for that and a few based on my personal experiences are..

1. Adding new tasks in between as they get discovered during the sprint causes havoc while using the tool

2. Tracking  story and task completion in the context of sprint is difficult
3. Moving around the incomplete stories and tasks to different Iteration makes the project plan chaotic
4. Picturing  Product and Sprint Backlogs while using MSProject is not so easy

In addition to above reasons, Michael Dubakov has written an article explaining why MS Project sucks in iterative development projects.

Rise and Fall of Waterfall Model

 

 

 

Craig Larman’s most popular book  Agile and Iterative Development a Manager’s guide  covers the topic about how Winston Royce’s white paper was misinterpreted which lead to the birth of Waterfall Model.

 

 

Incidentally an Agile practitioner has created a video explaining the birth and death of waterfall model in a humorous way.  The video is

available on YouTube

Balancing Organizational and Project Goals

In many outsourced(near shore or offshore) services organizations, employees are expected to take part in activities that are outside the purview of their projects. These activities are intended to support organizational growth in someway or the other. A few of such activities are

Conducting interviews for hiring new employees,
Taking team out for lunch/dinner,
Arranging an offsite meeting,
Conducting trainings, events
Publishing whitepapers, attending conferences, etc

The above mentioned activities need effort, and this effort needs to be accounted some where. Naturally, one might get few questions like:
Should one track these tasks in Sprint Backlog ?
Should one keep the customer updated about these tasks ?
Should this be estimated as part of Planning meeting ?

Being Agile practitioners, it is expected that the team should practice as much transparency as possible in estimation and tracking. Keeping this in mind, one should estimate the effort being spent on such activities during each iteration and capture it as part of a task in sprint backlog. This also ensures that the customer is aware of these non-billable activities at the same time, IEH and velocity counts are captured accurately.

It is not a good idea to mask these activities and also not informing the customers. This would not only affect the credibility of the team but also forces the team to stretch themselves to compensate for the lost time.

Image: djcodrin / FreeDigitalPhotos.net

Scrum Meeting – Punishment by collecting $ is it the right way ?

One of the first rules of Scrum Meeting is to ensure that it is conducted at the same time every day at the same place. It also expects that the team members should come on time to the Scrum Meeting.

Typical practice is that, late comers to the Scrum Meetings should either wear a joker cap or pay a $ as punishment for arriving late. However many thought leaders share that these practices of punishment is bad and it is not going to improve the situation or change the behavior of the late comers. Worse, Thought Leaders proficient in Intrinsic and Extrinsic Motivation, believe that, over a period of time the extrinsic motivators(reward or punishment) actually reduces the intrinsic motivation.

* So, what should we do in this situation ?
* How do we handle the late comers ?
* Should we ignore them ?
* How do we make the late comers for the Scrum meeting to come on time ?

The answer seems to be not easy. Researchers believe that there is no one formula that could be used to motivate every one. If some one is not coming on time to the Scrum meeting means either he/she is not interested or does not believe in these meetings and could be something else. One needs to identify the root cause of lack of intrinsic motivation and work on an individual basis rather than applying the same reward/punishment formula.

Cognitive Evaluation Theory and FLOW seem to provide some insights to improve the Intrinsic motivation.

Retrospectives in Agile Multi Site Development

Unlike other Agile practices, Retrospective sessions involves a lot of
emotions. Emotions could be easily understood(also handled) by looking at the body language of the people around us. However, in a distributed development projects, teams are scattered across various locations and this in turn makes it hard to understand the body language. This is one of the reasons why it takes more time for the scattered teams to bond with each other and thus reducing the efficacy.

Even though no tool or technique can replace the experience
emanating in a collocated team, there are a few that could

be practiced to improve the effectiveness of distributed retrospectives.

From the logistics perspective, one or more of following tools
could be used

Tool Name	Effectiveness
Voice chat through Wired phones, typically what is termed landlines or using popular tools like Skype, Yahoo Messengers, etc   without  Web cams	Low
GoogleDocs, Wikis in addition to voice chat and no web cams. Download the GoogleDocs Retrospective template from here	Low
Web cameras connected to tools like Skype or Office Communicators in addition to use of Google docs, Wikis,etc	Medium
http://www.CardMeeting.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.Dabbleboards.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.IdeaBoardz.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.IdeaScale.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.mindmeister.com Using this in addition to voice/video tools increases effectiveness	Medium
http://www.etherpad.com Using this in addition to voice/video tools increases effectiveness	Medium
http://en.linoit.com Using this in addition to voice/video tools increases effectiveness	Medium
Telepresence and Video Conferencing kind of tools  in addition to one or more of above mentioned tools	High

 

Note: Some of the above mentioned online tools could also be used for other Agile practices like Requirement gathering, brain storming, design discussions in distributed mode.

 

Patterns

Two popular patterns of distributed retrospectives include
1. All hands Retrospective
2. Location Specific Retrospective

In case of All hands Retrospective, all teams participate together
using one or more of above logistics. This pattern works well if teams
are located in same or closer time zones. May not be a good idea to apply this for larger teams . 

Location Specific Retrospective, In this pattern, location specific
teams conduct retrospectives and then the leads from each of these
location conduct “Retrospective of retrospectives” synching
Sad/Mad/Glad data. Larger teams (>15) can apply this pattern.

Test Driven Development for Embedded C++ Programmers

 

Src:blog.briandicroce.com/2008/03/

A lot of articles are available explaining TDD for Java and .NET. However I rarely find “good” TDD articles for C++ and C. 

James Grenning explains TDD for embedded C++ programmers in a step by step approach in this article

Comparison of Heavy and Lightweight methodologies

 

Several articles have been written comparing the heavyweight and the lightweight methods. 

However, I found this document to be very comprehensive in comparison.

 

 

The document compares the Heavy Weight methods like
Waterfall, UP and Spiral Model  with the Light weight methods like

  XP, Scrum, FDD, DFDM,etc. 

Building Generalized Specialists

The topic of  Generalists Vs Specialists is another eternal debate in the Agile community. Every one in the community has their own opinions.  I too have my personal opinion about this topic. 


Let me start this discussion with a few definitions.

Put it in a simple way,

 

A Specialist is some one who knows a “bit more” about something. In the context of the software world, this something could be Architecture, User Interface Design, Testing, Coding, Business Analysis, etc

A Generalist is some one who knows a bit about many things

The question arises, should we have specialists in the team or generalists in the team.   Each of these techniques has its own pros and cons as explained in this article.

My opinion is that, every individual is passionate about something. Some times they get to express it and get opportunity to pursue the same, and many won’t get this chance. People pursuing their passion end up becoming true specialists. However at the end of the day, every one in the software company gets a designation whether they like it or not, and end up becoming specialists.

Is there a problem being a specialist ?

Many Agile evangelists say specialists are not good. However what they mean is bottlenecks created due to specialization is not good. Bottleneck arises due to demand and supply issue in the organization/project.

Let me give you an example, most of the software companies (that I have seen so far)  have limited number of  Architects and Database administrators and mostly these roles are shared among various projects. Consider a situation when the Oracle DB admin who is currently been assigned to a new project is at the client site gathering requirements. At the same time, a critical bug was detected in one of the DB modules that he worked on an earlier project and this is a show stopper.  This is a challenging situation right ?  How can we make use of the DB admin in handing this situation as he is the only one available.

Let us review couple of options on hand

 

 Option 1:

Pull the DB admin for a few weeks from his current assignment and reassign him to the defect until it is fixed.  But doing so might make the current client unhappy

 Option 2:After completing the current assignment, go back to earlier project, understand the defect and fix it.  This may not be possible as the defect is critical and needs immediate attention
 Option 3:Split time between the current requirement gathering work and fixing the defect.  It has been proven that  multi tasking reduces efficiency and productivity.      

Situations like the one mentioned above where the specialists have become bottlenecks have made the Agile thought leaders to encourage generalized specialists.

How to build Generalized Specialists ?

While I coach teams, I observe that if specialists are going to be shared across projects and by this I know that in the future they would end up becoming bottlenecks.In such instances,  I apply what is called “Backup Pattern”. This pattern name is my own invention. While applying this pattern, I start analyzing the skills and passion of various team members and start making each one back up for the other.  This provides an opportunity to have backups(in knowledge and skill) and over a period of time, these backups will be in a position to handle most of the specialists tasks.  However the same backup personnel  would continue to have their own specialization. The team members could volunteer to be backups.

Here is an example of a table showing my backup pattern technique

 

Module Name	Skills/technology	Primary	Backups
Billing	JSP, Java, Hibernate	Rashmi	Rohit, Chandru
Dynamic IP Generation	Java, C++, Tcp/Ip	Jim	Chandru, Rashmi
CMTS configuration	WAS, TCP/IP, REST, XML	Chandru	Jim, Rohit

Above technique has helped me in tackling the issues of specialization. This is not a quick fix, and it takes any where from couple of weeks to months to build a generalized team.

Conclusion

Having an extreme form of  all Specialists or Generalists is not healthy for any project.  There should be balance between these two types  and decision to have generalists or specialists should be based on specific context.  

Requirements considered harmful

Jeff Patton kept talking about usage of the word Requirements considered harmful during recently concluded Agile Bengaluru conference. When you listen to Jeff from his context and examples, you tend to nod your head in agreement.

Jeff has written a very nice article about the subject and I don’t want to copy/paste the article, and go ahead and read it here.

The Rise and Fall of the chaos report

 

One of the most popular reports people use to showcase failure of software development is the Standish’s chaos report .

In 1994, Standish reported a shocking 16 percent project success rate, another 53 percent of the projects were challenged,and 31 percent failed outright.  Even though the new reports from Standish show better numbers still they cause a lot of heartburn to software companies and investors.

However recently J. Laurenz Eveleens and Chris Verhoef  have published a paper in IEEE challenging the numbers stated by Standish report.   The major problems in the Standish report seems to be around the way numbers for the Successful and Challenged projects are gathered.   According to Eveleens and Verhoef, these Standish figures are:  

     “misleading, one-sided, pervert the estimation practice,
and result in meaningless figures”

The problem seems to be coming from the way the Successful and Challenged projects are defined.  The definition seems to have loop holes due to which many valid projects are not considered leading to wrong result.

 

You can read the entire IEEE report here