Shojiki Solutions Blog

Kanban for customer portfolio management

2012-01-23T10:14:00.000-08:00

My business focuses on lean-agile coaching, consulting and training, not on software development services, and I successfully use Kanban to manage my customer portfolio.

It is untrue that Kanban is only good for software change management work. Many people new to Kanban have this misconception mainly for two reasons. One is because Kanban started in a change management team at Microsoft. The other one is because David J Anderson declared that Kanban is a method for change management in the organization and that statement can be misinterpreted. What David meant with that is Kanban helps you bring positive change to your organization. Although the original Kanban description is around software it is actually context free. There is a very popular book entitled Personal Kanban by Jim Benson that I invite you to consult.

Getting back to the main subject of this blog. I have been using Kanban for years to manage customer-facing and business-facing activities. The customer facing activities Kanban board has one swim lane per customer for easy visualization of the activities with each customer and to avoid making mistakes on which customer a given activity is for. Each customer has its own backlog, which we make visual as the first column on the board. The other columns are Ready, Execute (doing/done), Customer verification, and Completed columns. The WIPs for each customer are different and in agreement with the customer needs and my resources. The figure shows the electronic board we use. We actually have several boards, one for each country. Advantages of the electronic board are not only the fact that they make remote communication easier but also that it allows us to resort the lanes, which we do as a means to indicate level of priority and activity. That is, a lane (a customer) bubbles up if the activity and priority increases and bubbles down if the activity decreases. That way if we will not be doing any work with a customer for a while its lane is "out of the way" and is still easily available to reuse at a moment's notice. We also count with a swim lane called "other" and we use this for general work that has to do with potential customers when relationship hasn't matured yet to the point of earning a dedicated lane.

Our classes of service are

Business task
Business appointment
Business partner / associate task
Fixed delivery date
Immediate

Intangible tasks are business-facing and are, therefore, on a separate board.

Cheers,
Masa K Maeda

Swift Kanban free for non-for-profits

2012-01-19T12:18:00.000-08:00

Nice move from Digité, the company behind Swift Kanban. It offers free licensing to non-for-profit organizations and also recently added integration with Jira from Attlasian.
To read the full article click here

Presentación en LiderDeProyecto.com para PMI

2012-01-05T14:00:00.000-08:00

Presentación en Español sobre Lean y Kanban para PMI
http://www.liderdeproyecto.com/videoboletin/video077-gestion-lean-agil-de-proyectos.html

Short video series

2012-01-05T13:50:00.000-08:00

I started a Valueinnova video series and will be posting regularly. Subscribe to it and you won't miss them.

Btw, all the videos have English and Spanish versions.

Shojiki Solutions is now Valueinnova

2012-01-05T13:48:00.000-08:00

Happy 2012 !

With the new year also came a new name for our company, we are now Valueinnova.

Visit us :-)

Lean Value Innovation in a little tiny nutshell

2011-12-24T11:39:00.000-08:00

Whoa, it is almost the end of the year and it has been a long time since I posted anything on my blog. I know it is no excuse, but I actually spent most of the last half a year outside the US and that made it very difficult for me to pay attention to the blog as much of my time was focused on delivering value to my customers.

There is, however, one very important announcement I want to make. Shojiki Solutions is changing its name to Valueinnova LLC (www.valueinnova.com) effective January 1, 2012. This is actually good news, because the company has been moving forward and now that I have been maturing Lean Value Innovation it makes perfect sense to align the company to what set us apart from the competition.

In a nutshell, Lean Value Innovation is a framework indicating that in order to effectively increase value delivery to customers as well as to our organization it is necessary to take care of for aspects:

To improve the way we think and see things through systems thinking. This includes the system of profound knowledge, lean thinking, agile thinking, and creativity.
To improve our environment both in the physical sense and the collaborative sense.
To adopt methods and tools that facilitate innovation.
To fully embrace the notion that the human factor is the most important aspect to consider if you want our organization to be successful.

I am spending these days writing a book on the subject and hope to get it ready soon.

Cheers and happy holidays to everybody.

Lean Kanban Central Europe useful links

2011-10-22T09:50:00.000-07:00

For those who didn't have the opportunity to attend LKCE11 here's some useful links

Session visual facilitatings
http://www.lean-kanban-conference.de/visual-facilitating/

Sessions description and slides
http://www.lean-kanban-conference.de/program/

My presentation al Lean Kanban Central Europe 2011

2011-10-18T13:07:00.000-07:00

I will blog comments as soon a I have time to do so (I am still moving around quite a bit between Spain and Germany).

Thank you Steve Jobs

2011-10-07T23:17:00.000-07:00

High Performance Operations book review

2011-10-04T23:17:00.000-07:00

I had the pleasure and honor of receiving an advance copy of Hillel Glazer's book High Performance Operations for review. What follows is my unbiased opinion.

This book is bout an approach to make of compliance an actual competitive advantage through an integration of "cultural/psychological and interpersonal matters, service, and systems engineering". Hillel calls it Process Solutioneering. Hillel's writing style is very enjoyable and engaging.

As the title implies, the book focuses on compliance aspects that have to do with operations. Very important aspects that way too often affect organizations because of misconceptions on compliance are addressed here. For example, I recently had a customer who has a CMMI process that is making it take over a month of work on a task that requires less than one week of DB work and less than 30 min of coding in java. Hillel points this kind of situation as a common behavior because many companies do not count with compliance methods that scale to the work at hand. He also mentions bureaucracy, personal interests, operational complexity and other.

The core aspect of the book is it offers a set of patterns to keep compliance while at the same time also improving operational performance to gain competitive advantage.

The book begins with a motivation and an overview that provide a comprehensive fly-by of the entire book. Chapter four introduces the "how". 10 necessary factors that must exist in an organization to achieve excellence in high performance operations. Chapter 5 is about time, quality and money from the perspective of regulation and compliance and about mind setting. We should focus on guiding out thoughts and actions in the desired direction, not on thinking about avoidance of unwanted direction. Chapter 6 is about people and organizations focusing on compliance for the sake of status. Be it to show off or to get more contracts but not to really improve. It also talks about value streams and their economic impact at compliance level. Chapter 7 is about understanding the right purpose of compliance practices, which goes way beyond the verbatim application of the practices. On Chapter 8 Hillel introduces a 5-step-action "procedure to better understand the wisdom behind the practices stemming from compliance requirements". Chapter 9 is about value. this is a particularly attractive topic to me because it is focal to what my own business is about. HIllel's perspective is well-aligned in that it considers the business and customer facing value. Chapter 10 is a follow up of Chapter 9 on which he provides a guide to identify the operational system and explains the importance of performance management quantification to sustain value. My interpretation of chapters 11 to 15 is they are the set that covers Operational Excellence considering the systems engineering, service, and cultural/psychological and interpersonal matters. Chapters 16 to 18 are the wrap up. How to check the business performance and improvements, An integrated architecture that includes human factors and infrastructure. And what to expect when you do all this.

