Donate to help Japan

Shojiki Solutions will donate $100 dollars to helping Japan for each registration to its training courses.

Alternatively please make a donation through any sponsoring agency.

Thanks.

Cutter IT Journal Issue on Kanban

The Viral growth of Kanban on the Enterprise

Kanban is becoming amazingly popular very quickly because of its accelerated rate of adoption and remarkable impact on organizations of all sizes. Such fast pace is both good and bad because it is benefitting organizations when adopted properly and because of the risk of doing it wrong by rushing an adoption without fully understanding it. For example, a frequently asked question on Kanban is whether it is a methodology for software development, or for software maintenance, or for project management, or a systematic approach to cultural change in the organization, or other. Another frequent question is if Kanban is the next logical step after Scrum and if that means Scrum should be done before doing Kanban. The March issue of the Cutter IT Journal contains articles that help answer questions.

The issue features an article by David Anderson, de creator of Kanban, with Arne Roock on aspects of Kanban adoptions. Taking Kanban adoption in Germany as starting and central point, they discuss how Kanban adoption has disseminated throughout the world and how cultural factors influence the rate of adoption. Anderson and Roock also describe the main reasons why Kanban should be used.

Allan Shalloway’s article on Demystifying Kanban gives us a panoramic view on what Kanban is and isn’t by comparing it with what he has been calling first generation agile methodologies, such as Scrum and XP, and discussing how Kanban overcomes their challenges. Allan has identified seven misconceptions on Kanban and discusses four of them at length and three of them in brief, then he concludes the article with a “test” to determine whether or not your organization is actually doing Kanban.

Dan Verweij and Olav Maassen, present the success story of Kanban adoption at an insurance company in the Benelux, in Western Europe. They describe how the insurance company went from a pilot project on Kanban to 20 teams doing Kanban in around 18 months as well as the reasons for the adoption, which include business, management, and operational reasons.  Verweij and Maassen discuss the difficulties encountered throughout the adoption and the various benefits obtained and conclude their paper with four recommendations to adopting Kanban.

The article on Kanban for help-desks, written by Rolland Cuellar, is around the context of what he calls “managing the unplannable” as a phrase to describe the challenges encountered at help-desk organizations. He explains why approaches such as waterfall and Scrum are not suitable for such type of activities, and how Kanban makes the cut for both help-desk and network operations organizations. Cuellar gives credit to limiting work-in-progress, a core property of Kanban, as an important differentiator useful to that kind of organizations and addresses other factors such as visualization. The result was a significant improvement on responsiveness and an increase in customer satisfaction.

Last but not least is the article on the use of Kanban on distributed onshore-offshore environments by Siddharta Govindraj and Sreekanth Tadipatri. The paper lists some difficulties on doing outsourcing and how Kanban is better suited than Scrum for it. The authors elaborate on how Kanban was applied and present nuggets of cases to illustrate the benefits obtained. They present s series of pitfalls and close with a discussion on cultural challenges encountered.

Playing increases productivity.

Last year I volunteered to translate David J. Anderson's book on Kanban into Spanish. Translating a book was a first for me and I had no idea what I've gotten myself into. Don't get me wrong, the book in itself is great and Kanban is an important part of my business. But translating a book is much  harder than I ever imagined.


Once the translation was finished the index needed to be created and that task was to be done by sometime else mainly because were couldn't find a tool able to easily generate it. Long story short getting the index done started longer than the translation itself because we couldn't find sometime to do it and it became clear that getting it done would end up being costly.


It occurred to me that maybe we could get a highly motivated student to do it well at a lower cost. I offered a high school student a third of the amount a professional would charge, which to him was to be the highest paying gig he had ever had, and I considered that to be enough of a motivator.


Taking advantage of a week- long school break we estimated the task would taking almost the entire week working full time. That became a turn off top the student who was looking forward to having some fun least pat of the time, but the money ease too good to pass. And so he began working on it at my office. I was keeping an eye on him and my main concern was the qualify of the work and likelihood of requiring longer time.


A couple of hours later I noticed  him doing things extremely quick. I went to his desk to check upon his progress and saw that not only everything was being done as expected but he was blasting away! I asked him how he was doing and he said "I am pretending this is one of my video games and figured out a strategy to do this with the minimum eye and keyboard movements." This was awesome! Although money was a good extrinsic motivator, he had found his own intrinsic motivator... to win the game.


He got done in just a day and a half. Upon reviewing the work done I noticed the need to do some time- consuming changes to improve the index and asked him to do a second pass, which he finished in less than one day. He was able to spend over half of the week having fun with his friends and having pocketed some good money, which he added to his savings to buy a semi- professional video camera.


