Geek Philosophy

I recently attended an Agile Vancouver talk by Bill Wood of Ping Identity on the subject of “Metrics Driven Agile Development”. I’ve been interested in metrics for some time as a result of following the work of David Anderson, so I had looked forward to hearing from an experienced manager who actively uses metrics on an agile team.

Bill opened the talk with a few points about Ping’s philosophy towards metrics. He admitted that many metrics are not scientific measures and can be prone to inaccuracy, but they can still be useful to help ground a company that’s working in a rapidly changing environment. The use of metrics is simple – gather some metrics in as consistent a way as possible, monitor those metrics, and question change. In this case, change means for the better or for the worse. In this way, metrics can provide a good way to “Check” when implementing a Plan Do Check Act cycle of learning. Some of Ping’s other philosophies and practices reinforce the value of metrics, such as the idea of “Going Honest Early” – bringing up potentially problematic issues immediately – and the use of operation reviews, company-wide meetings in which the health of the engineering organization and its projects is discussed. These reviews, which I first read about in Agile Management for Software Engineering, provide valuable feedback to non-engineering facilities and are a practice that I’d love to see taken up in my office.

Next up was an Introduction of the classic “iron triangle” of project management, Quality, Time and Features. At Ping they fix time, committing to three month “trains”, or releases. If something is not ready in time due to quality issues, incomplete development, or any other reason, it’s not in – the rest of the completed features go ahead and ship. Lead time is established to be 3 months, with high confidence; in the last 5 years, there have only been 12 days in train delays. With time fixed, there is a tension between quality and features, with quality always winning. This is not to say that they gold plate – there is simply a zero defect release criteria. The concept of the “Iron Triangle” was elaborated into an “Iron Pentagon”, the additional two factors being resources and system.

Bill brought up several metrics that are used at Ping to observe many aspects of their development system. There were graphs of “utilization”, or how many team members were available to work on a project and how many were absent due to vacation, holidays, illness, etc. There was a slew of metrics related to quality, from the count of development-injected bugs to the average amount of time between finding and fixing a bug and the amount of time the test team spends on set up. Like all metrics, these require the gathering of data over time, and one of the metrics mentioned was a measure that I did have the data for, albeit not centralized – the number of various types of automated tests run by one of our products. A few hours of hacking data together, and a few minutes learning some jQuery and flot, and I get the following chart:

From here it’s easy to tell that 2008 was an awful year for unit tests, we greatly prefer unit tests to system tests, and that both have been growing over time. There are several more metrics that were mentioned that I’d like to take a look at, particularly the ones related to defects. I’ll post any graphs I make, and would love to hear stories from others who have sucessfully used interesting metrics to drive change in their development organization.

As an aside, I asked Bill after the talk about techniques used to loosely couple features such that they may be removed near project end without destabilizing others. He said that a variety of techniques were used, ranging from a preventative / planning approach – that is, simply not working of features at the same time that are likely to impact each other, making backout easy – to incorporating functionality “switches” in the product, which can be configured either at compile or run time to use either new or old code. These are techniques that I would love to start applying on my team, if there is ever a need to have strict adherence to a release schedule.

Tonight, Christy Clark was was elected to be the Premier of British Columbia. I use the word elected very intentionally, as I have heard several people complain about the way this new Premier came to power. I had no real preference for any the candidates, but I do disagree with some of the outrage that’s going around.

First, some background. Here in BC, as in all provinces, the Premier is the leader of the party with the most seats in the legislature. We don’t directly elect the Premier in the way that Americans vote for their President. Instead, we vote for a party candidate in our riding, in a first-past-the-post fashion (since we blew our chance a few years ago to move to a Single Transferable Vote system). Flawed as it may be, this is the current state of democracy in the province.

Since Gordon Campbell stepped down as Premier a few months back, an action that does not trigger a general election, it’s been known that the new leader of the province would be the winner of a party leadership vote. In such a vote, only members of the party cast ballots, and they do so in a transferable way. Additionally, people from all across the province get to vote for the leader.

I’ve heard many people talk about how “undemocratic” the whole thing is – after all, the logic goes, there wasn’t a general election, so how can this be democratic? In my opinion, this was actually a more democratic election that most in BC. Anyone in the province is eligible to join the Liberal party, at a nominal cost of $10, and a voter is able to make more of his or her preference known with the inclusion of a second choice candidate. Over 57,000 people voted in this election, from all over the province. Contrast with Gordon Campbell’s election in 2009, where he became the Premier with just over 11,000 votes from people living within a few square kilometers on the west side of Vancouver. Finally, this was a very rare opportunity for people in BC to vote directly and unambiguously for the Premier, instead of for a local candidate who will just end up having to fall in line with the eventual Premier.