In conclusion. The book is not a technical masterpiece (it isn't intended to be so) nor a recipe to follow step-by-step. It is a combination of awareness booster and guidance to take as a foundation to modify the organization's behavior surrounding compliance.

I recommend this to all organizations that operate, or are considering to operate, under some sort of governance.

You can learn more about this topic at http://www.hillelglazer.com/

Quotable Kanban book by Janice Linden-Reed

2011-09-19T14:01:00.000-07:00

Quotable #Kanban book is out http://bit.ly/puYJHD congrats Janice!

Processclerosis

2011-09-15T13:43:00.000-07:00

I began working with a customer rather recently whose line of business is software development for very large banks. my relationship with them began with a training course on lean-agile project management that led to coaching.

They were very happy and proud to have reached CMMI L2 one week before I began working with them.

The CEO agreed with my recommendation to bring Kanban in and after two days of training we began working on a new, small project. As result of their new CMMI status there was an executive decision to display large posters with their current processes throughout the company to bring visibility and ensure everybody followed process.

I decided it would be good to begin with the creation of an actual Value Stream Map for the project. The team created it based on their CMMI process, as expected, and discussing the action details for the project. The resulting VSM is shown below. The orange cards are the steps, the blue cards are one per stakeholder, and the yellow cards are actions; so we have 8 steps with between 4 and 9 stakeholders per step and between 3 and 17 actions per step. In total there are 90 actions.

Most of you might be thinking something along the lines of "wow, is that a small project?" I was equally puzzled so I asked one of the team members to explain it all to me (I was at a meeting with executives while the map was being created). What called my attention from her explanation was that only two of the action cards actually had to do with coding! There were a few other technical actions but over 80% of the actions had nothing to do with the project itself and everything to do with process. As in, non-value-added process.

I decided to guide them through questions to help them realize the tremendous amount of waste they had but nobody in the team, including the manager, saw an issue with their process. I then asked them how long it would take to do the coding... and they said it would take at most 30 minutes (their bet was 10 minutes). So we have a 90-action process that requires up to 9 stakeholders for a customer request that takes at most 30 min of technical work.

It was clear then that they were still high from their recent CMMI L2 accomplishment and weren't seeing the obvious so I asked them to create a Kanban board and use it to manage the project flow making sure to quantify their actions from day one. This meeting took place on a Tuesday and the intention was for the project to be done by Friday or Monday at the latest. They revealed that some DB work also needed to be done and that would take several more hours of work so it appeared as if the value-added work was to take in reality less than one day. My recommendation was to get the information as directly as possible from the customer, implement the code with the proper testing and deploy it. Their CMMI process should've considered lightweight solutions in agreement with the size and complexity of the project instead of having a one-size fits all process.

I had one remote meeting a few days later to see if they had finished and to use the quantification gathered to help them realize their process needed improvement. But they hadn't even written the WIPs on the Kanban board, which we had already determined, and even less using it because they were focused on just executing away. This showed how the company is yet to properly use tools and methods and how and what they had accomplished with CMMI was being seen as an after-the-fact formalization to comply with governance. The second meeting took place three weeks later only to learn that they have 82 items in backlog and 26 in progress and 3 finished --new action cards were created. Then they made the mistake of changing the Kanban board to look the way they want things to happen and not the way they are actually happening, and the clear opportunities for improvement were being lost by their decision to remove the columns where delays were happening. I had a long conversation with them to modify the Kanban board and to work on those improvement opportunities because their delays were precisely due mostly to them and if nothing was done then the small project is going to end up taking over a month! The quantification gathered so far showed very clearly the high level of waste by the large number of actions yet to be processed and the long cycle times.

I emphasized on the need to make sure the Kanban board is a mirror of their reality and that by removing columns they were letting go of amazing opportunities to better the quality of their work and the lengthy cycle time. Most importantly, they were ignoring to consider everything that's happening around the board, their decisions and actions, or lack of them, and the impact it is having in both customer satisfaction and the economy of the project.

Quantification began 8 days late, when the project was expected to have been done. There are plenty of opportunities for improvement, some very important ones related to their customer, but internal changes need to happen first before they can talk to the customer and make agreements to improve.

Note: I Had the opportunity to show the VSM photo to Hillel Gazer and he commented that this is a very common problem in organizations that do CMMI and the problem is due to a combination of a poor understanding from the organization and in good measure because maturity evaluations are often done by-the-book instead of based on understanding to help the customer do it right.

I'll write an update as this project develops and how the company matures.

--- Update: as of Nov 4, 2011 the project is far from finishing. The company indicated over a skype meeting I had with them that the delay is because customer approval is the bottleneck. They are not being proactive towards helping change behavior even when now they count with data to present their customer the economic impact this is having for everybody. Curiously, they themselves are reluctant to change and seem to want Kanban to magically improving things without any changes.

The 3 principles of the Kanban Method

2011-09-15T11:53:00.000-07:00

This is from an email exchange that took place within the last 24 hours.

[David Anderson]:

Yesterday I changed this language in my keynote in Zurich...

While they are core or seed properties (for a complex adaptive system) they are also practices. In the interests of promoting common language I am now calling them "core practices" or Alistair Cockburn has suggested "Imperative practices".

The 3 principles of the Kanban Method are...

1. Start with what you do now

2. Agree to pursue incremental evolutionary change

3, initially respect current processes, roles, responsibilities and job titles

Customer satisfaction is king

2011-09-09T21:43:00.000-07:00

Customer satisfaction is king. Policies on cadence-based continuous flow delivery are a golden gift to the king.

Kanban actions when encountering a bottleneck.

2011-06-26T07:36:00.001-07:00

What kind of actions should be considered to take care of a bottleneck?

- Are the people on the immediate upstream doing things right or rushing them?

- Do we need to add a buffer?

- Is this something temporary so doing nothing is the right thing to do?

- Is the root cause somewhere farther upstream?

- Do we change WIP?

- Do we reallocate human resources?

Note: this list is not exhaustive.

In the need of scientific proof

2011-06-26T07:29:00.000-07:00

I was reviewing the feedback sheets from a course I finished two days ago and one of them called my attention. There was a comment indicating I should've given scientific evidence to explain why lean and Kanban work. I understand how compelling it is to count with scientific proof; however, no having scientific proof of something is not sufficient to say something didn't work.

Most things that work are followed by a scientific explanation and not the other way around. Even when no scientific proof is available, should we stop doing something that works?

Lean and Kanban work because they tackle projects from a systems perspective and because they also pay attention to the human factor. That is, they go beyond just the project to find opportunities for improvement and do root-cause analysis. They see projects and people as complex adaptive systems better than other approaches.

The longer professionals demand solutions that are heavily rooted on scientific proof the longer it will take them to realize the huge potential they are missing and will continue to struggle with projects more than is necessary.

Btw, that same person gave me a low score on "being on time" even though I was there 30 minutes before start time every day of the course and kept the lunch break times as agreed. Oh!... wait, maybe my score would've been higher if I had allowed more time for lunch.

Lean-Agile Project Management Certification and Kanban training in Panama

2011-06-13T18:28:00.000-07:00

I spent between May 26 and June 7 (with a break in between to go to Peru to give Kanban training) to give a Lean-Agile Project Management Certification course and a Kanban course in Panama to a small group from the telecom industry.

All participants loved the topics and the training. They also arranged for me to give a presentation at Telefónica in Panama and then a remote presentation at Telefónica Guatemala.

Look forward to the outcome...

Bringing Lean and Kanban to Peru

2011-06-13T18:19:00.000-07:00

I spent June 1~3 bringing Lean and Kanban to Peru.

June 1 was a presentation on Lean and Kanban at the Universidad Peruana de Ciencias and June 2~3 was to give Kanban training to a group of highly motivated people from Agile Peru, Academia and industry.

Both activities were quite successful and I look forward to being back to Lima both for training and to do business.

3rd PMI Panama Project Management Congress

2011-06-13T17:48:00.001-07:00

May 25-26 was of high-activity at the El Panama hotel, where the 3^rd PMI Panama Project Management Congress took place. Panama City is a very active place with a blooming economy. New business buildings are under construction and there are more jobs than people to take them. The boost in the economy is mainly due to the ongoing Panama Canal traffic plus its current expansion and the banking industry.

The congress had around 300 participants attending the congress days and then there was a workshops day on May 27. There were 4 keynotes: on management by Jeff Hodgkinson; on the future of management in Panama by Eduardo Jaén; on the subway project for Panama by Roberto Roy; and on the project management effort to recue the 33 miners trapped in Chile by Hugo Constanzo. All keynotes were worthwhile but I want to give special mention to Constanzo’s for its incredible success regardless the high stakes and low odds it confronted—and Constanzo’s high humanity and humility which shows his quality as a great manager and an exceptional human being.

There were a total of 24 sessions on diverse topics from the very practical to the conceptual, techniques, experiences, government projects, and other. My presentation was on agile and lean as a means to better handle project cycles and implement an evolutionary approach to management.

The three workshops offered where on Authentic leadership for breakthrough results by Hawk Carpenter; A sixth sense for project management by Tres Roeder; and Practical lean-agile and innovation for managers by yours truly. All workshops were successful and I was flattered by the fact that my workshop got the highest attendance and ranking of all. I hope to get the opportunity to give this same workshop at the SFBAC soon.

LSSC11 Report

2011-06-13T17:47:00.000-07:00

The Lean Software and Systems Consortium 2011 Conference took place last May 3-6 in Long Beach, California. This third conference was very impressive in more than one way. The conference grew 6 times since the 1^st conference for a total of over 800 attendees from all over the world, literally; it lasted 5 days (day one was for workshops and a day long Technical Advisory Board meeting); 21 sessions/panels per day; daily keynotes; topic-games room; Open Space; Intoductory talks; and tools showcase. Even more important were the countless conversations and discussions on aisles and halls. The event was organized by NetObjectives, led by Allan Shalloway, and by David J Anderson & Associates.

The Brickel Key awards banquet was quite an event, with six world-class candidates. In alphabetical order Siddharta Govindaraj (India) for his toolsForAgile software, Russell Healy (New Zealand) for his GetKanban game, Chris Hefley (USA) for his LeanKitKanban tool, Richard Hensley (USA) for his work on Kanban with CMMI, Mattias Skarin (Iceland) for his work and publications promoting Lean and Kanban, and Yuval Yeret (Israel) for his contribution bringing Lean and Kanban to Israel. The awards went to Russell Healy and Richard Hensley. The diversity of origin from the candidates is proof of the worldwide impact of Lan and Kanban.

Presentations covered familiar topics such as adoption and improvements as well as new topics such as lessons from the military, psychology, chaos, innovation, and risk. I myself had the opportunity to present Lean Value Innovation. All sessions were recorded and will be made available by mid June at http://www.leanssc.org/membership/ were some content will be available for the general public on a rotating basis and all content will be available to members.

To many attendees this was the best conference ever, and I agree with that opinion.

Lean Kanbann Jazz and Origami

2011-06-13T17:39:00.001-07:00

Proposal session sent to Lean Kanban Central Europe 2011 conference.
http://www.lean-kanban-conference.de/

Abstract:

What do Lean, Kanban, Jazz and Origami have in common... and where do they differ? In this presentation I will talk about important aspects of Lean and Kanban that I consider to be key to their success and to be what sets them apart form other approaches and methodologies such as Agile and Scrum, yet could be easily ignored. This is very important because ignoring them as Lean and Kanban gain popularity will result in failed adoption at organizations. I use Jazz and Origami as metaphors because they greatly facilitate the understanding of those key aspects. I will also be introducing the term Understanding Worker and the phrase Think Outside The Kanban Board .

Nota breve sobre Scrum, Lean y Kanban

2011-05-15T23:18:00.000-07:00

Este blog es para personas que desean aclarar su entendimiento sobre Scrum, Kanban y Lean.

Lean no es una metodología; es un fundamento basado en pensamiento en sistemas y en el sistema de conocimiento profundo a partir del cual se han generado prácticas y métodos tales como Kanban. La primer premisa fundamental es el mejorar todos los aspectos de la organización y no tan solo el buscar resolver problemas identificados. Esto es muy poderoso porque con mucha frecuencia el origen de un problema no está donde el problema se expresa sino en algún otro lugar; y porque una mejora que no toma en cuenta el contexto completo puede generar desbalance en otras áreas de la organización. La segunda premisa es el eliminar todo aquello que no agrega valor; resultando en mejoras en aspectos tales como productividad, calidad y satisfacción de clientes. Lean va más allá del contexto de desarrollo de software y considera a todos los stakeholders involucrados en la organización o el proyecto, por lo que no tan solo el proyecto es beneficiado.

Agile es un subconjunto de Lean y consiste es un una serie de valores y principios seguidos por una serie de metodologías de las cuales Scrum es la más popular.

Scrum se enfoca en la entrega de valor al cliente en intervalos fijos y logra esto mediante el aislamiento del grupo técnico para asegurar que se mantengan enfocados en completar las tareas a tiempo. La relación con el cliente es mediante un punto de contacto singular. La estructura de Scrum es fija y no toma en cuenta las necesidades particulares de cada proyecto. El ímpetu de hacer los intervalos auto-contenidos dificulta la implementación de ciertas tareas. Scrum no considera situaciones de la vida real que requieren de tratamiento especial tales como trabajos urgentes. Así mismo, Scrum no escala fácilmente por lo que es adecuado solamente para proyectos pequeños. La manera en que Scrum trata la escalabilidad es ya sea llevando a cabo lo que se conoce como Scrum de Scrums, o bien mediante la necesidad de contar con múltiples product owners; y en ambos casos el monto de tiempo de juntas de Scrum es incrementado y el monto de conocimiento sobre el proyecto entre stakeholders se reduce. Scrum no provee visibilidad sobre el proceso y tampoco sobre el estado actual del proyecto, por lo que es difícil identificar oportunidades de mejora. Esto quiere decir que Scrum es estático y no provee mejoras mas allá de lo logrado cuando fue implementado por primera vez. Scrum confronta alta resistencia al cambio en parte porque requiere el abandonar las prácticas actuales de la organización para implementar algo nuevo y distinto, lo cual tiene mayor riesgo y costo que una transición suave. La resistencia al cambio también tiene que ver con la introducción de nuevos roles y responsabilidades, lo cual hace que personas en la organización se puedan sentir retadas o amenazadas de alguna forma debido a la incertidumbre de la manera en la que tal cambio afecta sus carreras profesionales.

Kanban se enfoca en la entrega continua de valor tanto para con el cliente como para con la empresa. Es altamente visual y transparente por lo que todos los stakeholders tienen acceso al estado real del proyecto, facilitando la toma de decisiones a todo nivel. La alta visualización facilita la identificación de oportunidades de mejora por lo que tanto el proceso como los grupos involucrados pueden operar a nivel optimo en todo momento y el proceso evoluciona gradualmente conforme el proyecto progresa. Kanban mantiene una disciplina sobre el monto de trabajo en progreso que mejora significativamente el valor generado y entregado gracias a su alto enfoque en calidad, resultando en mayor trabajo terminado en el mismo monto de tiempo. El flujo de trabajo puede ser medido, analizado, y gestionado tal que las características de mayor valor son entregadas primero. Kanban cuenta con políticas de proceso explicitas tal que la comunicación y colaboración se hacen mucho más suaves y fáciles, reduciendo significativamente la posibilidad de error humano. Kanban trata de manera distinta los distintos tipos de tareas que contienen los proyectos por lo que, por ejemplo, tareas urgentes pueden ser tratadas adecuadamente sin la necesidad de salirse de la metodología o generar excepciones, evitando así el desbalance y la pérdida de disciplina. Métricas cuantitativas facilitan el análisis de comportamiento para la identificación de causa raíz, y la implementación de soluciones es fácil y rápida. Debido a que los cambios son continuos, pequeños y graduales, el sistema completo evoluciona (stakeholders, proceso, y organización). De hecho existen casos en los que organizaciones han madurado el equivalente a dos niveles de CMMI en menos de un año. Kanban no confronta resistencia al cambio porque no hay cambios de roles y porque el punto de partida es el proceso actual. Kanban escala fácilmente porque la junta diaria (el equivalente a la junta de Scrum) no requiere ser multiplicada y su duración no requiere ser incrementada para mantener su eficiencia. Por último, Kanban considera aspectos económicos de la actividad relacionada con el proyecto, tales comos costos de retraso, de transacción, de operación y riesgo.

Un malentendido sobre Kanban es la creencia de que se aplica solamente en proyectos de mantenimiento. Kanban es un método para la gestión de cambios necesarios para madurar la organización. De hecho, es tan efectivo que también ha sido utilizado en áreas fuera de desarrollo de software, tales como recursos humanos, administración, salud, educación y hasta en oficinas de abogados.

Otro aspecto importante a considerar es el hecho de que lean y Kanban son sistemas abiertos que permiten la utilización de una variedad incremental de herramientas para mejorar organizaciones, independientemente de si son ágiles o no.

En septiembre de 2010 llevé a cabo un estudio sobre adopción de Kanban a nivel mundial por medio del Cutter Consortium. Los resultados muestran que a pesar de ser relativamente joven, Kanban está siendo adoptado ya en todas las regiones del mundo y que esta generando mejoras en satisfacción de usuarios, calidad, y productividad fueron reportadas por un 59%, 63.6%, y 71.1% comparado con Scrum.

Kanban está siendo adoptado por empresas de todo tamaño: desde menos de una docena hasta de mas de 100,000 empleados (este último número reportado en la conferencia LSSC11 a principios de Mayo de 2011).

Es posible adoptar lean sin Kanban y viceversa, pero la combinación de ambos tiene mucho mejor resultado.

Scum y kanban no son mutuamente exclusivos. Ambos pueden ser implementados en la organización y ser compatibles. A fin de cuentas todo depende de las necesidades de la empresa.

LSSC11 -- the day before.

2011-05-02T22:17:00.000-07:00

Awesome weather here at Long Beach the day before the start of LSSC11.

It was great to meet with friends again and to get to meet in person some people I knew only remotely, such as Olav Maassen who wrote an article for the special issue on Kanban of Cutter's IT Journal I had the pleasure of being the guest editor for.

I also had the pleasure of meeting Donald Reinertsen and spent one-on-one time talking about cost, WIP, and lean.

Tomorrow the LSSC11 begins with tutorials and with a Technical Advisory Board.

One week to LSSC11 -- Register now!

2011-04-28T09:24:00.000-07:00

We are only one week away from the LSSC11 Conference.

This is the place to go to to get up to speed on Lean and Kanban.

Masa recognized by the Lean-Kanban Univeristy

2011-04-27T15:42:00.000-07:00

Masa is listed as part of the services offered by the Lean-Kanban Univeristy

http://www.leankanbanuniversity.com/masa-maeda

SFBALWS invited speaker Siddharta Govindaraj

2011-04-26T19:51:00.000-07:00

The May meetup of the San Francisco Bay Area Limited WIP Society is having Siddharta Govindaraj as invited speaker.

Topic: Using Class of Service for Managing Risk in Innovative New Product Development

Date: May 12

Time: 7:30 PM

Location: Thoughtworks

315 Montgomery San Francisco, CA

Make sure to RSVP indicating your name and affiliation. Security will be given a list to grant access to the building.

Improving People and Processes

2011-04-25T17:11:00.000-07:00

Improving People and Processes: Lean-Agile, Systems Thinking, and the System of Profound Knowledge

by Masa K. Maeda, Senior Consultant, Cutter Consortium

Click here for the full executive summary

Click here for the full executive report

Organizations deal with pressure on a daily basis. Executive and managerial pressure frequently comes in the form of on-time delivery, cost cuts, and scope coverage; customer pressure usually comes in the form of feature requests and better quality; employee pressure continually asks for more time to finish tasks, fewer work hours, and better guidance.
Some organizations consider those kinds of pressures to be part of the daily corporate life and end up just bearing with them. Most of those organizations eventually collapse because lack of improvement puts them further behind over time. Other organizations take a proactive approach to better the organization. Some of those actions could be localized to focusing on ailing areas or could be of global scope and higher impact, such as replacing the organization's governance standard or model or adopting one if the organization didn't come with it already. Or it might mean replacing entire teams or migrating entire operations to other countries. In the accompanying Executive Report, I present, in detail, a better means to improve your organization through the improvement of people and processes, taking into account excellence, quality, and value through the application of lean-agile thinking, systems thinking, and the system of profound knowledge (SOPK).

The term "improving the whole" is not an if-you-only-have-a-hammer approach but rather the acknowledgement that we can acquire a way of thinking that broadens our perspective to look at our organization, processes, and people. It allows us to understand the kind of tools we need to continually better them.

Analytical thinking focuses on knowledge of the parts, properties, and behaviors of an object. Systems thinking focuses on the understanding of the properties and behaviors of an object, its parts, and the system under which it operates. This means that analytical thinking takes us levels inward with respect to the object, whereas systems thinking takes us levels outward with respect to the object because explanations always lie outside and not inside the system being studied. Systems thinking is very effective in solving even very difficult challenges and problems because the understanding acquired makes it easier to determine the root cause or causes of issues we encounter.
The SOPK is a management framework that has four parts: (1) willingness to change the management style, (2) transforming the individual, (3) fully applying its principles to all interaction with other people and decision making, and (4) transforming the organization.

Ponencia y taller en la Semana de la Cultura Laboral en Tlaxcala

2011-04-23T21:46:00.000-07:00

Tuve el honor de ser invitado a dar la Presentación Magistral de Clausura de la Semana de la Cultura Laboral que se llevo a cabo en Tlaxcala, así como de dar un taller sobre Innovación de Valor el día 13 de Abril de 2011. Ambas tuvieron lugar en el auditorio del IMSS.

La presentación la atendió un auditorio lleno (con alrededor de 30 gentes de pie en los pasillos) consitente de industriales y oficiales de gobiernos de la region; maestros de enseñanza media y superior; y estudiantes de esos mismos niveles. El tema titulado "Entregando mayor valor a cliente y a la empresa mediante un enfoque moderno de calidad" lo presente bajo colaboración con la UNAM y con Esprial (empresa Española). La audiencia lo recibió con entusiasmo y parece ser que si logré tener impacto con toda la audiencia a pesar del reto que confronté debido a su diversidad. El tema incluyó innovación de valor, lean-agile, y Kanban.

Después de la ceremonia oficial de clausura se llevó a cabo el taller titulado "Mejorando la calidad mediante innovación colaborativa". La efectuamos el Mtro. Jorge Polo Contreras, el Mtro. Luis A. Nava, y yo. Efectuamos varias dinámicas para demostrar:

El beneficio de trabajar en equipo
El beneficio de la diversidad para llevar a cabo proyectos de manera mas exitosa
El beneficio de limitar el monto de trabajo en progreso
Las desventajas de efectuar múltiples tareas simultaneamente
La importancia de darle el valor adecuado al factor humano para el éxito de la realización de productos y de la prestación de servicios.
La ventaja de combinar pensamiento innovador con un ambiente que fomenta innovación y el contar con herramientas innovadoras que facilitan innovación.

Primer curso de Certificación en Gestión Lean-Agile de Proyectos en México

2011-04-23T21:20:00.000-07:00

El primer curso de Certificación Lean-Agile de Proyectos en México se llevó a cabo del 4 al 6 de Abril de 2011 en la Colonia del Valle, Distrito Federal.

Un grupo de 9 personas atendieron el curso impartido por el Dr. Masa K Maeda.

El curso fué muy intenso y de alto calibre. Los participantes se divirtieron, fueron retados con los cambios de paradigmas y sobrevivieron la transformación ;-)

De izq a der: Dr. Masa Kevin Maeda, Ing. María Elizabeth Rivera Patiño, Ing. Marlon Torres Valle, Mtro. Ismael Villegas Ochoa, Mtro. José Manuel Muguiro Alvarez, Mtro. Luis Alonso Nava Fernández, Mtro. Marco Antonio Navarro Gutierrez, Ing. Maria Luisa Regato, Ing. Leonardo Mrak, Mtro. José de Jesús Hernández Suárez.

Felicidades!

El mismo grupo tomó también un curso de Kanban el 7 y 8 de Abril.

Donate to help Japan

2011-03-14T23:40:00.000-07:00

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

2011-03-10T07:43:00.000-08:00

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.

2011-03-05T11:05:00.000-08:00

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.

2011-02-11T10:02:00.000-08:00

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

2011-02-04T11:57:00.000-08:00

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

2011-02-04T11:27:00.000-08:00

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

2011-02-04T07:00:00.000-08:00

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

2010-12-28T11:24:00.000-08:00

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

2010-12-23T17:32:00.000-08:00

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

2010-12-17T10:31:00.000-08:00

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

Cutter Consortium 2011 Predictions

2010-12-07T10:20:00.000-08:00

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

2010-12-07T09:31:00.000-08:00

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

2010-12-07T09:27:00.000-08:00

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

2010-12-07T08:41:00.000-08:00

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

2010-10-30T12:22:00.000-07:00

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

2010-10-27T16:09:00.001-07:00

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

2010-10-22T07:33:00.000-07:00

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

Rapid Maturity on sight

2010-10-20T13:36:00.000-07:00

the most voted topic to cover at agileperu

2010-10-20T12:01:00.001-07:00

@epeupc epeupc

@masaKmaeda #kanban was the most voted topic to cover yesterday in the monthly meeting of @agileperu @epeupc /via @lshimokawa

WIP Limits and how to leverage to improve flow- Lean Agile and the Lean Agile Prism

2010-10-13T12:48:00.000-07:00

From AOCWiki

Host: Michael DePaoli (Agile Coach, VersionOne (http://www.versionone.com) )

Bill Dominguez (Agile Coach, Shojiki Solutions)

Participants: Dave Smith, Tom Moore, Tom Lody, Alida Cheung, Shane Duan, David Mcleod, Steve Bockman, Jeremy Lightsmith, John Donahue, Brian Chan, Dirk Wippermueller, Jeffrey Frederick, Jim Sun, Trevor Morris, Mike Wright, Moira Wilmes, Vickie Hall

Session notes:

We started with a discussion of common problems that occur on agile and non-agile teams with unplanned work,bug escalations Examples: Startups that don't usually have the goal of shipping a product in the short run, rather they need to achieve their next round of funding. This can cause a highly volitale set of priorities.

Companies that allow technical debt to get out into the wild begin to get escalations from customers about problems. This only increases as more debt is put out into the world. Teams that don't have a way of dealing with this that are following an agile approach like Scrum will be very frusturated and frequently won't have a useful velocity.

To address this problem an example was given where a team implemented a defect threshold. This was explained with a metaphor where delivering a release was equated to landing a plane. Teams that allow for the amassing of defects during a release create a situation where they frequently can't land their plane because the find / fix rate of defects doesn't approach a smooth landing approach. Their plane keeps bouncing back up. This happens because of the complexity of defects that have been built upon other defects. Frequently bug fixing in this environment treats symptoms of a bug and not the root cause. Also, the more complex the situation the more likely fixing one defect breaks code in other places (more defects).

Mike gave an example of a team that put in place a defect threshold that basically set a maximum altitude' the release could fly at in terms of number of the amount of time to fix defects. So, the particular team set this ceiling at 3 weeks. Therefore, no developer could continue to work on new features if their bug backlog hit the defect threshold. This policy always kept the release at an altitude that could have a predictable landing. This was a basic

application of Work In Process Limits (WIP).

Bill introduced the concept of the Lean Agile Prism which is an extension to the traditional iron triangle of project management by adding 3 other facets, those being Value, Quality and Innovation. More information at www.shojiki-soltutions.com.

Bill and Mike also introduced kanban as a way to implement pull based processes for a team and explained the use of WIP limits to eliminate waste in the value flow (workflow). Also it was explained for for continuous process improvement to occur, there must be slack in a process. Case in point, it is frequently the case that QA is a bottleneck in software development value flows. If all the other operations upstream from QA continue to produce inventory to drop at QA's door step, this is push based planning and not pull based and is not respecting WIP Limits of the upstream steps in the value flow. If instead, when QA's WIP limit was reached, the dev teamwould stop pulling in new items once they reached their WIP limit, there would be slack created for the dev team.

With this time, the dev team can spend time on process improvement, innovation or just helping QA to eliminate the bottleneck for the moment. Once the bottleneck is evaluated from a value flow perspective and this issue is addressed, it is inevitable that another will occur, hence continuous process improvement. By having slack in the value flow occur because of bottlenecks allows us to identify the bottlenecks. If every operation in the value flow is unbounded by WIP, you can't truly identify the issues.

Bill also introduced the concept of an Organizational Value Currency that can be used as a common measure of value for work / features. This allow for richer prioritization of work as well as helping to provide an understanding of the cost of changes that are being considered. Without a common currency, it is difficult to negotiate trade offs.

It was clarified that how a team chooses to do prioritization of stories ahead of the kanban development process is up to the organization and should be appropriate given their context. However, once a story arrives in the queue that is ready for dev (analysis or what ever the first step in the value flow) it needs to be ready, just as how stories that are brought to a Sprint planning meeting need to be ready, otherwise it adds waste to the process.

Excellent kanban reference is David Anderson's book on Kanban

Competencia en trabajo de conocimiento es algo malo

2010-10-08T20:00:00.000-07:00

Wow! Such a long time without posting. Too much going on with the business and I feel ashamed for the lack of posting. Here's an email response I sent to a person in Peru regarding competence vs collaboration:

Agile nos recomienda que cuando tenemos que llevar a cabo una evaluación, tal como por ejemplo para determinar una herramienta a adoptar, es mucho mas efectivo evaluarlas todas al mismo tiempo en lugar de una a la ves. Esto es adecuado porque reduce el monto de tiempo que toma llevar a cabo las actividades de evaluación.

La manufactura lean (entiendase Kaizen) nos dice que el trabajo competitivo es bueno porque motiva a las personas a hacer mejor.

Esa labor de competencia en Lean es, sin embargo, aplicable solamente en tareas de naturaleza manual (i.e., manufactura) y no en tareas de carácter creativo tal como el trabajo de conocimiento. Hay estudios extensivos que demuestran que motivadores externos de hecho hacen que la ejecución sea peor que si no hay motivadores en absoluto. Afortunadamente ustedes no están utilizando como motivación el darles a las personas dinero sino el adoptar su trabajo. El problema con ese modelo está en que no es lean porque genera desperdicio. Todo el tiempo y labor del equipo que pierde el concuso se va a la basura! Si ustedes pueden darse el beneficio de tener dos grupos compitiendo entonces sería mejor tenerlos a todos como un grupo colaborando efectivamente para generar una solución, y el motivador que deben encontrar es un motivador interno y no un motivador externo. El motivador externo es ganar la competencia. El motivador interno que actualmente utilizan es el adoptar la solución mejor. Podrían agregar otro(s) motivador(es) interno(s). De esa manera el trabajo de todos los involucrados será de valor. Colaboración supera competencia siempre, por eso los modelos industriales de Japón y Korea superan los de los E.U. y muchos otros paises.

Competencia impulsa a apresurar las cosas mucho mas que impulsa a innovar. Motivadores internos motivan a innovar. El concepto de respeto a las personas e incremento de conocimiento (lo cual se logra muy bien mediante cooperación) supera por mucho la competencia. El grupo de trabajo que pierde la competencia perderá motivación en su grán mayoría y el grupo que ganará comenzará a tender a ver a otros por encima del hombro y se distrairá y se confiará durante la siguiente ronda de concurso, por lo que la efectividad de ambos grupos disminuirá con el tiempo. Ese acto de ganar y de ser mejor es una ilusión.

Webinar: Moving from Failing to Successful Agile Adoption (new version)

2010-06-25T20:45:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
New version of my Webinar (added new material and has better sound quality): Moving from Failing to Successful Agile Adoption
is available at http://bit.ly/c4p87N

----- Spanish -----
Una nueva versión de mi Webinar (con material nuevo y mejor sonido): Moving from Failing to Successful Agile Adoption
está disponible en http://bit.ly/c4p87N

What makes a good manager?

2010-06-24T12:27:00.001-07:00

A few weeks back I was at the Sir Francis Drake Hotel in San Francisco having a conversation with a good friend and an executive from a very large top organization in the Bay Area. We were talking about managing projects and how lean-agile can better things up. At some point the executive said, "A good manager is the one who gets things done!" That statement sounds great, right? Nonetheless, i counter-argued saying, "I think that a good manager is the on e who gets things done with minimal or no collateral damage." He looked at me intently... smiled... and continued on with the conversation. The next day I got an email from a recruiter from that company.

Then last week I was at a gathering in which a question shown on a slide and we were asked to discuss answers to it. The question was "you are asked to reduce the burn rate of the HR department by 10%, what do you do?" I was sitting at a round table with five other people to do this. One person, who happens to be a senior project manager, I learned later, was arguing that we should go about doing a round of lay offs. Almost everybody at the table started then talking about what the criteria should be to let people go. I was quietly listening to the conversation, amazed of how easily they were willing to get rid of the most valuable asset on every enterprise. Finally, I argued that we could focus on first understanding why the need for reduction, which can help on the decision making process, and also have a closer look at the processes to identify areas of improvement, which would lead to cost reduction potentially beyond 10%. In the end my proposal was the answer we presented.

Webinar: Moving from Failing to Successful Agile Adoption

2010-05-28T06:41:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
My Webinar: Moving from Failing to Successful Agile Adoption
is available at http://blip.tv/file/3645444

----- Spanish -----
Mi Webinar: Moving from Failing to Successful Agile Adoption
está disponible en http://blip.tv/file/3645444

New game: Packing Peanuts to learn about technical debt

2010-05-21T15:21:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
My new game: "Packing Peanuts" is now available on tastycupcakes.com

----- Spanish -----
Mi nuevo juego: "Packing Peanuts" está dispnible en tastycupcakes.com

Making pamphlets, my Kanban game has 5 stars :-)

2010-05-20T20:09:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
"Making Pamphlets", my kanban game which I posted on tastycupcakes.com is currently the featured on the home page of tastycupcakes.com (a website dedicated to learning through games) and has 5-star rating :-)