Reading the Wired magazine this morning while enjoying a hot mocha I read an article about how the UK' s Guardian newspaper had the daunting task of analyzing 170,000 pages of bonus expenses and how reporters were, understandably, reluctant to do that. They then turned the task into a hammer and made it public. The result, over 2,000 people played it and the task got done in less than
four days.


One of the three core aspects of value innovation is to have an innovation fostering environment and the more work we do in the form of games is a great way to achieve that.

Perspiration, innovation, and success.

On a day like today, 164 years ago (Feb 11, 1847), Thomas Alva Edison was born. Most people know about Edisson as the inventor of the light bulb and the phonograph, and that he invented a bunch of other things (but have little to no idea what those other inventions are). He held a recortd 1093 patents! According to the Wikipedia, Edisson had only three months of official schooling--he dropped out amongst other things because he was considered "addled".

Edisson is also credited to have said "Invention is 1 percent genius and 99 percent perspiration"--he might have had quite a metabolism. But really, what made him do so much was a combination of high energy, a curious mind, and an amazing skill for making associations. Figuring out new, different ways to put seemingly unrelated things together and coming up with new applications to things that already existed or that he had invented were the skills allowed him to do so much. Just look at his inventions and you will see that most of them were incremental inventions; an invention was built from the results of a previous one. But that wasn't all, he was a great businessman and created an industry to support him, so the 99 percent perspiration was done mostly by all the workers he had at his factories and laboratories. A good number of the inventions and patents weren't a result of his ideas but rather the result of the collaboration with some of those workers; and some key ideas were actually from those people and not from Edisson himself.

Edisson's Menlo Park, NJ laboratory

Long before lean manufacturing and before Frederick Taylor, Edisson was pioneering mass production; most likely influenced by the raise of the Industrial Revolution and the works of Eli Whitney Jr., who make key inventions on machinery to automate some processes for the textile an milling industry.

Edison had an amazing insight on the importance to balance value to customer and value to the Enterprise to have a successful business. He also understood the importance of collaboration as a means to accelerate innovation. The conversations held with his most important workers and seriously consideration and analysis of what they proposed led to most of "his" inventions.

Today's organizations have fallen behind. They make employees work isolated inside cubicles and "teamwork" is rally a buch of people working by themselves on separate pieces of a product. Communication between groups in the organization is limited to orders and FYI's mostly. The groups building products have no direct, or very little, contact with customers or end users. The enterprise's priority is to make profit and not to satisfy users. As we try to turn things around applying Value Innovation, Lean-Agile, and Kanban we often confront strong resistance to change.  It seems some executives are so afraid of failure that they lost track of the fact that to move ahead of the competition and to succeed it is important to move away from the beaten path and do something new and different; and that to do so we have to be willing to invest and perspire,

Value Stream Mapping and a touch of reality

Rather recently I had a team from a customer create a VSM of their process. The usual steps: identify the different steps, or actions, of the process and their sequence; estimate the calendar task for each step; estimate the actual time it takes for each step to be executed; estimate the wait times between steps; identify and calculate loops in the process, if any; then calculate its efficiency by dividing the actual execution time by the total cycle time. I was shocked when they showed me their to be at close to 90%! I knew something wasn’t right, taking into account their own comments earlier during the training on the large number of projects they were running and the dependencies that sometimes taking up to months to resolve. I asked them to consider one typical project and recalculate.

It is very hard to imagine a highly productive team that is running close to 140 simultaneous projects with a staff of around 30 people, each project requires around ½ dozen staff members and takes between 4 to 5 weeks and up to 3 years to get done. 

Each post it is one project!

I explained to the team why although they are busy all the time their efficiency couldn’t be high. There was too much multitasking, frequent long waits, projects that were never finished because a dependency was never resolved, and projects that were either poorly finished or finished late because they had to improvise to pull it off when a dependency was not being satisfied by the corresponding stakeholder. With that in consideration the efficiency was 29.3% at best and most times under 20%. They agreed with this assessment and are now working towards implementing an actual Kanban system to help them control how much they are working on at a given time, improving communication, and figuring out effective ways of enforcing policies to reduce delays (hopefully eliminate them).

Using the Kanban game for time-boxed simulation

A few weeks back I read an interesting LinikedIn posting on how to do time-boxing using Russell's Kanban game. It is an interestig way to lean Scrum using a Kanban board.

I have yet to try to do that buy my hunch is that playing the game doing time-boxing will bring afloat some of the limitations of Scrum such as task management, the lack of classes of service and policies associated to them, the lack of a way to handle urgent tasks, and the fact that not all tasks are necessarily done within the time allocated.

La Mejor Manera de Probar

Esta es una presentación de Juan Gabardini sobre formas de hacer pruebas de manera Agile. Una version en texto está disponible en Software Guru.

http://softwareagil.blogspot.com/2011/01/la-mejor-manera-de-probar-en-agilesbsas.html