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

2011 Prediction

Masa's 2011 prediction as posted on the Cutter Consortium page

• A Move Toward Value Innovation

  Under pressure from the continuing economic crisis, enterprises are struggling to maintain their level of competitiveness, or even remain in the market. What has been considered key to success will begin to shift, from the search for effective methodologies to the realization that innovation and value are the most important differentiators for success.

  For many years, enterprises have considered effective management of scope, schedule, and budget as the key to success. This has been proven over and over to be incorrect. (Just ask the professionals you know. How many projects have they been involved with where scope, schedule, and budget were really effectively managed?) Furthermore, there are projects that accomplish this goal and still do not succeed. (Think "no sales.") The success-failure reports from some well-known firms are misleading because they are based entirely on those evaluation parameters and continue to guide enterprises in the wrong direction.

  One of the contributions of Lean and Agile has been the realization that emphasis on quality is much more important than the three parameters of scope, schedule and budget. More recently, attention has been brought to value to customer as the main driver to increasing the chance of success. These contributions are helping enterprises better evaluate what is considered success and what is considered failure. More successful products will be created as enterprises around the planet continue to adopt Lean and Agile. This success will not only help those companies flourish, but will also contribute to better the world economy. Observe, for example, the tremendous level of enthusiasm over Kanban and Scrum adoption in South America where the economy of countries like Brazil, Peru, and Chile is growing surprisingly fast. Entrepreneurs are seeing the benefits of Lean and Agile, and are adopting their methodologies at a rate that may match North America and Europe soon.

  Innovation has been brought in as the newest player. Value Innovation puts innovation, quality, and value together to better both the customer-facing and the business-facing sides of the enterprise, with particular emphasis on the human factors of competitive advantage and enterprise success.

  2011 will be a year of maturity in the way we understand success and the beginning of a change in direction to follow Value Innovation.

Book Review: Continuous Delivery

Book: Continuous Delivery

Authors: Jez Humble and David Farley.

Addison Wesley, 2011

I had two simultaneous impressions when I browsed Continuous Delivery. The first impression was “is there anything really new here?” and the second was “humm… I have actually never seen a book that puts together all these topics that do have an important relationship.” Throughout my career I encountered over and over the continuous struggle between diverse teams to successfully develop and deliver software. Communication, coordination, and collaboration have always been an often-ignored important factor that affects the effectiveness of organizations. Add to that the lack of a coherent infrastructure to make design, development, testing, integration, and deployment fit seamlessly and the end result is the nightmares way too many organizations deal with on a daily basis. I decided to read on because I appreciate the importance and complexity of those issues, years ago when I built QA organizations for diverse companies, and the last couple of years coaching and consulting enterprises in the adoption of Lean-Agile practices and the importance of Value Innovation.

Jez and David did a very good job at addressing the infrastructure coherence issues and propose effective ways to bring order. The novel aspect is not the fact that, say, good configuration management, continuous integration, and testing are very important to the increase of software quality, and to both managers and engineers mental health. The value is in the way to make this happen successfully and with minimal effort. They rightfully use the term Delivery Ecosystem and put together innovative thinking with strong bases on the importance to optimize the entire process, increasing quality, reducing technical debt and, best of all, making work life easier to technical stakeholders. The single automated pipeline approach is in agreement with current practices influenced by Lean and Agile.

Part 1 is a very god compendium of practices necessary to every software development organization, which the authors present as the challenges to deliver software. Jezz and David begin by presenting some release antipatterns and what to do about them. Then they address configuration management and continuous integration, where they describe diverse types and practices, pointing out essential characteristics and making suggestions to make them more effective. The last chapter of this part points out the importance of testing and explains it in terms of the test quadrants as proposed by Brian Marick and mention some real life situations.

Part 2 focuses on the deployment pipeline. Jez and David begin with its components—or anatomy—from practices to its stages. They did they right thing by including automated and manual test strategies. The following chapter focuses on scripting for build and deployment by first mentioning some build tools and then guiding the reader by the hand on the basics to get builds and deployments automated; and is complemented by a short chapter on the commit stage wraps it up. The next two chapters focus on testing, automated acceptance and nonfunctional requirements. These topics are not comprehensive due to the extent and complexity of the topics but the authors made a good job at bringing the key factors to motivate the reader to understand their importance and to explore further. This part is concluded with a chapter on deployment; an activity taken way to lightly most of the times and a main point of failure for most organizations. The authors cover zero-downtime releases, emergency fixes, and other.

The last part of the book is on the delivery ecosystem. This is the most important part of the book. I would say that very senior leaders and very senior technical staff with rich, broad and in-depth experience may be able to browse through Parts 1 and 2, but should slow down and read in more detail this part. This is the glue that puts things together.

