Business Oriented Development

Guerrilla Kanban

2010-02-17T09:50:00.005-06:00

After speaking to a few local Kanban practitioners (and aspiring practitioners), I thought it would be helpful to demonstrate how you can use Kanban to improve your software development process in small, incremental ways. So much of what we learn about Kanban and Lean software online are implementations in relatively open and conducive work environments. Or at least they are implemented by people with the authority or influence to make the change. We see photos of large, gorgeous Kanban boards and we read about profound accounts of successful Kanban projects.

If you work in a corporate structure that seems too dysfunctional or too rigid to adopt agile processes, you may feel helpless in your current role to affect change. Maybe you work on a small team in a command-and-control environment. Maybe you work as a single developer in your own project silo with more work assigned every week than you have the capacity to complete.

This blog post is to challenge your assumptions about your ability to affect change, and hopefully give you the tools you need introduce positive change in your organization.

Background
Project X is currently in production, but has some significant challenges. It has suffered from the lack of developer availability since it went live. Bugs were discovered in production and often there were no developers available to fix them. This later caused the product owner and users to overload development staff when they were available for support work. The code was originally developed in project silos, with no automated test support. The code base is only 2 years old, but is effectively a legacy code base.

Making Improvements
David Anderson, a leader in the Kanban community, has recently talked about Kanban as a “change management” system. Since Kanban has a low barrier to entry compared to other popular Agile methods, your goal should not be to make grand, sweeping changes in your environment. Allow Kanban to show you and the other stakeholders where you need to make changes.

Mechanics of Kanban
Your immediate goal is to visualize the value stream. This can be on a white board, but any wall with appropriate fasteners will do. The value stream for Project X (bug fixing) is:

Needs Prioritized –> Prioritized –> Dev –> Ready for Test –> User Testing –> User Accepted –> Released

Represent the value stream on your board and track every work item (figure 1).

Figure 1.

Next, start limiting work in progress where possible. At the time of the board photo, there was one developer fixing bugs, so the WIP limit for development is 1 (yellow highlight). Notice the two large batches of bug tickets at either end of the board. We'll explore what that means a bit later in the post.

As soon as you can track work items on a board, keep an electronic copy in a spreadsheet or tool of your choice. The critical piece of data to track is the actual cycle time per work item (figure 2). You will notice this sheet shows "Dev Cycle Time". Since the code base doesn't have automated tests, large numbers of code changes are typically batched up for user acceptance testing and manual regression testing. Given the technical and testing limitations, the project has very little end-to-end flow. So, to help with project planning in the near term, development cycle time becomes more useful. It allows the product owner to plan when a full regression test and subsequent release can occur. In Lean terms, this is not ideal, but in the context of Project X, there is value in measuring a subset of the full cycle time.

Figure 2.

Once your work items are captured, and cycle times are recorded, you will need to capture that data on a regular basis. For most projects, a daily project "position" is adequate. At the end of each day, record the total number of work items in each state (figure 3). Unless you have a very busy Kanban board, this should only take a few minutes each day.

Figure 3.

This historical data can be used to generate a simple Kanban dashboard in excel (figure 4). At a minimum you should include information to answer two basic and related questions: how fast are we going, and when will we be done?

Once again, in the short term, Project X is primarily concerned with calculating cycle and lead time values for the development stage.

Average cycle time is easy: (sum of cycle times / count of cycle times).
Lead time measures the backlog and average cycle time: (backlog count * average cycle time).

For Project X, this simple dashboard is posted beside the Kanban board (figure 1 red highlight) and emailed to stakeholders every week.

Figure 4.

The Goal
We have two immediate goals with our Guerrilla Kanban implementation:

Generate useful metrics to assist with immediate project planning needs.
Provide visibility to make observations and improvements to the process over the short and long term.

For Project X, providing metrics around development effort helped the product owner make more informed decisions about release cycles and project coordination with other systems in the portfolio. Questions about developer estimates diminished quickly, and were ultimately replaced completely by cycle and lead time metrics. A byproduct of this change was a significant increase in trust from the customer.

