Monday, December 13, 2010
Wednesday, October 20, 2010
I've recently been poking around various software projects, tutorials, and blogs, trying to brush up on some recent technology. It's been the usual fare. Pull the latest code and then muster a good 15 to 20 minutes of straight concentration time to get my brain wrapped around what this developer is trying to accomplish.
Well, I had an incredibility refreshing experience today. I contacted a coworker for some advice on technology and technique. He offered example code from his current project. So I cloned the repository and cracked it open.
What a refreshing change. The project structure was clean, organized, and intuitive. Ok, maybe I'm biased because I know this person, I've worked with him for 2+ years, and I know how he thinks. But everything just made sense and it was simple! I opened the build file, and I could read the entire script without scrolling. Imagine that. Oh, and it's not like he was hiding complexity by using the latest and greatest build tool. This is an old-school XML build file, you know, the stuff that gets the snarky laughs at the conferences? Well, it didn't matter because it was simple and understandable. And I'll take old-school any day when it doesn't cause me to run through a mental boot camp just to understand how the damn project is built.
So, to the community of book authors, bloggers, open source developers, thank you for your efforts. If you are interested in advice on how to further expand the reach of your examples and projects:
1. Keep it simple (seems obvious, but very few achieve simplicity).
2. Get off your architectural high horse every so often and take time to smell the flowers.
3. Make your intent as clear as possible.
3. Keep it simple.
Tuesday, July 13, 2010
Thanks to those who attended the panel discussion on Agile methodologies, the other panelists, and Don King for organizing the meeting. I thoroughly enjoyed the discussion.
I referenced a couple of books that I wanted to relay here. Anderson’s book is the best source for understanding Kanban. Poppendieck’s book contains very good information about value streams and funding models (product development).
Monday, June 21, 2010
I failed to mention the local Limited WIP Society chapter (http://groups.google.com/group/limitedwipsocietykc) during my talk. If you are interested in participating in the continuing discussion with other local Lean and Kanban practitioners, then join the mailing list. We try to meet on a monthly basis for a casual lunch or dinner.
Thanks for the interest in Kanban!
Wednesday, June 16, 2010
Interesting in attending? It's free! They will feed you (free again) twice during the day. And there are some great speakers. Register here: http://kcdc.eventbrite.com/
My talk will be a variation of my presentation for the Lean Software and Systems Conference in April. Attend the conference, enjoy the networking opportunity, and ask me some tough questions!
Wednesday, April 7, 2010
Also, if you have any feedback on presentation, please let me know through this blog or by email: troyltuttle [at] gmail
Tuesday, March 16, 2010
My talk will be about Kanban for software development. I really enjoy talking software process with an audience primarily made up of software developers. They usually are the most passionate.
Where: Federal Home Loan Bank Topeka
When: April 6, 2010 at 11:30 am
What: Learn about Kanban!
Food: Yes, lunch is provided, but please register to attend.
Wednesday, February 17, 2010
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.
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.
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 –> ReleasedRepresent the value stream on your board and track every work item (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.
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.
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.
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.
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.
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!
Wednesday, January 20, 2010
Tuesday, January 19, 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: