Wednesday, October 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.

Wednesday, October 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. :-)

the most voted topic to cover at agileperu

epeupc
@ was the most voted topic to cover yesterday in the monthly meeting of @ @ /via @

Wednesday, October 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

Friday, October 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.