Improving People and Processes

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

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.

A case of Lean-Agile Kanban adoption with value innovation

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

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

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

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

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

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

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

Rapid Maturity on sight

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

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

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

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

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

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

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

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

----- 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

Snow Crash and the emerge of lean-agile

----- 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.

Second presentation at Congress in Mexico

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.

Presentation at Mexico's Central Bank

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.

MexAPLN meeting: January 2010

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

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

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.