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. :-)
Dec 7, 2010
In a Kanban Adoption, Go Lean
Recent posting on the Cutter blog
http://blog.cutter.com/2010/12/06/in-a-kanban-adoption-go-lean/
http://blog.cutter.com/2010/12/06/in-a-kanban-adoption-go-lean/
Oct 30, 2010
Oct 27, 2010
It's begining to look a lot like Christmas... I mean Kanban
There was a workshop on Technical Debt this morning at the 2010 Cutter Summit in Cambridge, MA, Given by Israel Gat and Jim Highsmith. It was a good one, although short, in which several important points were discussed and I decided to blog on one specific point.
Towards the end of the workshop Israel proposed an event-driven process control (EDPC) based on the Ken Schwaber's process control view of Scrum. The fundamental idea is to replace the daily scrum meetings with on-demand meetings triggered by failure events on the project's continuous integration activity. That is, daily standups are to be no longer and instead the meeting will occur between all stakeholders involved with the failure at continuous integration time. This is motivated by the lean manufacturing modus operandi of stopping the production line when a defect is detected. The determinant is created by using Statistical Process Control over defects, in which the trigger is a policy. Israel emphasized on the fact that quantitative data enhances the power of scrum to reduce technical debt.
This was a rush of fresh air. Kanban does that! ...and more. Anyway, the point is, as agile methodologies mature they are gradually moving towards where Kanban already is. Kanban offers quantitative metrics such as statistical process control over delivered value and other policy-driven factors, cummulative flow, mean lead time, and other.
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.
Oct 22, 2010
Follow these leaders
From Chrstopher Avery:
Follow these leaders @gilbroza @CoachingLeaders @masaKmaeda @Leadership_Gold @Mark_Sanborn @VoxLive @Leadership__101 #ff
Follow these leaders @gilbroza @CoachingLeaders @masaKmaeda @Leadership_Gold @Mark_Sanborn @VoxLive @Leadership__101 #ff
Oct 20, 2010
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. :-)
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. :-)
the most voted topic to cover at agileperu
@epeupc epeupc
@masaKmaeda #kanban was the most voted topic to cover yesterday in the monthly meeting of @agileperu @epeupc /via @lshimokawa
Oct 13, 2010
WIP Limits and how to leverage to improve flow- Lean Agile and the Lean Agile Prism
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
Oct 8, 2010
Competencia en trabajo de conocimiento es algo malo
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.
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.
Jun 25, 2010
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
----- 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
Jun 24, 2010
What makes a good manager?
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.
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.
May 28, 2010
Webinar: Moving from Failing to Successful Agile Adoption
----- 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
----- 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
May 21, 2010
New game: Packing Peanuts to learn about technical debt
----- 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
----- 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
May 20, 2010
Making pamphlets, my Kanban game has 5 stars :-)
----- 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! :-)
----- 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! :-)
May 19, 2010
Book Review: Kanban: Successful Evolutionary Change for Your Technology Business
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.
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.
Subscribe to:
Posts (Atom)
