Kanban in the Wild

I went to a local upholsterer this weekend to pick up one chair he fixed and drop off another, and what did I see?  It might look familiar to those of us who practice Agile on a daily basis:

Apparently, the shop owner has used a system like this for decades.  It's a Kanban system, although he had never heard the term before. The "Waiting for" column is his backlog, things that are blocked for some reason (materials, payment, etc.).  "Ready to go" is his list of projects that he can work on next, and "Doing" represents his work in progress. Due to the size of  his shop, he can really only have 3 projects in progress at a time.

And true to his system, since I paid my deposit and he had the fabric in-stock, my sticky is in the "Ready to Go" column!

Enterprise Learning: notes from IBM Innovate 2013

IBM described how their enterprise training strategy for their Global Business Solutions division has evolved to support their new DevOps culture.

IBM realized that their training model resulted in many of their employees having what they referred to as “shelf skills”: meaning skills that are not used (think shelfware).  They referred to this as ‘waterfall learning’: gaining knowledge without knowing why or how you are expected to use this information. At the same time, their development organization was making the push towards becoming a more agile, DevOps-focused institution.  They realized that formal training and continuous delivery would have a hard time co-existing, since the deployed software had the potential of changing faster than it would take to develop a traditional training course. 

This encouraged IBM to change the way they train their employees on technical items that are important to the organization over the past few years, switching their focus from a formal, managed method to more of an informal, supported method.

They have done this by transitioning their classroom learning model to a “community of practice” (COP) model. The COP model at IBM is formal, with employees encouraged in their annual objectives to actively participate in COPs.

They quickly found that implementing this model was somewhat harder than they initially thought. A traditional weakness of a COP is how to onboard new members to the community; you would want the level of technical topics in the community to be of a certain complexity to encourage domain experts to participate fully.  In order to ensure that employees joining a COP had a certain base level of understanding of the topic, IBM created what they called “Learning Circles”.  The premise behind a learning circle is: if an individual wants to learn about a topic, they should have access to a trusted list of resources that have been vetted by a known expert. Domain experts were encouraged to contribute material to the Learning Circle to become better known in the community and build their ‘trust network’.  Learning Circles have the goal of getting their members a baseline level of knowledge so they would feel comfortable participating in discussions in the affiliated COP.  

A participant in a Learning Circle has the goal of demonstrating competency in the field of study.  When they feel they are ready to participate in the full COP, they have the option of ‘self-graduating’ from the Learning Circle. At this point, IBM management starts to keep track of the use of this skill – the employee has six months to use these new skills in their job or engagement.  This encourages employees to keep their skills current to their jobs, or help gain skill that can move their career along a new path. This approach appears to align individual training with the needs of the organization, IBM measured that 82% of LC graduates reported that they used their new skills within 6 months of graduation.  Additionally, there was an 80% overlap between the list of skills being learned by employees to a survey of skills that customers said they wanted.

When measuring the effectiveness of the LC/COP model, IBM realized that the communities with higher rates of participation had much better content than smaller communities. In order to boost participation in communities across the board, IBM opened up the communities so members from outside of IBM could join a COP: first business partners, then to the general public.  These will soon be available on the IBM developerworks site.  The concept is the creation of a ‘system of engagement’ with customers using their tools.  IBM hopes to strengthen relationships with their clients by giving away this basic ‘how to use our tools’ content.  They are looking to use this as a new engagement model; it gives many of the advantages of a face-to-face meeting, but is much more scalable.

Enterprise Learning Key Take-Aways:

A key for the IBM training model was that as they transitioned from a traditional learning environment to a self-guided model is that they continued to give their employees time to learn new skills and tools, trusting them to learn the skills that would help the organization. 

Culture Change: notes from IBM Innovate 2013

I attended a session which described how IBM built what they referred to as an ‘Agile Roadmap’ using a cross-business team. 

The presentation began with some alarming statistics from an IBM-funded study: 59% of companies listed culture as the key inhibitor to the adoption of agile practices. 70% of all change initiatives fail, with the following key areas listed as the cause of organizational failures:

1.       Poor executive sponsorship

2.       Lack of employee involvement

3.       Ineffective change champion

4.       Underestimating the change effort

5.       Ad-hoc approach to change

The IBM ‘Agile Enterprise Transition Community’ realized that if they wanted the organization to fully benefit from an agile transformation, they would have to focus on changing the underlying culture of IBM. A direct quote from the presenter: “you can not change culture by adopting a new set of tools.” Corporate culture reflects the reality of the organization – the values, practices and traditions that have made a corporation successful; this is something that is very difficult to change.

IBM consulting has a “Better Change” process that they have used to help their clients make cultural transitions; this was used as a framework for framing the changes the committee proposed to make internally.  The process is loosely based on John Kotter’s Leading Change approach, which has eight steps:

1. Establish a sense of urgency: Determine what is driving your need for change – the greater the urgency, the better chance you have of making changes.
2. Create a powerful guiding coalition: Bring together business and technical personnel to remove impediments to success. Change cannot be enforced; it must be encouraged and supported. Determine how to achieve many small successes early in the initiative to build momentum and gain credibility. Use these lessons to determine how to leverage wins across the organization. Put out a call for volunteers at this point, who believe in the need for change and will act as additional grass roots voices across the organization. The coalition at IBM was organized in this fashion:
3. Develop a vision and a strategy: Craft a mission statement, articulating this will help the community get on the same page.  Ensure everyone uses a common set of definitions to describe key goals and deliverables.  Make sure everyone understands the problem, such as: “if we cannot make this change, the contract is going to be awarded to another company who can make this change.” The mission statement will simply lay out the strategic vision, but will not give any indication about what will need to be done to achieve the goals. Again, mandating change will reduce the chances of success.  If the vision is dictated, it isn’t our vision – work out the vision together.  As an example, the IBM vision was: "Uses continuous stakeholder feedback to deliver high-quality, consumable code through use cases (user stories) and a series of short, stable, time-boxed iterations."
4. Communicate the change vision: The vision needs to be communicated from the top, all the way down the management chain to the individual practitioner. Do not be shy about communicating the vision to anyone and everyone!  The presenter made the analogy of two workers in a quarry: when the project manager asked one what he was doing, he said “cutting stone.” When he asked the other, he said “building a cathedral.” The second worked understood the project vision.
5. Empower a broad base of people to take action: The volunteers identified in step 2 are essential to this step. They need to be empowered and supported to make change. It is essential to have volunteers from a wide range of responsibilities, they can be used to identify and eliminate blockers to change. Some examples were given; volunteers can lead courses, coach other employees, and help craft new practices. IBM would bring the most influential volunteers together to hold an “Academy of Technology Agile Conference.” This was a series of virtual conferences, webinars and events, plus face to face local events. Members detailed successes and failures, and gave them an opportunity to engage with other change enablers across the organization.  The committee took this time to formally recognize the valuable work the volunteers were doing.
6. Generate short-term wins: Scrum is very good to do this, due to the short turnaround time for deliverables and the quick incorporation of lesson learned. Wins will help you gain credibility across the organization.
7. Consolidate gains and product more change: This is one of the more difficult steps. Adopting agile practices can directly impact business investment gates: does your business process framework hinder, tolerate, or actively support agile practices? As an example, one of the first IBM business gates required the proposal to completely define requirements; this needed to be changed.  IBM is currently in the third iteration of changing their business practices to support agile practices.
8. Anchor the new approaches into the culture: It may take some time for employees to practice the new behaviors before they become ingrained – making the new culture. Some problems may occur during this phase: the executives sponsoring the initiative may move on, or you may declare victory prematurely. The agile steering committee needs to be kept in place and vigilant to ensure that the organization sustains the transformation.

One of the last points emphasized was a quote from John Kotter regarding what does not work when changing a culture:

"Some group decides what the new culture should be. It turns a list of values over to the communications or HR departments with the order that they tell people what the new culture is."

Key Take-Aways:

• This was an excellent presentation. The presenter was Elizabeth Woodward, who was an Organizational Consultant in IBMs Office of Strategy.
• An overall change vision must be created and articulated across the organization, to the point that any practitioner knows how they are contributing to this vision.
• Employees effecting change need to be empowered and supported by the organization.
• Cultural change cannot be made through the incorporation of tools, or by dictating new processes.
• Practitioners need to be part of the transformation if this is to be successful.

Overheard at Work

From the two developers pair programming across from me:

"Ooo! We did it! That's good, right?"

"I'm not so sure that's good. Or right."

"All right. We'll put it back."

"Damn."

Pair programming is the best.

Build Breaker!

One of the most noticeable features of the team room I work in is the traffic light which reports the status of our Continuous Integration builds. We really like it when the light is green. However, what happens when one of the builds is broken and the light is red? You can immediately tell there is a problem, but don't have any visual cue that anyone is working to fix it.
At past jobs, I've seen a highly-visible token of some sort used for this purpose, developers working on a critical fix would put something on their desk to indicate that someone is working on the problem.
On Monday, our scrum master presented the team with the best token I've seen to date; I'll let the picture of it speak for itself.

Congratulations, Phil - for being the first bearer of our stylish build-break hat!

Pair Programming - when your pair is 20 miles away?

I am working at home today, my furnace broke last night and I am waiting for a plumber to get the part he needs to fix it. However, our team is in the middle of a sprint and I need to get work done on a number of tasks I was planning on doing with another member of the team in a pair programming exercise.  What's a 21st century developer to do? Enable himself with collaboration tools!
This morning, we set up a online meeting, and shared one of our screens.  I was fortunate enough to have a VOIP headset, so I was comfortably able to be on a long phone call without having to take my hands off the keyboard.
Much to my surprise, this arrangement worked out better than I could have ever imagined. We have both been working away on our task without any loss of productivity - actually even having a minor productivity gain when we needed to run the same test in another development environment to compare the results of our changes versus the baseline and all I had to do was click a button to share my screen -  allowing us to work on another system without having to move.
I am amazed that technologies such as Remote Desktop Connection, VPNs, and IP telephony have matured to a point that allows me to pair program with someone in another office almost better than if I was sitting next to him. These tools certainly help out in cases like this, when someone is forced to stay at home unexpectedly.