----- Spanish -----
"Making Pamphlets", mi juego de Kanban que publiqué en tastycupcakes.com (un sitio dedicado a aprender jugando) esta actualmente en la página principal de ese sitio y clasificado con 5-estrellas! :-)

Book Review: Kanban: Successful Evolutionary Change for Your Technology Business

2010-05-19T16:32:00.000-07:00

It is very rare to find a good technical book that is also a good management book and addresses both aspects in a balanced way. But what really makes one's chin drop is finding a book that goes beyond the methodological, the mechanical, and the administrative aspects to address the ever so important--but way too often ignored--human aspects required to make a project successful. David's is such a book.

Kanban is a relatively new lean-agile method that allows teams and the projects they work on to be built in a true continuous flow manner in which improvements over the product being built and over the process itself occur. I indicted it is relatively new because its origins started back in 2004 as David writes on chapter 4. David is the person behind the creation and evolution of Kanban as a mechanism for software development. Although Kanban started in manufacturing, it has evolved to become rather unique in many aspects so don't expect a 1:1 mapping. Meaning, you should read this book cover-to-cover to get full benefits.

Part One describes David's journey of revelation to develop the Kanban model and explains why Kanban is a very effective method. In many ways it is due to its ease of acceptance, adoption, and the highly collaborative and communicative nature that allows people to bring change and evolution to processes what makes it successful.

Part Two explains the basics of Kanban as a mechanism. From work-in-progress to lead time, figuring the right cadence to maximize productivity, and prioritization; all of them paramount factors to mature enterprises. Using the case of an IT division from Microsoft, David explains how Kanban made the best out of the worst department at a division of Microsoft's IT division. Kanban brought high visibvility to the issues that affected the department and through waste elimination, limitation of work-in-progress, adequate policies, and cadence the department became amazingly successful. The last chapter treats in detail the importance of generating a culture of continuous improvement within an organization.

Part Three is the core of the book and explains how to implement Kanban. It introduces Value Stream Maps from a kanban perspective and goes into full detail on how to create a kanban board, the anatomy of the cards, and how to treat aspects such as concurrency and unordered activities, which are hard to deal with under other methodologies. How to use the board as a control and pull system as well as an scalable mechanism for daily standups is treated on Chapter 7. True sustainable pace is explained on chapters 8 and 9. Chapter 10 provides some strategies to limit the work-in-progress. One key factor in the communication within and outside the team are the service level agreements and are explained on chapter 11. Kanban metrics are particularly useful and fun to use, as shown on chapter 12. A problem with most methodologies is that they do not scale well. Kanban is better suited for such situations and chapter 13 gives insights on how to do that. The last two chapters focus on operational and strategy issues to increase its effectiveness and adoption.

Par Four is the next-step. That is, once you have a functional kanban mechanism in place at your organization here's how to make it evolutionary to create significant impact at the organization. Consider eliminating or at least reducing bottlenecks, waste and variability; better usage of resources; identifying wasteful activities; understanding and treating variability; and the importance of properly treating blocked work.

I introduced Kanban to a financial institution recently and even use it as an administrative tool for ma work and personal activities. The results have been no less than awesome.

David J Anderson's book on Kanban is out :-)

2010-05-12T20:13:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
David J Anderson's book
Kanban: Successful Evolutionary Change for Your Technology Business
is now available
http://tinyurl.com/29phwxr

----- Spanish -----
El libro de David J Anderson's
Kanban: Successful Evolutionary Change for Your Technology Business
ya está disponible
http://tinyurl.com/29phwxr

Mexican Academy of Informatics just made me a member

2010-05-11T12:58:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
Unexpected event. I just got a phone call from the AMIAC (Mexican Academy of Informatics) and was told they are making me a member. This is a huge opportunity, which obviously I accepted, that will make easier my plan to create strong relationship with the Secretary of the Economy to get them to give lean-agile similar support for adoption as that given to CMMI, TSP, ISO, etc.
It will also give me the opportunity to contribute to the creation of a new program to improve the educational system in Mexico.

----- Spanish -----
Esto me llego de manera inesperada. La Academia Mexicana de Informática (AMIAC) me invitó a ser miembro de ella; lo cual acepté con mucho gusto. Esto es una grán oportunidad que facilitará mi plan de poder tratar con la Secretaría de Economía que le dé apoyo a la adopción de lean-agile de la misma manera que lo ha hecho con CMMI, TSP, ISO y otros. También me permitirá colaborar en la generación de un nuevo plan educativo para México.

My first Kanban game

2010-05-10T22:17:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
My first Kanban game is now available on tastycupcakes.com. It is a very simple game that helps practice some kanban concepts.
http://tinyurl.com/29kg42r

----- Spanish -----
Mi primer juego de Kanban está disponible en tastycupcakes.com. Es un juego simple que ayuda a practicar algunos conceptos de Kanban.
http://tinyurl.com/29kg42r

Coming webinar: Moving from Failing to Successful Agile Adoption (5/19)

2010-05-02T12:34:00.000-07:00

----- English -----
I'll be giving a webinar on "Moving from Failing to Successful Agile Adoption" on May 19 at Noon PST. For more information visit Shojiki Solution's website or http://bit.ly/aBWFya

----- Spanish -----
Voy a dar un webinar en Inglés titulado "Moving from Failing to Successful Agile Adoption" el 19 de Mayo a las 12:00 hrs (hora de California USA). Para mayor información visiten el website de Shojiki Solutions o http://bit.ly/aBWFya

MexAPLN: First public meeting

2010-05-02T12:14:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
MexAPLN's first public meeting took place April 29, 7:45 PM, at the offices of IDS in Mexico City. Despite the fact that, in addition to the usual heavy traffic, there were a couple of very serious accidents that delayed some of the attendees, The meeting was a great success! There were 20 people, out of which 2/3 were guests.

The first 25 minutes were for networking and extra slack for those delayed by traffic... and we had great hor d'ouvres. Adriana was our master of ceremonies. She welcomed everybody and to get started had Masa give a little bit of background talking about APLN and how MexAPLN was formed. Adriana then introduced Sergio Durán, who talked about MexAPLN and its charter. We moved then to the main topic of the meeting which was a talk by Masa on lean-agile project management, emphasizing on the lean-agile prism. There was great interest and participation by the audience. A post-talk discussion on agile adoption took place with great comments by everyone.

The meeting's closure consisted on a raffle and a quick introduction by all present.

----- Spanish -----

La primera reunión pública del MexAPLN tuvo lugar el 29 de abril, 19:45 hrs, en las oficinas de IDS en la Ciudad de México. A pesar de que además del tráfico habitual hubo un par de accidentes muy graves que retrasó algunos de los asistentes, la reunión fue un gran éxito! Había 20 personas, de las cuales 2 / 3 fueron invitados.

Los primeros 25 minutos fueron para la networking y dar mas tiempo a aquellos perjudicados por el tráfico ... y tuvimos grandes hor d'ouvres. Adriana fue nuestra maestra de ceremonias. Ella dio la bienvenida a todo el mundo y para empezar Masa dio un poco de antecedentes hablando sobre el APLN y cómo se formó MexAPLN. Adriana presentó a continuación a Sergio Durán, quien habló sobre MexAPLN y sus estatutos. Pasamos entonces al tema principal de la reunión que fue una charla sobre gestión de proyectos ágil por parte de Masa, con énfasis en el prisma lean-agile. Hubo gran interés y participación de la audiencia. Una discusión posterior a la charla sobre la adopción ágil se llevó a cabo con grandes comentarios por todos.

El cierre de la reunión consistió en una rifa y una introducción rápida por todos los presentes.

Kanban Coaching Workshop

2010-04-24T09:04:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
This event actually took place before my previous posting on Rapid Requirements Gathering. It is no excuse but the last month and a half have been intense. Between March 19 and April 16 I was home only one day; and all of last week has been intense too.

I spent April 13 through 16 at Dana Point, Orange County, in Southern California on a Kanban Coach Workshop with David J. Anderson (the workshop was April 14~16). This was actually my second Kanban workshop with David; the first one was last November in San Francisco. That first workshop was amazing and this one was even better.

Dana Point is a quiet area right next to the ocean with a beautiful beach and few people at this time of the year.

12 people attended the workshop. Some of them where local and most of the rest from the west side of the USA. The one exception was Russell Healy from New Zealand. The workshop had a very informal tone and was driven by two factors: an agenda of key points David wanted to make sure we covered and an agenda that was created by all of us during the first 45 min. of the workshop. Daniel Vacanti, who is part of D. J. Anderson & Associates, was also there to assist David.

Most of the course were advanced Kanban topics (although we revisited some foundations as well) which included the human factors such as emotional intelligence, and executive level aspects of Kanban adoption. The workshop was highly productive also because there was a high degree of exchange of experiences and ideas. Definitely the kind of things that cannot be effectively captured on slides or a book.

I recently designed a Kanban game and used it for the first time at a Kanban course I gave to a large financial institution. My strategy has been to create a set of games that show different aspects of Kanban since it is very difficult to get to capture it effectively in one game. Well, one of the biggest surprises at the workshop was Russell's Kanban game. He managed to figure out a way to demostrate a a large amount of Kanban modus operandi in one game, which is also fun to play. Needless to say we all were amazed by it, including David.

I have to say the workshop was worth many times over its dollar cost because, and I think this goes for all who attended, the wealth of knowledge was vast, deep, and unique.

Not everybody who was at the workshop is in the photo. Attendants were:
Wendy Wong
Paul Hodgetts
Rand Bradley
Masa K Maeda
David J Anderson
Daniel Vacanti
Darrin Ladd
Keith Clinton
George Schlitz
Russell Healy
Donna Reed
..not on the photo..
Juan Pablo Dellarroquelle
Keith Clinton
Alan Atlas

----- Spanish -----
Este evento de hecho tuvo lugar antes de mi publicación anterior sobre Adquisición Rápida de Requerimientos. No es excusa pero el último mes y medio han sido intensos. Entre marzo 19 y abtril 16 estuve en casa tan sólo un día, y toda la semana pasada ha sido intensa también.

Pasé del 13 al 16 de Abril un tiempo increíble en Dana Point, condado de Orange, en California del Sur en un Taller de Coucheo en Kanban con David J. Anderson (el taller mismo fue del 14 al 16 de abril). Este fue mi segundo taller Kanban con David; el primero fue en noviembre del año pasado en San Francisco. Ese primer taller fue increíble y éste fue aún mejor.

Dana Point es una zona tranquila justo al lado del mar con una hermosa playa y muy pocas personas en esta época del año.

12 personas asistieron al taller. Algunas de ellas locales y la mayoría del resto vino de la parte oeste de los EE.UU.. La única excepción fue Russell Healy de Nueva Zelanda. El taller tuvo un tono muy informal y fue impulsado por dos factores: un programa de puntos clave que David quería asegurarse que se cubriera y una agenda que fue creada por todos nosotros durante los primeros 45 min. del taller. Daniel Vacanti, quien forma parte de D.J. Anderson & Associates, también estuvo ahí para ayudar a David.

La mayor parte del curso fueron temas avanzados de Kanban (aunque también revisitamos algunos fundamentos) que incluyeron los factores humanos tales como la inteligencia emocional, y los aspectos de nivel ejecutivo para la adopción Kanban. El taller fue muy productivo también debido a que hubo un alto grado de intercambio de experiencias e ideas. Definitivamente el tipo de cosas que no pueden ser efectivamente capturados en las diapositivas o un libro.

Hace poco diseñé un juego Kanban y lo utilizé por primera vez en un curso de Kanban que le dí a una institución financiera grande. Mi estrategia ha sido crear un conjunto de juegos que muestren diferentes aspectos de Kanban, ya que es muy difícil llegar a capturarlo todo de manera efectiva en un juego. Bueno, pues una de las mayores sorpresas en el taller fue el juego de Kanban que Russell diseñó. Tuvo el ingenio para encontrar una manera de demostrar una gran cantidad del modus operandi de Kanban en un juego que también es divertido de jugar. Todos estuvimos asombrados y nos divertimos con el, incluyendo David.

Tengo que decir que el taller valió muchas veces su costo en dólares, ya que, y creo que esto va por todos los que asistieron, la riqueza de conocimientos fue muy grande, profundo y único.

Rapid Requirements Gathering with Scott Killen

2010-04-20T23:24:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

----- English -----
Today's BayAPLN meeting had Scott Killen give a workshop on Rapid Requirements Gathering. Scott is an amicable person and an entertaining presenter. His workshop was very dynamic and it was easy to understand the concepts.The basic steps are (in my own words and not the way Scott explained them):

Requirements suggestions. All those involved white succinct ideas for requirements on cards.
Expose cards. The cards are read aloud by two or more people and are posted randomly on as much wall space as possible; preferably on separate walls.
Making sense of the cards. All attendants go about looking at the cards and start gathering them by topics at separate areas of the wall(s). This has to be done in a self-organized manner but making sure not to let anyone dominate actions. It was to be done in a collaborative way and through discussion.
Eliminating redundancies. All attendants self-organize to discuss the cards and eliminate those that are redundant. Something I observed and commented to Scott is that is important to make sure not to eliminate important cards or let important interpretations to get lost by removing any given card. That is, two cards on the same subject could bring important, complementary conceptualization and in such case it is better to either keep both cards or write a new one that captures what the two separate cards convey.
Prioritization. All attendants discuss and sort the cards by priority
Discussion. For each top priority cards (say, the top two or three per category) the people who wrote it or are involved explain about it, and are discussed.
Voting. All attendants get 5 dot-stickers to place them at will on the cards. This allows to know what everybody considers to be the most important stuff, which then drives what needs to be done and in which order.

----- Spanish -----
La reunión de hoy del BayAPLN tuvo a Scott Killen danso un workshop sobre Adquisición Rápida de Requerimientos. Scott es una persona muy amigable que sabe entretener durante sus presentaciones. Su workshop fue muy dinámico y fue fácil entender los conceptos.

Los pasos básicos son (en mis propias palabras y no en la forma que Scott lo explicó):

Sugerencias de requerimientos. Todos los participantes escriben ideas para requerimientos de manera sucinta en tarjetas
Exponer tarjetas. Las tarjetas son leídas en voz alta por dos o mas personas, y son puestas en paredes de manera aleatoria.
Haciendo sentido de las tarjetas. Todos los participantes se auto-organizan para ver las tarjetas y las agrupan en base a temas. Hay que asegurarse de no dejar que nadie domine la acción. Debe hacerse de manera colaborativa y mediante discusiones.
Eliminación de redundancias. Todos los participantes se auto-organizan para discutir las tarjetas y eliminar aquellas que son redundantes. Algo que observé y le comenté a Scott is que es importante asegurarse de no eliminar tarjetas importantes o dejar que se pierdan interpretaciones importantes al eliminar tarjetas. Es decir, dos tarjetas sobre un mismo tema pueden conllevar conceptos complementarios importantes, y en ese caso es mejor que o bien se conserven las dos tarjetas, o bien escribir una nueva tarjeta que capture y reemplase las dos tarjetas en questión.
Priorización. Los participantes discuten y ordenan las tarjetas por prioridad.
Discusión. Para cada grupo, las personas que escribieron las 2 o 3 tarjetas de mas alta prioridad las expliquen y sean discutidas.
Votación. Los participantes obtienen 5 calcomanías de punto para que las pongan en las tarjetas que consideran mas importantes. Esto permite que todos sepan lo que se considera ser mas importante y dirige lo que se debe de hacer y en que orden.

Kanban boards as VSMs

2010-04-16T07:00:00.000-07:00

----- English version on top, Spanish version at the bottom ----
----- Versión en Inglés primero, versión en Español al fondo -----

--- English----
Lots of people keep asking me about the conversation I had with Alan Shalloway from which the idea of Kanban boards as VSMs emerged. You can read more on at
http://bit.ly/bGt62B

--- Spanish ---
Mucha gente me sigue preguntando sobre la conversación que tuve con Alan Shalloway en la que surgió la idea de usar tableros de Kanban como VSMs (Mapas de Valor de Flujo). Pueden leer mas al respecto en
http://bit.ly/bGt62B

Lean-Agile Prism

2010-04-14T19:52:00.000-07:00

Article I wrote for Agile Journal
http://bit.ly/dbbBHJ

Conference presentation at ITESM

2010-04-10T18:34:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

--English--
I'm back at my hotel room after having given a presentation on Lean-Agile and Innovation. Unfortunately I got very sick last night; and was feeling quite weak and out of focus during my talk, thus it didn't go as great as I wanted. Students and university staff received quite well what I had to say on lean-agile and it seems they enjoyed both the pair face-drawing exercise and, even more so, the speed-boat exercise which I used for the audience to evaluate the conference (taking advantage of the fact that mine was the last, and main, presentation.

One of the talks I attended yesterday was by Luis Armando Bravo from Probionics, a mexican maker of prosthetics controlled by muscular electric signals. His work is amazing as he managed to develop a set of prosthetics, that are lighter, stronger, faster, cheaper, and more versatile than any other in the world.

The other talk I attended was by Ricardo Medina from Microsoft. As expected, it was part marketing - part presentation. The highlight was the offering from Microsoft to provide no -strings-attached material resources to young entrepreneurs as long as their idea includes the use of technology.

This congress was actually organized by the students at ITESM, with help from some university staff, and they did a fantastic job. There were around 300 attendants and sponsorship from several national and international businesses. Congrats!

--Spanish--
Estoy de regerso en mi habitación del hotel después de haber dado una presentación sobre Lean-Agile e Innovación. Lamentablemente tuve una noche difícil debido a que me enferme; y me sentí muy débil y fuera de foco durante mi presentación, por lo que resultó como yo lo deseaba. Los estudiantes y profesores universitarios recibieron muy bien lo que les comuniqué sobre lean-agile y parece que disfrutaron los dos ejercicios: el dibujar caras por parejas y, más aún, el ejercicio de la lancha, el cual utilizé para que la audiencia evaluara la conferencia ( aprovechando el hecho de que mi plática fue la última, y la presentación principal.

Una de las pláticas a las que asistí ayer fue por Luis Armando Bravo de Probionics, un fabricante mexicano de prótesis controlada por señales eléctricas musculares. Su obra es muy buena y se las arregló para desarrollar una serie de prótesis, que son más ligeros, más fuertes, más rápidos, más baratos y más versátiles que cualquier otra en el mundo.

La otra plática que asistí fue la de Ricardo Medina, de Microsoft. Como es de esperarse, fue parte mercadotécnia - parte presentación. El punto culminante fue el ofrecimiento de Microsoft de proporcionar recursos materiales sin compromiso a los jóvenes empresarios, siempre y cuando su idea incluya el uso de la tecnología.

Este congreso fue organizado en por los alumnos del ITESM, con la ayuda de staff universitario, e hicieron un trabajo fantástico. Hubo alrededor de 300 asistentes y obtuvieron patrocinio de varias empresas nacionales e internacionales. Felicidades!

Snow Crash and the emerge of lean-agile

2010-03-26T18:22:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

--- English ---
Silly question: have you read Neal Stephenson's novel Snow Crash? I know... I know... who hasn't? duh! I myself read it for the first time back in 1996 (didn't read it when it was published in 1992 because I lived in Japan at that time and the novel wasn't available in the City I lived in. Moved to the USA in 1995).

So, why am I bringing Snow Crash up? At the beginning of the novel, Stephenson wrote the are things we Americans do better than anyone else and the list includes music, movies, and microcode (i.e., software). This is a nice thing to believe. Take movies, for example; we make really good movies (The Matrix pops out in my mind). Even the bad movies are good; why, because even when they suck they entertain and bring audiences and make money. Fortunately we are much better at doing good ones even better. Take for example "La Jetée" made into "12 Monkeys", or the short story "The Sentinel" into the movie "2001 A Space Odyssey". Our pizzas are also awesome (Chicago style being my favorite) and although I have never been to Italy friends have told me there's no way Italian pizzas are better than ours! The emerge of new music in the USA is unlike anywhere else. We can create new music just as much as we can take something from anywhere else in the world and morph it into something new and cool.

All that is, of course, arguable. But we all are entitled to an opinion and even if things are not to the larger extent my words may sound we can all agree that many good things have been done here.

Similarly, lean and agile are a combination to two things. We took things that work in practice, regardless of what theory or established processes indicated, and made them better. We didn't care if a standard came out of a DoD sponsored effort, or a model came out of a prestigious institution. We wanted something that worked really well in the real world and that acknowledged the variability that comes from working in an ever changing environment. From market trends to customer needs, the economy, team members personal life, health, etc. We wanted and needed a foundation and practices to make us succeed in such chaotic environment.

Lean and agile evolved independently of each other, although it is clear that agile follows some very similar foundation. None of them brought something entirely new but both took bits and pieces that have had good results and shaped them up into something congruent and quite useful and effective.

The history of humanity has gone through some important changes such as from he feudal days to the renaissance, the industrial revolution, the popularization of culture, and an information revolution. The pattern is pretty much bringing something big, monolithic, power-based, controlling, and inefficient to something smaller, distributed, knowledge-based, collaborative and efficiency-oriented.

Lean-agile is following that pattern by emphasizing on work in small teams, breaking work into small chunks, empowering people (and respecting them), increase collaboration at all levels of the enterprise and with customers, and replacing costly and fancy processes with efficient practices.

--- Español ---
Pregunta tonta: ¿Has leído la novela de Neal Stephenson titulada Snow Crash? Lo sé ... lo sé ... ¿Quién no? Yo la leí por primera vez en 1996 (no lo leí cuando se publicó en 1992, porque yo vivía en Japón en esa época y la novela no estaba disponible en la ciudad que vivió in mudó a los EE.UU. en 1995).

Así que, ¿por qué estoy atrayendo atención a Snow Crash? Al comienzo de la novela, Stephenson escribió que hay cosas que los Estadounidenses hacemos mejor que nadie, y la lista incluye música, películas, y microcódigo (es decir, software). Esta es una cosa agradable de creer. Tomemos películas, por ejemplo, hacemos películas realmente buenas (The Matrix surge en mi mente). Incluso las malas películas son buenas, ¿por qué, porque aún cuando son malas entretienen y atraen al público, y ganan dinero. Afortunadamente somos mucho mejor en hacer algo bueno aún mejor. Tomemos, por ejemplo, "La Jetée" en la cual se basó "12 Monkeys", o el cuento "The Sentinel" a partir del cual se hizo "2001 Una Odisea en el Espacio". Nuestras pizzas son también buenísimas (estilo Chicago son mis favoritas), y aunque nunca he estado en Italia, amigos que han ido me han dicho que no hay manera de que las pizzas italianas sean mejores que las nuestras! El surgimiento de nueva música en los E.U. no tiene comparación con cualquier otro lugar.Podemos crear nueva música tanto como podamos tomar algo de cualquier otra parte del mundo y se transforman en algo nuevo y fabuloso.

Todo esto es, por supuesto, discutible. Pero todos tenemos derecho a una opinión y aunque las cosas no lleguen a ser de la medida que mis palabras reflejan, creo que todos estaremos de acuerdo que muchas cosas buenas se han hecho aquí.

Del mismo modo, lean y agile son una combinación de dos cosas. Tomaron las cosas que funcionan en la práctica, independientemente de lo que la teoría o de los procesos establecidos indicam, y las hicieron mejor. No nos importaba si una norma salió de un esfuerzo patrocinado por el Departamento de Defensa, o un modelo salió de una institución de prestigio. Queríamos algo que funciona muy bien en el mundo real y que reconoce la variabilidad que viene de trabajar en un entorno en constante cambio. De las tendencias del mercado a las necesidades del cliente, la economía, la vida personal de los miembros del equipo, la salud, etc.. Queríamos y necesitabamos una base y prácticas que nos hicieran prosperar en un ambiente sumamente caótico.

Lean y agile evolucionaron de forma independiente el uno del otro, aunque es evidente que agile sigue algún fundamento muy similar a lean. Ninguno de ellos aportó algo totalmente nuevo, pero ambos tomaron pedazos que han tenido buenos resultados en la práctica y en forma congruente para llegar a algo muy útil y eficaz.

La historia de la humanidad ha pasado por algunos cambios importantes, como de los días feudales al Renacimiento, la revolución industrial, la divulgación de la cultura, y la revolución de la información. El patrón es cambiar de algo grande, monolítico, basado en el poder, controlador, e ineficiente en algo más pequeño, distribuido, basado en el conocimiento, en colaboración y orientado a eficiencia.

Lean-agile está siguiendo ese patrón, poniendo énfasis en el trabajo en pequeños equipos, rompiendo el trabajo en pequeños pedazos, capacitando a las personas (y respetandolas), aumentando la colaboración en todos los niveles de la empresa y con los clientes, y substituyendo los procesos costosos y pesados con prácticas eficientes.

MexAPLN meeting: March 2010

2010-03-26T07:04:00.000-07:00

----- English version on top and Spanish version at the bottom -----
----- Versión en Inglés primero y version en Español abajo -----

--- English ---
MexAPLN meeting on March 25 took place at Software Guru, again. Many thanks to SG for hosting us! I like their offices quite a bit, btw. Given the fact that a long vacation time starts next week and many people start early I expected few people but to my surprise there were 8 of us; which is great considering previous meetings have had between 8 and 12 people.

Agenda for the meeting was primarily to:

Work on the charter's objectives. We covered a little over the list we had and added new ones. We have enough to get started and will cover the remaining ones by the next meeting, hopefully.
Next meeting will be the first double-meeting, meaning a CoCo meeting followed by a general meeting. Venue is TBD and topic will be either one to be proposed by Alberto Balderas or one on project management by Masa
Learning. I talked about the project management triangles and showed a new polygon I call the lean-agile prism, which I am currently proposing and submitted and article about it to Agile Journal.

--- Español ---
La reunión del 25 de marzo tuvo lugar en Software Gurú otra vez. Muchas gracias a la SG por recibirnos! Por cierto que me gustan mucho sus oficinas un poco. Dado el hecho de que las vacaciones de semana santa comienzan la próxima semana y que muchas personas inician su vacación días antes, esperaba poca gente pero para mi sorpresa hubo 8 de nosotros, que es fabuloso teniendo en cuenta que las reuniones anteriores han tenido entre 8 y 12 personas.

La agenda fué primordialmente:

Trabajar en los objetivos de los estatutos. Hemos cubierto un poco más de la lista que teníamos y añadimos otros nuevos. Tenemos suficiente para empezar a trabajar y cubriremos los restantes en la próxima reunión, de ser posible.
La próxima reunión será la primer reunión doble: reunión del CoCo seguida de una reunión general. Lugar para el event está por determinarse y el tema será uno propuesto por Alberto Balderas o uno sobre la gestión de proyectos de parte de Masa.
Aprendizaje. Hablé acerca de los triángulos de la gestión del proyecto y mostré un nuevo polígono que yo llamo el prisma lean-agile, que estoy proponiendo en la actualidad y he presentado un artículo sobre el tema al Agile Journal.

Book review: Innovation Games

2010-03-19T10:02:00.001-07:00

Everybody wants to better their businesses and make serious efforts to do so, but maybe we could be more effective is the efforts were less serious and more fun. Business communication is always challenging within the organization, with customers, providers, contractors, etc.. This is in part because they are not face-to-face and because most times one or more people who could add significant value take a passive role, in part because most times there is someone who enjoys dominating the meeting. End result is incomplete and biased information and decisions.

One main reason why games work is because (a) they are fun, and (b) they make everybody to actively participate. Hohmann's book is a great starting point. The games cover diverse needs and conducted properly add significant value (and save costs) to teams, projects, and entire enterprises.

Don't get serious... instead, start using this book!

Writing Spanish version of new Kanban book

2010-03-18T23:33:00.000-07:00

Great news, I have been given the opportunity to translate David J Anderson's new book entitled "Kanban: Evolutionary change for you technology company". Needless to say I am thrilled by this.
:-)

Agile Training Game Board

2010-03-17T09:41:00.000-07:00

Yesterday's talk at the BayAPLN meeting was on the Agile Training Game Board, proposed by David Chilcott from Outformations and Pat Reed from The Gap.

The basic concept is very simple. The same way that some of us actually use an agile dev board alike scrum at the training courses we offer, the ATGM shows the flow of stories from backlog to completion. What I think the contribution was is the emphasis on short timeboxes, 10 min in average and 20 min tops. This is particularly useful for training to executives because details are not necessarily important to them and they rather get the succinct version of things. They also encourage the thumbs-up-down-sideways feedback to consider stories Done. The board had extra columns at the end for value points and time, both important aspects to executives.

The talk included a stand-up game on self-organization to show how some concepts can be "explained" effectively and in shorter time through games.

Lean-Agile editor for the Software Guru magazine

2010-03-10T12:32:00.001-08:00

Software Guru magazine invited me to be the editor for its lean-agile section and I gladly accepted :-)

This is a great opportunity to help in contributing more effectively to the penetration of lean-agile in Mexico and hopefully Latin America as well; and at the same time increase de presence of Mexico within the global lean-agile community.

The best way to fix the Prius sudden-acceleration problem is by not fixing it.

2010-03-09T23:08:00.001-08:00

Did I get your attention? Good!
Tonight's news included yet another case of a Prius sudden-acceleration problem, this time in San Diego where the driver ended up being assisted by a police officer who used his police car to stop the Prius by driving in front of it to slow it down to a stop. Toyota's engineers are really scratching their heads over this problem and that particular Prius is now being analyzed very thoroughly in hope to figure out the cause.

So, how to fix this problem? Probably Toyota's engineers already thought about what I am about to propose but here it goes anyway: do not fix the problem! Okay so, before those of you who are still reading on what I think should be done is two things:

Verify the algorithm and its implementation. One very likely cause is the software that controls the car's acceleration and brake systems. If that is the case and engineers cannot find and fix the bug(s) then a better course of action would be to start from the beginning and (a) create a new algorithm, (b) analyze the algorthm quality as such, i.e. as an abstraction, (c) implement and test it simultaneously. Step (b) is extremely important because that is the best way to make sure the algorithm is robust. If we wait until implementation time to do testing then it will be harder to know if the problem is the algorithm itself or its implementation. I think this is the most viable, fast, and cost-effective course of action.
Unit level testing is not enough. One well know problem with measurement, from the physics standpoint, is that any attempt to measure something will affect what is being measured and therefore the measurement will be inexact. This means that once the algorithm and its implementation are robust it will be more effective to test at subsystem and system levels instead of inisolation.
Reproduce internal and external test conditions. The best way to reproduce a behavior is by recreating all conditions that triggered the undersired behavior. In addition to the car conditions this includes road, slope, weather, etc.

Building things anew might be a quicker and better way compared to trying to identify and fix what is wrong.

Presentaion on Lean-Agile and Innovation at the ITESM

2010-03-05T16:43:00.000-08:00

This morning I gave a presentation on Lean-Agile and Innovation at the ITESM (Monterey Advanced Studies Institute of Technology), which was broadcasted to its 33 campuses nation-wide via satelite and was also webcasted.

I talked about the motivation to create better products and services considering Quality, Value, and Design, then moved on to talk about fundamentals of Lean and Agile. Last I talked about the advantage of using games to foster innovation and did examples on planning and estimating, group cohesion, and product analysis. More specifically I used planning poker, pair drawing, and prune-the-tree games.

The oopsy part was that I used all of the allocated time giving the presentation so Q&A had to be off-line. But it was possible to compensate at least with the local audience through 10 min. of Q&A.

BTW, the ITESM staff did an extraordinary job with logistics, production, etc., and the campus is impressive and functional.

MexAPLN Feb 2010 meeting

2010-02-26T06:26:00.000-08:00

MexAPLN Feb 2010 meeting took place last night at the offices of Software Guru Magazine, a modern looking floor with cool artwork on the walls. Definitely a nice place to work. We had 10 people, three of them new with one of them from the city of Puebla. The central topic was to thumbs-up our charter's vision, mission, values, and principles and will be available before the end of this week. The discussion was rather short thanks to off-line work by 7 members in that most of the discussions took place before the meeting. We did a first-pass at the objectives and will be discussing them further as well as the other parts of the charter with the intention to finalize it at our March meeting.

There are numerous ideas and enthusiasm to start executing. I don't see a reason for MexAPLN to become of of the best!

Note: Software Guru has been making reference to a blog in Spanish written by Armando Peralta, check it out!

Second presentation at Congress in Mexico

2010-02-24T19:19:00.000-08:00

This morning I gave a second presentation on lean-agile at Mexico's Congress aiming at medium and small industry. It was probably not the best day to schedule it because today is Mexic's Flag day and logistics got a bit complicated. The presentation was successful in that all attendants got very enthusiastic about lean-agile and the Q&A session lasted over 1/2 hour. There were three nice outcomes:

1. The Deputy I started doing all this with concluded is time to bring my ideas to the Secretary of the Economy. I will be meeting two of its members either next week or at my next business trip.

2. An entrepreneur wants us to talk about how lean-agile can help his new life-science business.

3. I was asked to give a presentation at the School of Economy at the National University of Mexico.

One very cool thing that also happened was a person from an indigenous area in Mexico was there and asked me about how to use lean-agile principles to help the community of craftsmen better their business. This is obviously a very different context but after hearing details on how they are working to create and sell their crafts I gave her some ideas and advice I hope will help them. Of course I would love to get a chance to go there for a few days and create a direct positive impact.

Effective employee performance assessment via lean-thinking

2010-02-20T08:41:00.000-08:00

An eBay executive once asked me how I would go about doing individual employee performance review if lean-agile are team oriented. Effectively, in agile-lean thinking, we value team effort more than individual effort and consider individual rewards to hinder teamwork improvement. That doesn't mean, however, individual performance cannot be measured. As with enterprises, what we need to do is know what to measure.
We must use measurements that encourage the employee to improve teamwork through individual efforts for the benefit of the business and the customer. For example:

Measure sales executives in terms of the number of successful deliveries instead of the number of sales deals closed. That way the sales executive can't forget about the customer once the sales deal is closed. It is necessary to make sure the client gets what was paid for, and to do that it becomes necessary to work as a team with other groups in the company.

Measure developers in terms of how many stories got completed with good customer satisfaction instead of how many lines of code were implemented but rather . This developer has to interact with QA, the scrum master, the product owner, and customers to fully understand the stories and customer needs to ensure the code meets customer needs and has the quality required.

Measure QA engineers in terms of reduction of bugs in the code and increase of product quality instead of number of bugs found. That way the focus becomes building quality, as compared with showing how bad the product is. Activities are proactive, including higher interaction with customers and other teams instead of only the reactive activity of bug hunting.

Under such lean thinking the employees increase teamwork, quality, and customer satisfaction; and executives have an effective way to measure individual performance without fomenting individualistic work.

Some coming presentations

2010-02-19T11:30:00.000-08:00

I will be in Mexico City the next two weeks (Feb 22 ~ Mart 5) and during that trip I will be giving the following presentations:

Feb 24, Congress building. I will be giving my second presentation on lean-agile, this time to a larger audience that includes industry leaders and some congressmen. It is very likely that it will be broadcasted through the Congress TV channel.
March 5, ITESM (Instituto Tecnológico de Estudios Superiores de Monterrey). I will give a lecture on lean-agile and innovation which will be broadcasted to its 33 campuses accross the country via satellite and internet.

Also, Feb 25 is the MexAPLN meeting at the Software Guru offices starting at 7:30 PM. Address is Temstocles 34, 3rd.floor, Col Polanco, Mexico City.

Jim Highsmith's talk: Beyond scope, schedule, and cost

2010-02-16T22:53:00.000-08:00

I'm back home from the monthly BayAPLN meeting. This time we had Jim Highsmith give a talk entitled "Beyond Scope, Schedule, and Cost: rethinking performance measures for agile development". I read Jim's most recent book on agile project management and actually wrote a review on it (posted on by blog and on Amazon.com) and thought this talk was going to have as central point the new Agile Triangle as proposed on the book. I was very pleased that the presentation went beyond that. Jim exposed different ways in which we can measure performance by considering value and quality; and gave a good number of examples. He mentioned the importance on having a better standing point to evaluate and measure performance. A common factor on all of them is adaptability. The metrics must allow changes and be effective measuring under real-world variations. Quality could very well be the most important metric of all; but doesn't mean it should be the only metric to have.

Ikiru and why some lean-agile projects fail

2010-02-05T20:23:00.000-08:00

Many years ago when I was in college I had the opportunity to see the movie Ikiru (生きる) by Akira Kurozawa. As a nice way to finish my work week, I just finished watched it again while having dinner. The story is around an elderly man, Watanebe-san, who is a public office head of department who is diagnosed with terminal cancer. He immediately starts a desperate hunt to recover the 30 years he spend doing nothing as a public official, and after much soul searching he decides to help build a public park at a low income neighborhood. The park is finished shortly before his death, whose cause was unknown to his coworkers and family. At his funeral reception there are about a dozen other public officials of different ranks. It is there where an amazing display of bureaucracy is made clear, and after much drinking and discussing, those who remained at the room came to the realization of the reazon of Watanabe's death. Inspired by it they all determine to make their work as meaningful and really serve the public, only to get back to the same status quo once back to work.