Concluding. This is a vey good boo that should’ve been written many years ago to avoid so much waste and pain by so many technical organizations because it puts diverse parts of the software development organization puzzle together in a way they actually fit together. The only aspect I wish was also there, but isn’t, is the human factor. That is, how to get not only the complexity of processes and infrastructure to work together coherently, but also how to get the people behind the process and infrastructure to also work together coherently. In any case, that wasn’t an objective of this book.

Masa to give courses at The University of California at Berkeley

Masa to begin giving extension courses at The University of California at Berkeley in 2011.

Cutter Consortium 2011 Predictions

Here's the main page to Cutter's 2011 predictions:
http://www.cutter.com/predictions/2011.html

and here's my prediction posted on the same page:
http://www.cutter.com/predictions/2011.html#maedam

Kanban book in Spanish

The best book on Kanban: David J Anderson's is now available in Spanish
http://agilemanagement.net/index.php/kanbanbook/
Translated by Masa K Maeda


English Cover Spanish Cover

A case of Lean-Agile Kanban adoption with value innovation

I did Lean-Agile Kanban adoption with Value Innovation at a 90-people organization back in mid September. Around 60 people where at the headquarters and the other 30 at a neighboring city just a 1.5 hour drive away. The training was given at the headquarters with the away team receiving instruction remotely taking advantage of the remote-training infrastructure they themselves developed. I myself didn't feel very comfortable with the remote training because my training technique includes doing games and, believe me, conducting team games for training purposes remotely is not for the faint of heart. Even more so when you also have a group to teach in person.

Coaching followed the training. The local group was difficult to train and coach because they allowed themselves to be distracted and continuously left the room to attend work related matters, even against my strong recommendation to focus entirely on the training by pretending they were doing this out in San Francisco instead of at their offices farther south. To make matters worse, the coaching wasn't done at their work area but at a training room with mixed teams. As result the employees and leaders treated the coaching as if it wasn't part of their every-day activities and the results weren't carried to their actual work. And then, there was lots of politics going on such that the leaders were more focused on how to position themselves to get a higher position in the coming elections than on getting the job done.

The remote group, on the other hand, was less preoccupied with political capital and more concerned with operations. When I got to their offices to do the coaching I was concerned with how effective it could be given how limited the success of the remote training was. The group was somewhat disfunctional. It became clear to me that they were segregated. Teams did not communicate or collaborate well. Leaders and individual contributors did not communicate well. It was a typical command-and-control environment. They continuously struggled to get projects finished and had a long list of pending projects.

Instead of going straight to the Kanban face-to-face training I started by conducting exercises to remove the communication and collaboration impediments. Fist, I conducted some NLP exercises to get them to mix and talk to each other at same level (no hierarchies or roles). Then I got them to create a snapshot of the organization using innovation games. By then they were already communicating much better. Next activity was to crate a value-stream map of their core process and by the time they were done the director told me this was the first time in the history of the organization that everybody knew the entire process in detail, him included. I proceeded to solidify lean-agile thnking some more. The following day we talked about Value Innovation and then worked on learning Kanban.

I followed up via email with the teams. The teams at headquarters didn't carry on any activities but the other group did put effort on the adoption, not without struggle, but keeping in close communicaton with me they managed to get Kanban implemented. I visited them last week and was no less than astonished by the amazing implementations they have made. They started with one Kanban board to get all in synch and then implemented custom team Kanban boards that were in agreement with the common board to communicate efficiently. One team actually had two team boards and each team member had his own board in perfect synchronicity without any extra effort. The team they interacted with had its own two boards also in agreement with the other team's main board. It was a mastery of coordination. They asked me some fine tuning questions.

There was one team whose manager deviated from Kanban, not on purpose, in an effort to be original and creative. Nor surprising, this team was struggling to get things done smoothly. I gave my opinions and recommendations to the team, and then talked to the manager in private to help him realize the creativity has to go towards adding value rather than over thinking a Kanban design and letting the Kanban board evolve naturally. We spent the rest of the day digging into the activities around the Kanban board: the meeting, analysis, discussion, decision-making, and execution.

A director from headquarters had joined me on this visit upon instructions from the CEO, who had considered making a dedicated effort to bring Kanban to the most progressive team at headquarters after I reported to him the progress at the remote location. The director was so impressed that on the way back to headquarters discussed with me a strategy to make the adoption at the entire headquarters instead of just one team. :-)

In a Kanban Adoption, Go Lean

Recent posting on the Cutter blog

http://blog.cutter.com/2010/12/06/in-a-kanban-adoption-go-lean/

A Halloween Story: The Imminent Death of an Enterprise

My last blog posting on Cutter...

http://blog.cutter.com/2010/10/29/a-halloween-story-the-imminent-death-of-an-enterprise/