For those of you in BC (or paying attention to BC politics), what did you think of the system used to elect Christy Clark?

This past year was probably a turning point for me in terms of getting involved with a larger community on cutting edge issues, specifically the Kanban community. Although my team achieved great successes in the past year, shipping 37 different software releases and maintaining high quality standards, I can’t say that I’ve really seen too many benefits from Kanban thus far. Don’t get me wrong – I still think the method has a large number of merits. It’s really more that I’ve been barely doing Kanban.

The year is a continuum, of course, and I can’t say that I didn’t do anything with respect to Kanban all year. My knowledge about the team and the method improved throughout the year, culminating in a Kanban “relaunch” in the new year. That’s been going well, and my current approach is much more in line with what the method prescribes, but that’s a subject for a different post. Today I’ll reflect on what did and didn’t work in the past year, and why.

First, I’ll cover the highlights. Even the very limp version of Kanban we were doing afforded us some structure to build on and learn from. With a visualized workflow and explicit work in progress limits, the team engaged in conversations around how much parallelization was too much and what the appropriate size of work items was. The beginnings of explicit policies emerged, blocked items were noted and prioritized, and the team successfully delivered on their commitments.

Now for what didn’t work. Explicit policies were few and far between, which led to the rehashing of several topics as well as too much unnecessary management intervention (tie breaking, direction, clarification, etc.). Metrics about lead time, cycle time, and work in progress were not kept – I always thought there would be a better time to start, such as the beginning of the next project, and worried about missing important metrics or recording useless ones. The lack of classes of service also provided some discouragement for data-gathering, as two different tasks in progress could be two orders of magnitude apart in difficulty. Without such data, our Kanban system was being used primarily for task management instead of as a process of evolutionary change. Finally, with a dedicated, embedded customer / product owner on the team, and with an existing culture of openness, there was no cadence at all. Releases, retros, and queue replenishment were all ad hoc, which prevented any rhythm from forming.

Although our work system is still, and will always be, a work in progress, all of the above difficulties have been addressed. I now have a month’s worth of data, spread across 5 classes of service. We have a weekly cadence for queue replenishment and retrospectives; we’re in the middle of a large project, so we no release cadence right now.  Policies are explicit and are up for review during the retrospectives, or during the week if the policy is wrong or dangerous.

My next post will outline how the team’s system works, some problems we’re still trying to address, and what we’ve learned so far.

I always find it pleasantly surprising when I see parallels and analogues between pieces of knowledge I gain from very different sources. After thoroughly enjoying the Dalai Lama’s The Art of Happiness, I decided to pick up another book of his I had on a shelf – How to See Yourself As You Really Are. This is a much denser book, with meditation / reflection exercises after each chapter. It’s probably the deepest I’ve ever gone into Buddhist philosophy, and I won’t admit that I’m understanding it all perfectly, but I’m enjoying it nonetheless.

One of the parts I think I understand is the discussion on the topics of emptiness, inherent existence, and dependent arising.  In particular, the idea that no object, person, or situation exists independently, but instead is dependent on  previous circumstances. I’m not even scratching the surface of what’s discussed in the book, but I found it quite interesting. The same week that I was reading about these topics, I noticed a link from Alan Shalloway on Twitter to the fundamental attribution error. A finding in social psychology from the 1960′s, the fundamental attribution error occurs when people ascribe others’ failures or misfortunes to some sort of individual deficiency but  are quick to blame outside circumstance for any personal failings.

Why mention both of these things? It seems to me that there is a lot of overlap in these two ideas from different approaches, cultures, and times. The basic shared idea, that greater context leads to greater understanding, is a powerful one. The Responsibility Process tells us that recognizing dependent arising when it applies to one’s self is part of a natural progression. The key is to look out for snap judgments that ignore the reality that others can also be victims of circumstance, instead finding fault. While this can be a natural reaction, being aware of your reactions and working to counteract this way of of thinking can help foster empathy and understand situations from other people’s points of view. Such empathy and understanding is a key component of leadership.

This post is going to be one of those relatively few times when I ask people to comment. If you’re an RSS reader, and you care about Kanban, please consider visiting the site and letting me know what you think.

I’ve done a few posts this year entitled This Week in Kanbandev. The stated goal of this series was to get me writing more and get me reading the excellent Kanbandev mailing list. It accomplished both of those things, but I don’t see a future in the series in its current format. I find now that, after killing off my backlog, I’m interested in reading Kanbandev again, but I’m now putting it off because the thought of boiling down an interesting, 80+ comment thread into a few sentences is not a pleasant one. Because of this, I’ve not done a post on the subject in two weeks, and haven’t really missed.

That all said, I really do enjoying reading the list and sharing what I find. However, sharing is a two-sided coin – I’d like what I’m sharing to be somewhat useful to people. My current format is so short that the only benefit I think someone would get out of it is to be pointed to the list. People who are interested in subscribing to the list will do so. People who aren’t interested in reading the whole list probably can’t glean enough useful tidbits from my summaries. People who are already reading the whole list will continue to do so and not bother to visit the site.

So, here’s where the Request For Comments comes in:

• What have you thought of the series so far?
• Do you have any suggestions for Kanban-related topics I could write about?
• Do you have any suggestions for a different format (perhaps a “best of the week” instead of a summary)?
• Do you have any Kanban questions that I could help you with?

Please leave a comment below, and thanks in advance!

I’ve been playing video games, primarily on consoles,  since I was 5 and got the Nintendo Entertainment System for Christmas. I certainly haven’t owned every system, but I haven’t missed a generation since I started (although you could definitely make an argument that, GoldenEye and Mario64 aside, purchasing an Nintendo64 was missing a generation).

Although I’ve enjoyed most types of games, Role Playing Games (RPGs) have always been my favourite. From the very first Dragon Warrior – single person party! – to wonderful modern RPGs like Mass Effect on today’s consoles, I’ve played as many as I can get my hands on. Reading The Grand List of Console Role Playing Game Cliches (warning, TV Tropes time sink link), I can name two or three example games for almost every one. I’ve never counted how many of these games I’ve actually played, but it’s certainly been several dozen – hell, there’s a dozen Final Fantasy games!

Today’s games have great graphics, interesting plot twists, and usually decent voice acting, but I’ve always had a soft spot for 16-bit RPGs. From the first time I saw Final Fantasy II on the Super Nintendo, I was in love, and to this day that’s probably still my favourite game. I played through some decent ones, some great ones, and even some pretty bad ones. However I definitely didn’t play all of the SNES RPGs that existed, as many of them were Japanese-only, never released in North America.

Luckily, the combination of emulators and dedicated translators have made these games available to computer-owning, non-Japanese speaking players such as myself. Conveniently, I have a 1.5 hour commute on the bus every day, so I’ve been able to tear through several of these games in the past few months. As it turns out, I find that emulation is an ideal way to play these games – the presence of a “turbo” button (which runs the emulation as fast as your computer can handle it) makes random battles incredibly fast.

I hope to get around some day to listing the RPGs that I’ve played, and also reviewing some of the lesser known games I’ve found, but for now I’m off to solve some puzzles with Lufia.

My team has recently adjusted some of its process to adapt to changes in our organization, and I thought that this was a good chance to get on a regular retrospective schedule. As a team, we are very good at communicating, and we are constantly reflecting on successes and failures. Because we address most issues in real-time, weekly (then bi-weekly, then monthly, then occasional) retrospectives became relatively quick, limited-value rehashes of the tired old “What Worked / What Didn’t Work / Actions required” formula. If we were going to start doing retrospectives more often, I wanted to make sure that we were getting something out of them.

Chatting with Esther Derby at the recent Agile Vancouver conference, and seeing her present, made me quite interested in her books. There’s been a copy of Agile Retrospectives sitting around the office that I had skimmed a few times over the years, but now that I was intent on improving my team’s retrospectives I sat down and read it cover to cover.  It’s a great book with many sample exercises that have proven effective for a variety of teams, but it’s probably the psychological and sociological theories and general frameworks for group learning that I found the most interesting.

Our first of the “new” retrospectives was on Tuesday of this week, and I think it could be considered a success based on the feedback I’ve received. It was great to see that, despite some relatively major changes in focus for us, the team is generally on the same page with respect to how were are working together. We came up with a few explicit actions, but my primary goal for this retrospective was to get a baseline of the team with respect to their thoughts on the current project, adherence to team values (which we defined), and general team satisfaction.