There is a parallel to the story and why some lean-agile projects fail and, worse, why entire organizations fail in the adoption. Simply put, it is very easy to get back to the old habits. Many organizations claim to be doing agile, be it scrum, xp, kanban or whatever else, in reality they still do in good measure the same things they were doing before with minor modifications such as not sitting at their periodic meetings or using post-it notes for their use cases. This more often than not results in even worse dynamics than before the "adoption". If you want your organization to really adopt lean-agile then you have to fully embrace it and be willing to go through what it takes to really make the transition.

Cutter predictions 2010

2010-02-04T17:40:00.000-08:00

Cutter published its 2010 predictions back in mid December, which includes a prediction by yours truly.

Agile-lean will become the new mainstream approach to project management and software development. Latin America will become aware of this and will start investing heavily on its adoption towards the end of the year in an attempt to bridge the IT gap between developing and developed countries.

You can see the full list at:
http://www.cutter.com/predictions/2010.html

Presentation at Mexico's Central Bank

2010-01-26T21:43:00.000-08:00

Mexico's Central Bank (Banco de México) asked me to give them a presentation on Lean-Agile today. The experience was awesome starting with the venue. The Central Bank counts with a cluster of Colony Epoch buildings within the downtown Mexico City area (see photos for an example), which are as beautiful on the inside as they are from the outside. The presentation took place at a small but well-equiped auditorium and I had an audience of roughly 60 people. The audience was great and attentive during my 60-min talk, which consisted of Lean Agile fundamentals, case studies, hard data on agile benefits, reflections, and short speech about my services. I was then asked a series of good questions on some lean-agile aspects, on governance, and on comparison with other methodologies.

Next I had lunch with 11 executives and managers from the Bank at its private restaurant, which gave me the opportunity to have closer conversations with them and gave them the opportunity to ask lots of questions. To my surprise I received a limited-edition art book on Frida Kahlo (a famous Mexican surrealist painter) sponsored by the bank.

I have to admit the people I met and the bank itself exceeded my expectations and it would be great if I get to have the opportunity to work with them.

mute-deaf at Innovation Game online

2010-01-23T08:34:00.000-08:00

I was all exited about the opportunity to participate on an online Innovation Game with folks from APLN and BayAPLN while still abroad on business. I logged in and proceeded to dial in to the conference from a telephone only to come to a halt because the conference call requires a "#" at the end of the code and the long distance service at the place where I am staying interprets it as a call to operator so there was no way I could reach the conference call.

But where there's a will there's a way. I thought it would be an interesting experiment to see how effectively I could go about participating on the game while on a mute-deaf state. The game started and I felt I was at at real disadvange at first but soon after I realized that the entire environment provided an quite complete and friendly environment such that I soon forgot all about the audio feedback. For sure there were interesting conversations going on that I was missing, but the information I was getting through the game board itself, the text tab, and the actions tab were providing enough information for me to not only follow through but to also contribute!

Comparing the online experience with a face-to-face experience I would say that:

Face-to-face has the benefits of not only more effective verbal communication but also body language and higher encouragement for all stakeholders to participate.
Online has the benefits of counting on a log, making it easy for people to think more carefully about something or re-visit something without breaking the rhythm or distracting others.

Also, my being mute-deaf throughout the exercise proves the effectiveness of the playground experience that innovation games bring to the matter being discussed.

MexAPLN meeting: January 2010

2010-01-19T23:18:00.000-08:00

The second meeting of the MexAPLN was way better than the first one. The meeting was at the IDS offices. IDS is one of the two oldest sw dev services businesses in Mexico. Its building has a beautiful view of the 4th and 5th highest mountains in all of the American Continent.

This being the second session it was obviously very org related and the main subjects were:

Alejandor Escamilla from Software Guru reported that they received over 400 responses from a member's blog posted on its website
12 people (including myself) attended the meeting, 5 of them first-time. One person actually drove 180 miles one-way just to be there and headed back to his city of origin, Morelia, the next morning! ...and I used to think my 60-mile drive was significant.
We talked about what we need to do to be accepted as an actual chapter, about sponsorship and about logistics on meetings.
I reported that VersionOne showed a lot of enthusiasm about becoming an sponsor once we are ready for it
Main topic was Chartering. Since we were running out of time we decided to do some off-line work, discussing via web-conference to get more done and by the next meeting at which time we'll give it thumbs-up or down.
We decided to use Google groups instead of Yahoo groups as one of our comm tools.
Next meeting is at the offices or Software Guru.

Too much material for one session, of course but there was good progress.

Once this is done we'll have the foundation and a good start to become a relevant chapter.

Thanks to everyone who has contributed.

*** Important Note:
Paul Culling from VersionOne wrote a comment on the original posting, on which I used the workd "demands". My response is: Paul, I apologize if the word created some interpretation. One of the definitions of "demand" is "the requirement of work". The communication through Cesar has been quite clear and I informed at the meeting that VersionOne will be happy to become a sponsor, but first we have to prove that we are an active community of practitioners of agile and lean, and that is what is the requirement of work we have to do to earn your sponsorship.
I edited the posting in hope that you agree with the new wording, otherwise let me know and I'll be happy to rephrase it.
~Masa K Maeda

MexAPLN meeting: January 2010

2010-01-11T17:45:00.000-08:00

The January 2010 meeting of the MexAPLN meeting will take place at the IDS offices at 7:30 PM on January 19 (Tuesday). Theme of the meet is Chartering.
Adddress: Av. Insurgentes Sur 1388, 11th floor.

See you there!

Book review: Agile Testing by Lisa Crispin and Janet Gregory

2010-01-06T00:27:00.000-08:00

Agile testing is a great book to both new and seasoned test engineers and test managers. At 533 pages, the book might feel a bit heavy but it is actually a pretty light and practical read if you read it to get a solid foundation on agile testing and then as reference. Note that the book is not about test coding techniques.

Part I is an introduction to agile testing and proposes ten principles for agile testers. What I don't know is if there are really 10 principles or if Crispin and Gregory forced it to be that specific number because it sounds better than 9 or 11. In any case, this chapter is a must read for all. Part II discusses organizational challenges, specifically cultural, logistical, and transitional from typical processes. This is a must-read for managers and team leads, and highly advisable for engineers if you want to have a successful test organization fully integrated with an agile organization. I personally encourage the division between development and testing to disappear completely. Part III is about he testing quadrants proposed by Brian Marick (one of the Agile Manifesto signatories) a while back. This is the first time I see the quadrants treated in larger detail and highly recommend it as a must for all.

Part IV is about test automation. It is a good read to understand the advantages of test automation and proposes a test automation strategy. This is a good starting point for test organizations that are new to automation but for mature test automation organizations it might add little value. Test code writing techniques are beyond the scope of this book. Part V illustrates the previous parts and then some by following a tester's activities through an agile iteration and the activities prior to it.

One problem I see way too often in test organizations and the way companies treat their test organizations is due to a lack of understanding not only of the difference between Quality Assurance and testing but also because of the place testing has hi people's minds. This book is a big help to create a cultural shift for the better.

Book review: Agile Project Management: Creating Innovative Products (2nd Ed.) by Jim Highsmith

2010-01-05T23:50:00.000-08:00

Jim Highsmith is one of those few people that have really been-there-done-that and continue to be a pleasure to meet, accessible and down-to-earth. But anyway, this review is about his new book and not about him so I'll get to it. From my perspective Agile Project Management has two accomplishments: It fills in the gaps left by other books on the same subject and brings us one step further on different ways to see and approach the way we manage agile projects, within and outside software development.

Chapter 1 contains one of the best introductory chapters I've seen in any book on management. It is both a great motivation to read the rest of the book with interesting real cases. This chapter also refreshes the audience on the basics of agile, including the declaration of interdependence, which is explained in detail throughout the book, and provides some lesser known and relatively recent basis such as the Agile Triangle (not the Agile Iron Triangle).

Chapters 2, 3 and 4 are a detailed study of leadership values: Value over Constraints, Teams over Tasks, and Adapting over conforming. Similar to the agile values in the manifesto, these invite a cultural change in the way we measure project performance, lead teams, and focus on customer needs. Highsmith explains how the quality of the product and the work environment is improved through these. He also emphasizes on the fact that fail-often-fail-early is of very hight value in building a successful agile organization.

Chapter 5 has two objectives, to introduce an agile enterprise framework consisting of four layers that is arguably more appealing to large organizations, and to introduce an agile delivery framework consisting of five phases. That Agile Delivery Framework is explained in higher detail within the following 5 chapters, one per phase: envision, speculate, explore, adapt, and close. The last part of this chapter provides important practical information on the delivery framework. Chapter 6 has one of the best prep work descriptions you might be able to find and includes a project data sheet and the Tradeoff Matrix, which you might find useful. Chapter 7 digs into the speculate phase. Its contents are useful for those new to agile but not necessarily for those familiar with its basics since it explains fundamentals such as the backlog and story cards. Chapter 8 is about release planning. It introduces some planning strategies and a product planning structure that goes from the roadmap to the iteration. I recommend everybody to read this chapter since it has a bundle of snippets of useful information. Chapter 9 explains the explore phase and includes iteration planning, estimating, management and monitoring. It also talks briefly about technical debt, continuous integration and refactoring at a level good for managers but too light for for technical people. A good portion of the chapter is dedicated to coaching, one of the best parts of the book. Chapter 10 deals with the last two phases: adapt and close. It discusses how diverse activities usually considered secondary are of great importance to successfully fulfill customer needs and rapidly adapt to add value, increase quality, improve performance, and have a realistic view of the project status.

Chapter 11 is about scaling agile projects. Scaling has been a hot topic within the agile community during the last couple of years and Highsmith takes the opportunity to introduce an agile scaling model within the software development organization (other areas of an organization are beyond the scope of the book). scaling is treated at both size and distance levels, which increase the level of uncertainty and complexity. The model has five components: business goals, agile values, the organization, the product backlog and processes. The last three of these are treated differently at product, project, and feature level. I recommend you to read this chapter even if you work with a small team because there is value in understanding what works in the small and what works in the large. It may help you improve what you do in the small.

Highsmith does a great job discussing on chapter 12 how to do governance within agile projects, an aspect most small companies might not have to worry about but most mid to large organizations have to. Chapter 13 is an overview of metrics at a high level. If you want to learn about this topic in technical detail you are better off reading other books such as the David J Anderson's book on agile management and conference proceedings. Chapter 14 is a rather motivational reading on the value of agile

In conclusion, this is a book of high value to get up to speed on agile project management and learn more, recent advances in agile that are useful beyond software development and both in the small and in the large. Although the book doesn't advocate a particular agile development framework it leans mostly towards scrum.

Good kanban tool

2010-01-02T11:19:00.000-08:00