It's begining to look a lot like Christmas... I mean Kanban

There was a workshop on Technical Debt this morning at the 2010 Cutter Summit in Cambridge, MA, Given by Israel Gat and Jim Highsmith. It was a good one, although short, in which several important points were discussed and I decided to blog on one specific point.

Towards the end of the workshop Israel proposed an event-driven process control (EDPC) based on the Ken Schwaber's process control view of Scrum. The fundamental idea is to replace the daily scrum meetings with on-demand meetings triggered by failure events on the project's continuous integration activity. That is, daily standups are to be no longer and instead the meeting will occur between all stakeholders involved with the failure at continuous integration time. This is motivated by the lean manufacturing modus operandi of stopping the production line when a defect is detected. The determinant is created by using Statistical Process Control over defects, in which the trigger is a policy. Israel emphasized on the fact that quantitative data enhances the power of scrum to reduce technical debt.

This was a rush of fresh air. Kanban does that! ...and more. Anyway, the point is, as agile methodologies mature they are gradually moving towards where Kanban already is. Kanban offers quantitative metrics such as statistical process control over delivered value and other policy-driven factors, cummulative flow, mean lead time, and other.

Follow these leaders

From Chrstopher Avery:
Follow these leaders @gilbroza @CoachingLeaders @masaKmaeda @Leadership_Gold @Mark_Sanborn @VoxLive @Leadership__101 #ff

Rapid Maturity on sight

I did Lean-Agile Kanban adoption with Value Innovation at a 90-people organization back in mid September. Around 60 people where at the headquarters and the other 30 at a neighboring city just a 1.5 hour drive away. The training was given at the headquarters with the away team receiving instruction remotely taking advantage of the remote-training infrastructure they themselves developed. I myself didn't feel very comfortable with the remote training because my training technique includes doing games and, believe me, conducting team games for training purposes remotely is not for the faint of heart. Even more so when you also have a group to teach in person.

Coaching followed the training. The local group was difficult to train and coach because they allowed themselves to be distracted and continuously left the room to attend work related matters, even against my strong recommendation to focus entirely on the training by pretending they were doing this out in San Francisco instead of at their offices farther south. To make matters worse, the coaching wasn't done at their work area but at a training room with mixed teams. As result the employees and leaders treated the coaching as if it wasn't part of their every-day activities and the results weren't carried to their actual work. And then, there was lots of politics going on such that the leaders were more focused on how to position themselves to get a higher position in the coming elections than on getting the job done.

The remote group, on the other hand, was less preoccupied with political capital and more concerned with operations. When I got to their offices to do the coaching I was concerned with how effective it could be given how limited the success of the remote training was. The group was somewhat disfunctional. It became clear to me that they were segregated. Teams did not communicate or collaborate well. Leaders and individual contributors did not communicate well. It was a typical command-and-control environment. They continuously struggled to get projects finished and had a long list of pending projects.

Instead of going straight to the Kanban face-to-face training I started by conducting exercises to remove the communication and collaboration impediments. Fist, I conducted some NLP exercises to get them to mix and talk to each other at same level (no hierarchies or roles). Then I got them to create a snapshot of the organization using innovation games. By then they were already communicating much better. Next activity was to crate a value-stream map of their core process and by the time they were done the director told me this was the first time in the history of the organization that everybody knew the entire process in detail, him included. I proceeded to solidify lean-agile thnking some more. The following day we talked about Value Innovation and then worked on learning Kanban.

I followed up via email with the teams. The teams at headquarters didn't carry on any activities but the other group did put effort on the adoption, not without struggle, but keeping in close communicaton with me they managed to get Kanban implemented. I visited them last week and was no less than astonished by the amazing implementations they have made. They started with one Kanban board to get all in synch and then implemented custom team Kanban boards that were in agreement with the common board to communicate efficiently. One team actually had two team boards and each team member had his own board in perfect synchronicity without any extra effort. The team they interacted with had its own two boards also in agreement with the other team's main board. It was a mastery of coordination. They asked me some fine tuning questions.

There was one team whose manager deviated from Kanban, not on purpose, in an effort to be original and creative. Nor surprising, this team was struggling to get things done smoothly. I gave my opinions and recommendations to the team, and then talked to the manager in private to help him realize the creativity has to go towards adding value rather than over thinking a Kanban design and letting the Kanban board evolve naturally. We spent the rest of the day digging into the activities around the Kanban board: the meeting, analysis, discussion, decision-making, and execution.

A director from headquarters had joined me on this visit upon instructions from the CEO, who had considered making a dedicated effort to bring Kanban to the most progressive team at headquarters after I reported to him the progress at the remote location. The director was so impressed that on the way back to headquarters discussed with me a strategy to make the adoption at the entire headquarters instead of just one team. :-)