We’re definitely going to maintain our current practice of doing immediate retrospectives, root cause analysis, and other corrective techniques, as it’s working well for us. I think these new retrospectives will be a chance to look at things at a higher level, measure trends, and ensure that the team is still aligned with the company and with each other.

Despite my best intentions to get started on reading posts early in the week, I was distracted by preparations for the talk I gave to Agile Vancouver on Monday. I still got through the bulk of this week’s posts, so here goes.

• Inspections?

The originator of this thread has a client who introduced inspections at various parts of the process, with the stated purpose of improving quality. His is the only team in his organization that’s using Kanban, or any sort of Agile for that matter, so he’s trying to find a way to convince his client that his  process already has mechanisms in place to prevent defects. Eventually, it was pointed out that this conversation wasn’t directly related to Kanban. After all, since Kanban says nothing explicit about technical practices or defect prevention, saying that you’re using Kanban isn’t sufficient to pacify customer concerns about quality. The good news is that since the last project his team shipped did not use inspections – nor did it have any reported defects – this could be the start of a conversation about trust and metrics-based decision making.

• requesting help on myths of Kanban

Alan Shalloway is preparing a poll about commonly held Kanban myths. I love the idea of clarifying what Kanban is, not so much to maintain any sort of ideological purity, but instead to ensure that anyone trying Kanban benefits from the best practices established by the community. There’s discussion of common myths, some of which can be easily dismissed and some that require a bit more reasoning. I’m interested to see the end result of this work.

Following up on the Incremental Change thread from last week – the conversation did get better. People offered more clarity on their positions, and the tone improved. Several good concepts were discussed, such as the idea of “good practice” (analysis- or evidence-based) versus “best practice” (a community accepted standard / off-the-shelf solution), and the Cynefin framework. I had heard of Cynefin before but never really investigated it – I’m happy to see that creator David Snowden is a confirmed speaker at this year’s Lean Software and Systems Conference, which I hope to attend. All in all, the thread is likely a good reference for anyone struggling with the concept of standards, their proper place in a development / IT organization, and the difficulties that one can encounter when trying to manage shared knowledge.

Finally, it’s worth noting that the Wikipedia page on Kanban has been updated by several people, including myself. It was in a sad state before, but it’s looking much better now. Feel free to contribute if you have something to add!

This was a busy week on the list, but almost all of the content was concentrated in one thread that I didn’t get around to reading until today. Let’s start with the big one.

• Incremental Change – How?

This huge thread is an offshoot of the “BVI was MMF” conversation that I touched on last week. The sub-thread originator raised some legitimate questions about whether the types of change that can be made  are different than, or perhaps even a subset of, the types of change that can occur through Big Change Up Front. The basis of incremental change in Kanban (standardized work that can be continually improved via experimentation) is challenged, going so far as to say that without a skilled coach Kanban is actually more difficult for a team to use successfully than a more comprehensive and prescriptive method such as XP due in part to the lack of standardized work. Of course, this dodges the fact that XP is a software development methodology whereas Kanban isn’t.
There’s some good conversation on this thread, specifically about the utility of standards (are they dangerous? required? a good idea? impossible in software?), but I found that it devolved a bit too much into mincing terms and arguing over definitions. Some of the side conversations were good – such as the discussion of how Lean is more of an evolution of Taylorism than a complete departure –  but I felt that this thread lacked a lot of the useful, experienced-based discussion that I’ve come to love from this group. That said, the conversation is still going, so maybe it will pick up.

• Emotions to motivate change

This thread was a spin-off of the Sense of Urgency post that I discussed last week. It’ s somewhat  on the same subject material, but it delves much deeper into the into the nature of resistance to change from psychological and experiential perspectives.

• using Kanban to improve flow in appointment booking

With only three posts, this was a very short thread, but I thought it was an interesting example of how Kanban (and Lean thinking in general) is applicable to situations outside of software development – in this case,  scheduling appointments for a consultancy firm. The original poster relays some changes that they plan on making by applying queuing theory and allowing slack in their booking system. David Anderson suggested a talk by John Seddon about Lean in a service organization, which I managed to dig up and add to my ever-growing “talks to watch” list.

Links this week – only a few, and I’ve already mentioned John Seddon’s talk above.