LeanKitKanban (http://leankitkanban.com/) is a simple but powerful tool to do Kanban. It is fairly good in that it allows you to create your kanban boards very easily as it is also to add users (with avatars if so desired) to it with different roles. Users can subscribe to board events via email or RSS feed.
It is at beta and collecting suggestions.
Check it out!

Gotta love Apple's service :-)

2009-12-30T20:06:00.000-08:00

All my experiences with Apple Computer's customer care service have been no less than awesome, and my last one topped them all.

Two days ago I brought my MacBook Pro to the Los Gatos store because I wanted to see if it was possible to give it a general clean up. There was nothing operationally wrong with it. The person who took care of me told me they do not offer service that consists of just cleaning the machine up from the inside, so I thought that was to be the end of the story and I would go back home with the machine as-is. To my surprise he had a second look at the laptop, noticing some dust specs on the monitor that I have pointed out and also noticed a good amount of wear on the keyboard. He decided to accept the machine reporting those issues and told me the machine was going to be ready in 5 to 7 business days.

Well... just two days later (today) I got a phone call from the Apple store to inform me the laptop was ready for pick up and so I assumed the technicians looked at it and set it for pickup without having done anything to it other than replacing a missing screw on the back. What a surprise when I picked it up. Apple replaced both the screen (the entire part, including the shell which I noticed because the original one had a dent) and the keyboard. The laptop is now as good as new and the cost of parts and labor was nothing... zeppo... nada because it is still under its 3-year warranty. I honestly expected the warranty to cover actual damages that required repair and not the minor issues my laptop had due to wear and tear.

Apple, you rock!

Book Review: Lean-Agile Software Development: Achieving Enterprise Agility

2009-12-30T13:11:00.001-08:00

Authors: Alan Shalloway, Guy Beaver and James R. Trott.

Between December of 2008 and April of 2009 I participated on a series of 6 webinars on Lean-Agile Software Development given by Allan Shalloway, under NetObjectives, and knew that the book—same title as the webinar series—was being finished at that time so I was definitely looking forward to it. I was very glad when the publisher asked BayAPLN for a review, which gave me the opportunity take over such a pleasant task.

The basic premise of the book is a better approach to drive software development efforts to maximize realized business value. It pays particular attention to how to scale agile to the enterprise; a main topic of discussion within the agile community during the last two years. The book’s proposal is to use lean-agile instead of agile alone and to “extend” scrum to what the authors call scrum# which is, simply put, doing scrum while also doing lean thinking. Particular attention is paid to the lean principles of waste elimination and optimizing the whole. The authors put together a body of knowledge that would otherwise take lots of research, reading hours, and trial-and-error experience. The theme itself is not new, you can also consult, e.g., books on lean software development by Mary and Tom Poppendieck, and a book on scaling lean and agile development by Craig Larman and Bas Vodde. Shalloway, Beaver and Trott’s book is easy to read and very informative at a conceptual level and also at an anecdotal level. The cases they present actually add a lot of value to it. I consider this to be a must for executives, managers, and non-technical people involved on software projects because it will help them understand better what lean and agile can do for their organization. It is also helpful to software and QA engineers as a great informative reading.

The book consists of an introduction, three parts, and an appendix. The Introduction sets the tone for the book and revisits the basics of agile and lean (manifesto, principles, etc.). But make no mistake; this book is not for people new to agile or lean, and for those who are it is better to do some previous reading or they might get lost at times.

Part I starts with a discussion on why it is not preferable to think of software development as a science or a technique instead of as a discovery means to the end of satisfying a need, and gives a gentle introduction to some lean principles within software development. Chapter 1 nicely explains the transition of manufacture-based practices to software development. Chapter 2 addresses the business value added by agile and lean through better customer interaction, better delivery, and product focus. Chapter 3 gives some insights on how to get started with the transition to lean-agile, and chapter 4 dives into lean thinking for portfolio management, which I consider to be the most important chapter of this part because it gives a good deal of practical advice to do high value-added changes to your organization.

Part II Focuses on lean project management. Chapter 5 addresses some limitations of scrum that are particularly important when considering scalability. The authors propose what they call Scrum# as an extension of scrum that includes lean thinking. I personally think the problem is not scrum itself but rather how we put it into practice and what they propose as scrum# to me is nothing more than having a better (lean) way of applying the scrum framework; maybe because I learned about lean years before scrum came to be and so I have always used lean thinking when doing scrum. In any case, I would advocate to simply keep the term scrum as-is and encourage people to learn and apply lean to it rather than getting into new terminology, which I think might create confusion instead of clarity. I was very pleased to see that Kanban was added to the book and wish it had been explained in more detail, on a dedicated chapter, because kanban is very powerful in eliminating some disadvantages of scrum and it will gain importance as a highly effective software development framework. Chapter 6 is about iteration 0, which is the preparation phase before starting your actual scrum iterations. I entirely agree with the need to do the prep work but I have never been fond of calling it iteration because in people’s minds it time-boxes a very important phase that not necessarily—and almost never—takes the same amount of time as the actual scrum iterations (see, e.g., Jim Highsmith’s book Agile Project Management). Chapter 7 is a good explanation on how to do lean-agile release planning. Chapter 8 explains the importance of visual controls and information radiators, which is a subject that most executives have a hard time accepting from the lean-agile perspective but once they fully realize their high value regardless of their simplicity they usually embrace these fully. I definitely enjoyed seeing a chapter on the role of QA (chapter 9) because this is often under-treated in the software development literature in general, unless it is on a dedicated QA book. This inclusion goes well with the lean-agile principles of working in teams and optimizing the whole.

Part II addresses scalability at enterprise level on chapter 10 with a very effective discussion format. Management’s role in lean-agile is treated on chapter 11 with good arguments but I would’ve liked it better if it had elaborated further on this very important role. Chapter 12 was one of my favorite ones since it does a good job at discussing the Product Coordination Team, a relatively new approach that has proven to be better suited for scalability than scrum of scrums. Chapter 13 is rather a teaser about the importance of a better, lightweight, approach to software architecture and design, which is okay since it is beyond the scope of the book.

Part III consists of chapter 14 only and is an epilogue to the book that basically encourages people to explore and learn more about lean, primarily, and about agile.

Appendix A explains Steve Bockman’s Team Estimation Game. A dynamic, fun, and effective step further of what you can do with the Planning Pocker that is also scalable. Appendix B presents the authors’ model of lean-agile software development, a nice quick reference to refresh the key concepts.

Alan, Guy, and James wrote a fabulous book that is a must-read for those interested on a successful lean-agile adoption whether or not you need to scale.

The Downfall of Agile Hitler (Funny stuff)

2009-12-22T17:48:00.000-08:00

The downfall of Agile Hitler video

Enjoy :-)

Cutter Consortium 2010 predictions

2009-12-22T17:01:00.000-08:00

The Cutter Consortium just published its 2010 predictions.
http://www.cutter.com/predictions.html
Three of them are related to Agile.

APLN chapters in Latinamerica

2009-12-20T11:43:00.000-08:00

Back last June I came up with the idea of staring an APLN chapter in Mexico. After talkng about it with several people in both the USA--at the BayAPLN mainly David Chilcott and Cesar Idrovo--and Mexico (polling people to see how much enthusiasm there is about it) I decided to go for it. Coincidentally an agilist from Costa Rica, David Alfaro, contacted BayAPLN in October and so we held a teleconference USA-Mex-CR (since I was in Mexico on business those days) to brainstorm how to get those chapters started. I suggested David A and I to keep in close contact to share experiences and help each other out in addition to getting coaching from David C and Cesar.

Then in November I had the opportunity to meet a group of Brazilians let by Guilherme Chapiewski, who were in San Francisco for the QCon conference, and invited them to the BayAPLN meeting to be held the following day (talk about good timing). They all attended and loved it. Guilherme told me he would like to get a chapter started in Brazil.

Long story short, David A has been actively increasing awareness on agile in Costa Rica and is working towards getting the first meeting. We learned that a chapter in Brazil was started a while back but didn't succeed and current efforts are towards re-starting it. From my side the first MexAPLN (unofficial for now) took place on Dec 8th in Mexico City and was a great start, with 8 executives from diverse enterprises attending.

Several ideas I have in mind are:

Leveraging the fact that we have close relationship with BayAPLN (with me now being part of the Coordinating Committee) to figure out ways to help those chapters get up and running.
Growing the MexAPLN to become the prime chapter in Latinamerica
Create a latinamerican APLN metachapter to have higher impact in that geographical area and organize world-class events.

Last BayAPLN meeting of 2009

2009-12-20T11:29:00.001-08:00

The last BayAPLN meeting, held a the Tacit Knowledge offices, was a retrospective of the year. There were 24 people at the meeting, which is low for BayAPLN meeting standards but understandable given that lots of people are either out of town, shopping, or wrapping things up at work to finish the year in balance.

What was done and accomplished throughout the year was quite impressive, for example:

329 registrations at the yahoo group
394 registrations at the linkedIn group
Average attendance per meeting was 44, and topped around 70.
We had a pretty good number of Agile-Lean celebrities giving presentations at meetings on topics related to agile and: current economy, adoption patterns, group coherence, learning games, agile transition styles, scaling scrum, Personas and story maps.
Co-sponsored the Agile Open California 2009 open space.

We also noted areas of improvement and action items for next year, such as:

Better task distribution
Make presentations more easily available on our website
Increase knowledge, e.g., adding terms on Wikipedia
Give support to new APLN chapters such as those in Mexico, Costa Rica, and Brazil
etc

We all look forward to an even better 2010. First meeting is Jan 19 and the activity is Chartering.

Journey to the Centre of the Ministry of the Economy in Mexico: part I

2009-12-14T15:48:00.000-08:00

I started traveling to Mexico on business last January with the objective of injecting Agile and Lean practices into Mexican businesses. By the end of my first 12-day trip there I came to the conlusion that way too little was known about these and so instead of focusing on getting some contracts it was necessary to first evangelize about them, thus I decided to change strategies. As result, between January and April I gave 17 presentations on agile-lean at technical and leadership interest groups, associations, academia, and companies. The presentations were received with great enthusiasm and business-level meetings came out from some of them.

I was glad with the outcomes until another reality hit. Numerous Mexican businesses in the high tech, financial, and other white-collar sectors have to face a situation I expected to see on blue-collar sectors only, namely that of government mandated corporate governance such as ISO, CMMI, et-cetera. There is even a recent new regulation under the name of MoProSoft, a mexican model to regulate software development maturity that the Mexican Government approved as a norm for software development. Furthermore, it is undergoing evaluation by ISO to be accepted as a new standard. By now you might be wondering, is MoProSoft a model or a standard? Well, I wonder that myself and haven't got an answer for that yet. What I can indicate is that MoProSoft is, in good measure, a 1:1 mapping between some aspects of ISO and CMMI, plus the addition of a set of templates that need to be followed to fulfill its compliance requirements. Sounds heavy? It is! All those initiatives have been backed up by the Ministry of the Economy in Mexico.

I came to the obvious conclusion that if Agile-Lean are a great alternative to the aforementioned approaches to software development, and if corporate culture in Mexico is still heavily guided by government regulations then the obvious move to be effective was to reach that same government organization to get it to back up agile-lean. So, I took upon myself the quest for it. In March of this year I started talking to people in industry, academia, friends of friends, and so on trailblazing through professional networks, and going through numerous frustrations until by the end of November I got the luck to meet a person who connected me with a congressman directly who is directly connected with the Ministry of the Economy (this part is a great anecdote but I'll hold on to it for an article I'm writing). I met with the congressman, who liked what I have to offer so he asked me to give a presentation to other folks at the Congress building before bringing this to the attention of the Ministry of the Economy; and so I did. As result, those who attended gave to my proposal a thumbs-up and they agree this should be escalated to the Ministry. The congressman asked me to give another presentation, this time to a larger audience to then bring it to the Ministry of the Economy next month.

It's been an arduous journey but I am glad that I finally got to get some progress done before the end of the year. Hope things will move faster next year and that my objective of getting agile-lean be backed up by the Ministry of the Economy so that we can penetrate market more effectively.

I'll make a part-II posting when the time for it comes.

Editor's pick at Cutter Consortium

2009-12-14T15:36:00.000-08:00

I wrote a short article for the Cutter Consortium, based on a previous blog, which ended up being the Editor's pick for this month. www.cutter.com

First MexAPLN meeting

2009-12-08T20:22:00.000-08:00

The first MexAPLN meeting took place today at 7:45 PM at the Marie Callender's restaurant in Mexico City located on Insurgentes Avenue. Attendees were executives from diverse entities: Sergio Eduardo Duran Rubio (Accival), Martin Villalba Paredes (FIDEM), Alejandro Escamilla (Software Guru magazine), Armando Peralta and Ivan Carlos Rivera (Infotec), Jesus Flores, Jennifer Vazquez and René Molina (Bytline), and myself.

After introductions I talked briefly about how agile got started under a bottom-up approach and how as time has passed by, the practices matured, and the chasm has been crossed, executives are taking a more important and proactive role towards adoption thus the increase of top-down adoption. I then talked about what APLN is and, as a case, how BayAPLN operates. Next explained the benefits that MexAPLN can provide to industry and to us as professionals by bringing awareness on agile-lean.

Last we talked about the success factors and did some action planning for the next meeting, that time to be held at a company instead of at a restaurant.

To finish we did an intro planning pocker exercise for those new to it.

Photos I took today on my way between meetings in Mexico City

2009-12-01T16:22:00.000-08:00

Lean-Agile could've saved this company

2009-11-27T11:21:00.000-08:00

Air-Go was a software services company that went belly up. It's former CEO reported 10 reasons it failed. When I read about it I couldn't stop wondering where that company would be nowadays had it been an lean-agile company. I identified 8 of the reasons could've been fixed doing lean-gile
1. Poor people interaction. There was too much focus on personal benefit instead of team and business benefit. Also, interaction with customer was low.
2. Lack of vision. Chartering was never done and the company had no direction.
3. Different values. Individuals and teams were not on the same page with respect to what value should be added and how to add it.
4. Lack of focus. Teams handling too many projects at the same time instead of one at a time.
5. Overestimating. No knowledge of their teams' velocities.
6. Failed often but late. Most of their projects failed and failed too late.
7. Too much planing and very little execution. BDUF!
8. Overconfidence and designing for best-case scenario. Lack of planning and incremental/iterative development.

A recipe to improve enterprise success-fail project rate

2009-11-27T10:53:00.000-08:00

Larry Gelwix has been the head coach of the Highland HS Rugby team in Salt Lake City for 36 years. Along that time he has accumulated a 413-9 win-loss record; the most impressive any sports coach—professional or amateur—has achieved ever. Wouldn't it be fantastic if our projects had a similar success-fail rate? Some aspects of his coaching style are well in tune with some agile-lean values and principles:

• High degree of teamwork: doing collaborative work with all stakeholders within and beyond the project boundaries makes much more likely to achieve team coherence.
• Horizontal leadership: to give room for self-organization, delegation, empowerment of the team to make better decisions, and boost skill improvement amongst team members. This fades away micromanagement and a command-and-control culture.
• Setting goals: short, achievable milestones which are goals on their own right. An incremental-iterative approach to create products foments discipline, increase quality, and motivate customers to provide feedback throughout the creation of the product they want.
• Realizing potential: by trusting and empowering the team we form motivated individuals. And a motivated person is usually more productive and less prone to make mistakes.

This recipe doesn’t ensure project success, but it can help your enterprise become hyperproductive and, as a consequence, successful. As Larry said: “good decisions don’t make life easy, but they do make it easier.”