The Kanban board (figure 1) and cumulative flow diagram (figure 4) both serve as conversation starters with project stakeholders. The only “good” aspect of the cumulative flow is the thin yellow ribbon of development work. The WIP limits for dev work are effectively enforced. The rest of the diagram exposes a large backlog and high counts in the testing states. Work is batched up before and after development work. Even though items are moving through development at a steady pace, there is very little flow of value since bug fixes are only tested and released to production in large, infrequent batches.

To further make the point, we could contrast the average development cycle time (2-3 days) with the average end-to-end cycle time (2 – 3 months). If we desire a healthy software product and project, 3 month cycle times for bug fixes are unacceptable.

One of the top software project killers is lengthy feedback cycles. The conversation around improvements for Project X could center around ways to reduce the feedback cycle between development and testing. A potential solution would be to explore methods of automated testing. The ultimate goal for our testing phases would be an enforceable WIP limit that would ensure flow of value to the customer.

Reflection
You may be wondering why Project X uses such low fidelity tools (white board and spreadsheet). There are very capable digital Kanban boards available. Use whatever works for you! White boards and Excel spreadsheets have a unique advantage, almost everyone has access to both in the workplace.

If you decide to try your own Guerrilla Kanban, realize that your effort is simply to create an environment where stakeholders have the tools to observe and make improvements. As you begin to replace developer estimates with actual metrics, you will begin to build trust. Once you have project visibility through the board and cumulative flow diagrams, you have catalysts for future process improvement conversations.

I hope this inspires you to start your own Guerrilla Kanban!

LWS Kansas City Dinner

2010-01-20T10:30:00.000-06:00

We are having another Limited WIP Society KC meeting on Jan. 20 at 6:00 pm in the Overland Park, KS area. Email me at tuttle.troy at gmail for more details.

Speaking at the Lean Software and Systems Conference 2010

2010-01-19T12:44:00.001-06:00

I was quite pleased to learn my Why Kanban presentation submission was accepted for the Lean Software and Systems Conference 2010!

I am very excited to meet and learn from some of the brightest thinkers in the Lean software development community.

Want to learn more about Lean and Kanban? Check out the speakers and topics at LSS2010:
http://atlanta2010.leanssc.org

Limited WIP Society KC Lunch!

2009-12-11T22:07:00.000-06:00

We are meeting for a casual lunch time discussion of Kanban for software development on Tuesday, Dec. 15. If you are in the KC area and interested in learning more about Kanban, you're welcome to join us.

Send email to tuttle.troy at gmail (dot) com for details.

Kanban 101 Site

2009-12-10T13:21:00.001-06:00

Janice Linden-Reed, an active member in the Kanban community recently announced an introductory Kanban site: Kanban101.com.

Great content with simple to understand definitions.

Kanban Slides Available from 10/28/2009 AgileKC Meeting

2009-10-28T23:34:00.004-05:00

My Kanban presentation slide deck is available for download. Thank you to all who attended. Great questions and discussion afterward.

My slides contain a references page with links to pertinent materials. Here are a few resources we discussed:

Scrum-ban – Corey Ladas explains how to implement some Lean and Kanban principles on your Scrum team.
Implementing Lean Software Development: From Concept to Cash - Poppendieck (published before Kanban for Software was coined, but very good resource for Lean organizations)
Limited WIP Society – the best Kanban resource available on the web (resources page)

What Others Are Saying About Software - 10/26/2009

2009-10-26T12:54:00.000-05:00

Self-Organization vs. Evolution
Another take on complex systems and team software from Jurgen: "These teams are non-deterministic and therefore able to heal themselves, while an automated or controlled system is deterministic, and therefore not self-healing."

Kanban Results
A Kanban report card from David Joyce at BBC in London. Inspirational!

Kanban Presentation, AgileKC Meeting 10/28/2009

2009-10-20T22:49:00.000-05:00

I will be giving my “Why Kanban” talk to the local Agile KC user group. Meetings start at 6:30 pm at the Pizza Shoppe at 5285 W. 95th St, Overland Park, KS.

More information can be found at the AgileKC group site.

I am honored and excited to speak to the local Agile organization. Hope to see you there!

Why Kanban? Presentation Slides Available

2009-09-23T22:27:00.000-05:00

I would again like to thank everyone who attended my presentation, "Why Kanban?" at the Kansas City .NET User Group meeting on Sept. 22.

My presentation slide deck is available for download.

More Kanban-related content to come soon!

Speaking on Kanban, KC .NET User Group, Sept. 22

2009-09-14T23:14:00.002-05:00

I will be speaking to the KC .Net User Group about Kanban for software development on Sept. 22 at 6:00 pm. Meetings are held at Centriq Training, 8700 State Line Rd, Leawood, KS. Watch the user group site for updated information or subscribe to their google groups mailing list. Hope to see you there!

Interested in participating further in Lean / Kanban discussions? Join the new Limited WIP Society KC mailing list.

Announcing Limited WIP Society KC

2009-09-14T22:38:00.001-05:00

I am pleased to announce the establishment of the Limited WIP Society KC group. I encourage you to join the mailing list if you are interested in Lean/Kanban and if you live in the Kansas City Metro area (or within driving distance).

The group will be loosely associated with the parent site, Limited WIP Society, the best collection of Kanban material on the web.

As stated on the Google Groups page, the goals for the group are:

Sign up software professionals and start an online discussion once critical mass has been achieved.
Decide as a group if and how the group would like to "meet-up" for social and professional events. This could be similar to the KC Agile group who meets once per month for a presentation and dinner. Or it could be a type of open-spaces event where every participant is able to contribute to the topics being discussed.
Provide a support structure for software professionals to exchange ideas about Lean software approaches (Kanban).

I hope to see you on the group!

What Others Are Saying About Software - 7/30/2009

2009-07-30T10:17:00.006-05:00

Commit to Sprint Planning or Definition of Done, Not Both
Jurgen Appelo provides great blog content in a succinct package. He opens another dimension in the Agile planning game space, and once again tells us things are not always as simple as many think. To do software well, it still requires a good amount of thinking for yourself.

Lean and Kanban 2009 Video Archive
The best software development content on the web right now. If you want to get a taste of how software will be built in the near future, lend an ear.

What Others Are Saying About Software - 5/27/2009

2009-05-27T07:28:00.002-05:00

Comparing Kanban to Scrum
David Anderson weighs in on the Kanban vs. Scrum discussion.

UppercuT - The Insanely Easy to Use Automated Build Framework
Rob has posted a series on UppercuT, an automated Build Framework for .NET projects. I tried it and had a build running in 2 minutes!

Making Agile Sausage and the 40% Rule

2009-05-14T00:35:00.007-05:00

I recently stumbled across an article about Agile standup meetings told through references to the Chicken and the Pig project fable. The article is a conversation re-cap from the Yahoo Scrum Development group. The theme is chicken participation in standup meetings--how many chickens are too many?

Note: Throughout this blog post I will make references to chickens and pigs. My only meaning in this context is through the project fable mentioned above. I do not intend to convey any additional connotations associated with chickens or pigs. They are simply representations of the different roles in and around a software project.

My answer is 40%. When the number of chickens approaches and exceeds 40% of the total number of attendees in the standup, strange things begin to occur.

On a previous software project, my team’s standup meetings started taking on a presentation-like quality. Team member updates became terse. Real impediments were occasionally muted or missed completely. In general, the standup meetings became less about team collaboration and communication and more about project status updates. So, for a week, I counted and figured the percentage. 40% of the attendees were chickens.

It is not hard to imagine why the intent of a meeting can change over time in such an environment. On this particular project, the team members were actually asked to stand in front of the board and physically point to the story or task on which they were reporting. This was done so attendees could tell which index cards were currently being discussed. So not only was the standup meeting degrading to a forum for status updates, it also was being choreographed!

I understand the pragmatic-minded readers are probably questioning my 40% rule by now. Is there really something significant about 40%? No. It just makes better blog entry titles. My point is that standup meetings are similar to tools in a mechanic’s toolbox. The best tools are the ones that have a specific and narrow purpose. The all-in-one screwdrivers are usually flawed in some major way. They try to do too much, so they do not perform any one function particularly well. In my experience, standup meetings are similar. They do not serve multiple purposes very well.

So how do we know when our standup meetings are not serving their original purpose? Some simple observations will probably suffice. Here is my list:

Team members sound like they are reporting rather than sharing.
A significant number of team members are visibly nervous before their update.
The team starts to dread the daily standup meeting, whether stated or observed.
The standup meeting is directed (choreographed) by someone.
The project manager has stopped sending regular status reports to management and instead invites them to attend the standup meeting so they can get updates directly from the team members.

Is the answer to the standup problem to un-invite chickens? That does not seem to be a good long term solution. Agile projects are supposed to be transparent. I think it is important for management to feel they are welcome to observe the software development process first hand. Agile teams need to be transparent and open to be successful. But openness requires a level of trust; and trust only grows when parties observe common boundaries.

My advice for managers and product owners: If someone invites you to watch sausage being made, don’t complain that it is gross. Up close, software development can be messy and a bit erratic. If you value transparency, then find a way to build trust with the team. If you need a status update, talk to your project manager.

How and Why I (almost) Missed the Agile Boat

2009-04-27T01:56:00.001-05:00

My colleague and co-worker Lee wrote a bare-soul post recently about missing the boat as a developer, and it prompted me to do my own version about Agile development. Lee impressed me with his candor about his experience in software development. He laid his "code" soul bare for everyone to examine. That takes guts and thus the inspiration for this post.

I had a similar experience with Agile software development, albeit was a bit shorter time frame. Like many developers, I was well into my professional software development career before I was exposed to Agile. But even after I was exposed to Agile, I kept it at arms-length for some time, not really sure what to make of the new approach.

My introduction to Agile came at an organization that was in the process of converting from a rigid waterfall/phase-based methodology to Agile. We were learning as a group with the help of a few Agile consulting firms. Our organization had a few green, inexperienced, Agile advocates to provide a start. But for better or worse, we had to mostly stumble our way through the Agile learning curve.

I am a natural skeptic. I probably get that trait from my father who is the skeptic of skeptics. So when faced with these new ideas from the burgeoning Agile community, my natural skepticism kicked in. Abandon big up-front design in favor of emergent and incremental design? Crazy! Software requirements on a note card? Nuts! Writing unit tests before the code? Heresy!

As my organization explored Agile principles and practices, I thought about all the software engineering conventional wisdom that I relied on so heavily in the past. And everything about this new Agile approach just seemed so counter to my professional understanding. But as we experienced Agile development first-hand, it became clear that this movement had substance.

Soon we considered ourselves an Agile shop. It seemed that everything should be perfect. We left our dysfunctional waterfall days behind. We had the support of IT and senior management. We were doing Agile!

But through that experience, it felt like we still were battling a form of Agile low self-esteem. We seemed to continually question if we were doing it right. Were we Agile enough? Oh, there were plenty of helpers along the way. For any organization with a few thousand dollars to spend, there was an endless supply of Agile consultants willing to tell us that being Agile means doing “x.” Or to measure your Agile-ness, you could take an assessment to determine exactly how Agile you really are.

Eventually, I made an important observation about what it meant to be Agile. I found that Agile was just a means to the end, and not the end itself. It is futile to try to pump up your Agile self-esteem by convincing yourself and your team that you are indeed “Agile.” That you have arrived somehow in Agile land. Agile is not a state. Agile is not an end. Agile is just a vehicle, just a means to a goal.

I found my boat. Have you found yours?

Jumping The Agile Shark

2009-03-29T23:39:00.004-05:00

I stumbled across an interesting post, Why “No Issues” Is Not An Acceptable Answer where Derick Bailey describes an "anti-pattern" in Agile team standup meetings. He observes it is a bad indicator for Agile teams when team standup meetings repeatedly result in every team member declaring "no issues." I agree that this condition is common, and less than desirable. But I disagree with Derick's proposed remedies.

Don't Be a Bean Counter in a Creative Process

The readers of this blog don't need to be reminded that software development is a unique, creative undertaking. Developers have to be writers, analysts, problem solvers, and engineers every day. Sometimes they have to be all these things in the span of an hour. That kind of journey is always going to have unexpected issues.

One aspect of Derick's recommendations is to document issues as small as 10 minutes and raise them in the daily standup meeting. I can't think of something that would render a standup more impotent. Everyone who has worked in an Agile environment has experienced the occasional marathon standup meeting. There are well known remedies for these lengthy meetings, but they all boil down to one thing: too much information! Just like you don't need to know the details of your co-worker's skin rash, you also don't need to know that Bob found a solution to his 10 minute unit testing problem. You do need to know that Bob encountered a serious bug in the ORM two days before a major release. If that type of issue is not raised during standup, then you really do have a team problem.

Sometimes in our zeal to improve a process, we pinch pennies. We think that we can squeeze another 2 hours of work out of the average developer per week if we can just get them to raise their daily 10, 20, 30 minute issues during standup meetings. In reality, we would just give that time back when we turn our attention from building software to counting beans. If you really believe you can improve software development productivity by tracking 10 minute issues, you need a different profession. This is software development, not a German train station.

Lightweight Methodologies Are Frameworks, Not Therapists

Derick also recommends, as a rule, requiring every team member to raise at least one issue during standup meetings. Do you know what that outcome will be? Every team member will report one issue during the standup meeting! So where does that get us? Well now our standup meetings are oriented toward following a prescription instead of a tool to raise awareness of real problems. We have just shifted the focus of a standup from raising awareness to process compliance.

If we have a team that is not raising issues properly, then we should not look to our methodology (Agile) to provide the solution. Methodology is a framework. It provides us the tools to do team software development. Dysfunctional teams need help with their specific dysfunction. And sometimes, we perceive a team dysfunction when there really is a team asset.

On a previous Agile project, we found ourselves in one retrospective playing a variation of the popular board game, Apples to Apples. But instead of the game's topics, we were using continuous improvement topics that we generated from our last iteration. The idea to play the game came from an Agile coach who had read about the idea in an Agile self-help book.

Our team was doing relatively well on the project. We had our troubles like any other real-world software team, but we were delivering software at a regular clip. So why were we playing a board game during our retrospective? It was perceived from the outside, that our recent retrospectives were not generating a satisfactory number of issues to discuss. We were not meeting our retrospective quota, so to speak. The board game exercise was designed to elicit more issues since it was supposed to be "fun." The result? We definitely registered more issues for that specific retrospective. Did the game help the team recognize and resolve more real issues? No.

Through the normal course of the project, the team matured and developed good working relationships. As any well-functioning and competent team, we increasingly were attacking and resolving issues as they presented themselves instead of waiting for the next scheduled retrospective. Naturally, each successive retrospective generated fewer issues. This should have been judged exactly what it was, a side effect of a maturing software team. Instead it was considered a dysfunction in need of remedy.

For me, this episode was our jumping the shark methodology moment. We forgot that a methodology like Agile is only a framework. Agile is just a tool, it is not meant to perform therapy on a team.

If you find your standup meetings are not producing value for your team, I would suggest digging a little deeper into the team dynamics. Tweaking your methodology is not the answer. I would leave standup meetings to their original purpose:

1. What did I do yesterday?
2. What will I do today?
3. What is stopping me?

What Others Are Saying About Software - 3/16/2009

2009-03-16T12:54:00.008-05:00

Sorry for another "links" post. I'm planning on writing some real blog material soon. Enjoy...

How and Why I Missed The Boat As A Developer
Clear view into the soul of an honest software developer. Enjoy, because these are hard to come by.

You don’t need story-points either
This is crazy, crazy, crazy talk in the world of Agile project management. But there are increasing numbers of people saying these things. Interesting!
Caution: Proceed with an open mind.

What Others Are Saying About Software - 2/26/2009

2009-02-26T12:40:00.006-06:00

NashvilleProject
Martin Fowler's description of a 10 year old code base with 100K lines of code. He maintains the code is flexible and is still used for active feature development. I don't believe him, it can't be true. Nothing written 10 years ago could be in good shape. Impossible.

How Hard Could It Be?: Start-up Static
Joel took some hits over the Uncle-Bob-SOLID-gate issue. So here is a little love for the blogger from NYC. The short of it? Don't get demoralized. Good advice in this market.

What Others Are Saying About Software - 2/16/2009

2009-02-16T20:06:00.000-06:00

From a data centric to a domain driven design
Nice post with a decent explanation of a way to get started with Domain Driven Design. Very few people do a good job of explaining how it is different than the prevailing data-centric approach.

Ron Jeffries and Engineering for Adults
Great post with better comments about the big 'A' Agile crowd versus the small 'a' agile thinkers. I smell a future agile post brewing at BOD.

FlaccidScrum
Flowler once again shows why the rational mind usually prevails. The post deals with the same "SCRUM is failing" topic in vogue recently, but offers some real value compared to Jeffries comments. Fowler states:

Many people are looking to Lean as the Next Big Agile Thing. But the more popular lean becomes the more it will run into the same kind of issues as Scrum is facing now. That doesn't make Lean (or Scrum) worthless, it just reminds us Individuals and Interactions are more valuable than Processes and Tools.

What Others Are Saying About Software - 1/28/2009

2009-01-28T21:54:00.004-06:00

BizSpark - Free Software and Production Licenses for Startups in the Startup Phase
A nice option for service or product oriented start-up companies. And it is a smart move by Microsoft. A profitable company using your software is always preferred to the bankrupt company who cannot afford your software.

Programming By Numbers
Great article about the architect and developer roles in software organizations. I think a good rule of thumb is, All architects should code, and all developers should architect. And I don't mean spending 5% of your time as a meaningful cross discipline effort. John Lennon tried to imagine a different world than our own. I would like to imagine a future where there are no developers or architects, just expert software producers.

File Transfer Manager in VMWare = poof

2009-01-21T23:40:00.005-06:00

Ok, admittedly, this is an unusual configuration. But in the event you find yourself needing to download ISO images from MSDN in a Windows 2003 OS running in a VMWare virtual machine, beware.

The File Transfer Manager performs a brief file validation at the end of each download. On my virtual Windows 2003 machine, this validation step maxed the CPU and RAM. Within about 5 seconds, my virtual machine locked up and my host machine blue screened--forcing a reboot of the host machine.

That's a serious memory leak.

What Others Are Saying About Software - 1/13/2009

2009-01-13T07:10:00.004-06:00

Give and Take in the Software Industry
"Four-walls and a door might be too much to ask, but at least organise the open spaces in ways such that the shouty/squealy-teams are separated from the thinky-teams."

Introducing HNibernate Auto Mapping
James Gregory has published a series of blog posts on the new NHibernate auto mapping features. Basically, you can wire up your domain to your persistence medium without the use of configuration. Additional posts:

Auto Mapping Conventions

Auto Mapping Type Conventions

Auto Mapping Entity Conventions

What Others Are Saying About Software - 12/19/2008

2008-12-19T12:09:00.008-06:00

Making Agile Stick
Another great post from the Dark Side. It boils down to value and working software. David makes the case that it is not an IT 'thing', it is a business 'thing'. And from a business-oriented developer, Bravo.

Estimation Is Not For Accountability (It’s For Visibility)
Max takes a strong stand for real reason for estimates. Interesting read for sure, but I wonder how Max squares his view with those who do Agile training? You hear the word "commitment" a lot from Agile consultants when referring to an iteration. Maybe it's a way to get their foot in the funding procurement door to pay their own consultant fees?

Hardware is Cheap, Programmers are Expensive
Nothing earth-shattering from Mr. Coding Horror. But I like to keep track of these posts, if only for my own benefit when debating my pre-optimization brethren.

KC Day of .NET Presentation

2008-12-06T13:16:00.015-06:00

I gave a presentation at the KC Day of .NET today. If you attended my session, thank you!

Here is the slide deck and demo source code. It's located on Live Skydrive. You don't need to login to download, just select the file, and you should see a download link on the upper left.

I added NCover to the build file (we didn't have time during the presentation). So check out the html report in the artifacts directory.

If you don't mind, please leave me feedback on my presentation by commenting on this post.

Download Materials

I will be blogging on this topic and more in the near future. If you don't use a blog reader, I offer email notifications. Look right. --->

What Others Are Saying About Software - 12/3/2008

2008-12-03T11:09:00.009-06:00

3 differences between 'Small Business' and 'Enterprise'
Someone is obviously battling some serious corporate bureaucracy and his frustration shows. But he does make some interesting observations.

The Wisdom Of Insecurity
Wisdom is sometimes the result of not knowing and the humility needed to learn from it.

How Hard Could It Be?: My Style of Servant Leadership
A few managers get it. Management is not the art of managing, it's the art of getting the hell out of the way.