tag:blogger.com,1999:blog-66711868842417070652024-02-07T00:06:22.518-06:00Lean-Kanban LearningPragmatic Agilist, Kanban practitioner, and Systems Thinker.Unknownnoreply@blogger.comBlogger44125tag:blogger.com,1999:blog-6671186884241707065.post-7843818051595645732012-10-03T10:49:00.001-05:002012-10-03T13:55:11.206-05:00Is Kanban Agile? (Does it really matter?)Steve Denning, a contributor to Forbes, published an article, <a href="http://www.forbes.com/sites/stevedenning/2012/09/25/what-exactly-is-agile-is-kanban-agile/" target="_blank">Is Kanban Agile?</a> last week that stirred some debate in the Agile and Kanban communities. The article is a brief recounting of Michael Sahota's new ebook, <a href="http://www.infoq.com/minibooks/agile-adoption-transformation" target="_blank">An Agile Adoption and Transformation Survival Guide</a>. The book is quite informative and interesting. The theme of Sahota's book essentially is: <br />
<blockquote class="tr_bq">
<i>Agile is not a family of processes or a product, rather it's a specific cultural mindset. And to effectively introduce Agile, you must understand the culture of the organization you are attempting to change.</i></blockquote>
<div>
I agree with the general thrust of the book, but would like to offer a few counterpoints to several sub-themes.</div>
<div>
<br /></div>
<div>
<b>Kanban and Culture</b></div>
<div>
Sahota uses the Schneider Culture Model as the basis for qualifying various Agile approaches. (<a href="http://agilitrix.com/2011/03/how-to-make-your-culture-work/" target="_blank">See explanation by Sahota</a>). I think this can be useful, but where I differ with Sahota is how he arrives at his conclusions. To understand where Agile fits in the model, the Agile Manifesto is analyzed as well as a culture survey of agile practitioners. Agile is then qualified as mostly collaboration and cultivation. </div>
<div>
<br />
Sahota's analysis qualifies Kanban as mostly compatible with Control culture. He doesn't arrive at this by surveying knowledgeable and experienced Kanban practitioners, but rather just on his interpretation of <a href="http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method/" target="_blank">Anderson's Kanban Principles</a>. This is a disappointing omission. I understand why that data is not included, as no such survey probably exists. But nevertheless, it undercuts the weight of the analysis. For Agile, Sahota presents the sentiments of a broad number of Agile advocates. For Kanban, Sahota presents his own understanding of Anderson's high level principles. I was glad to see an appendix of alternate views included at the end of the book. A survey of Kanban advocates would likely reflect something similar.</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div>
Beyond my concerns with the analysis, it is worth exploring this qualification model further. Simply saying a principle belongs to one cultural quadrant or another (or somewhere in between) is lacking. </div>
<div>
<br /></div>
<div>
Take "Limit WIP" for example. At first glance, it appears to be focused on the system--something Sahota attributes to the company-oriented side of the model. But when I observe this in action, it is apparent to me that limiting WIP is a <i>challenge</i> to a company-oriented mindset. Limiting WIP is one of the best ways to help people reduce their dependence on the tools of anti-collaboration: functional specification documents, architectural diagrams, and meetings. Systems with extreme levels of WIP need ways to persist all that knowledge for long periods of time. And when when almost all available working time is devoted to knowledge persisting, there is no oxygen left for collaboration. One could think of limiting WIP as a mini "Green" initiative right in the middle of a software group. It helps protect the delicate ecosystem that allows people-oriented cultures to grow and flourish.</div>
<div>
<br /></div>
<div>
Try this for yourself. At the outset of an engagement with a company-oriented culture, ask the people who depend on traditional project schedules what they think of limited WIP and its first offspring, <i>a Pull system</i>. Do you suppose they think it's a cultural fit?</div>
<div>
<br /></div>
<div>
Another example, at the practice level, is how standups are conducted in Kanban compared to Agile's flagship approach Scrum. In Scrum, the meeting iterates over team members, who are asked: What did you do yesterday, what do you plan to do today, and what are your impediments. On the surface it sounds very people-oriented doesn't it? </div>
<div>
<br /></div>
<div>
In Kanban, the meeting iterates over work items, not people. Work items with impediments are noted. People are implicitly trusted to be doing the work; they don't have to be asked everyday. Even though the Kanban approach is about the work or the system, the resulting cultural and social attitude is much more people-oriented than the approach that is supposed to be people-oriented (Agile manifested through Scrum).<br />
<br />
These are just two examples. My former colleague Phil Ledgerwood, <a href="http://thecuttingledge.com/?p=409" target="_blank">blogged about the effects of visualizing the workflow</a>.</div>
<div>
<br /></div>
<div>
The difference I'm trying to illustrate is the observable outcomes when principles and ideas are put into action through specific methods. A static analysis of principles in a vacuum is inadequate. So to use the Schneider model further, the Kanban mindset recognizes a <i>cultural pressure</i> present in company-oriented cultures. The dominant aspects of this cultural pressure is usually harmful to the people side of the Schneider model (collaboration and cultivation) in knowledge work organizations. To help alleviate this, Kanban practices redirect this pressure to the system, and away from the people. So when an organization with a company oriented culture says they want to improve their software projects, Kanban and limited WIP challenges the project schedule pressure. That cultural pressure is redirected to the system instead, allowing people to cultivate a more people-oriented culture.</div>
<div>
<br /></div>
<div>
I agree with Sahota that Kanban is an appealing approach when faced with a control or company-oriented culture. But it is not because Kanban is accommodating to those cultures, it is because Kanban takes an evolutionary and incremental approach to challenging those cultures. </div>
<div>
<br /></div>
<div>
<b>Cargo Cult Agile Mindset</b></div>
<div>
My second counterpoint is not a direct critique of the book, but rather a commentary on a prevailing and persistent theme in the Agile community. The book just got my anti cargo cult juices flowing. </div>
<div>
<br /></div>
<div>
Over the last few years, many Agile leaders have <a href="http://jamesshore.com/Blog/Cargo-Cult-Agile.html" target="_blank">warned against a Cargo Cult Agile</a> approach that only mimics Agile practices and processes without understanding the real value is in the cultural mindset. I support this understanding and the distinction is a valuable lesson for people new to Agile. </div>
<div>
<br /></div>
<div>
<i>Full disclosure: I am completely supportive of the Agile way, being Agile, and not just doing Agile, etc. I find great value in aspects of XP, Scrum, and Kanban and use them in my work. I also see much value in the Lean mindset. </i><br />
<br />
However, I see a similar pattern emerging with the community's focus on the Agile mindset. We write about Agile failure rates, Agile adoption vs. transformation, etc. And I am concerned for those learning about Agile, that they will see the Agile mindset as the <i>destination</i>, not a means to improvement. <br />
<br />
Let's step out to a second learning loop for a moment and take a look at our language. We lament our failed Agile transformation initiatives not because of the continued poor organizational performance, but because we failed to instill the Agile mindset and all the cultural trappings. We differentiate between an Agile adoption and an Agile transformation, as if the Agile mindset is the end goal. We make statements like "Culture is the #1 challenge to Agile Adoption." Instead, why don't we state that culture is the #1 challenge to organizational improvement? Is Kanban Agile? Does it really matter if it helps organizations improve? </div>
<div>
<br />
When we describe our efforts in terms of organization improvement, it challenges us to think about where we really want to go as an organization. If I may channel Denning here, we would have choices between <a href="http://www.forbes.com/sites/stevedenning/2011/11/28/maximizing-shareholder-value-the-dumbest-idea-in-the-world/" target="_blank">maximizing shareholder value and delighting customers</a>.<br />
<br />
One of my fears is the development of a Cargo Cult Agile Mindset in our community. Even though it's the state of the art now, there is no guarantee it will always be that way. Imagine for a moment what the state of our community might be in the future (distant, or not so distant). I can image a team of software professionals registering impediments during a collaborative exercise, and one of those impediments could be the Agile mindset itself. "If we could only get senior management to let go of their insistence on that legacy Agile mindset, we could really make some improvements."<br />
<br />
The Agile mindset as an impediment... Sounds crazy doesn't it?<br />
<br /></div>
Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-6671186884241707065.post-32445552636335707432011-10-20T21:26:00.000-05:002012-01-14T10:49:53.019-06:00Kidz Kanban–Classes of Service<br />
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif; font-size: small;">In my first <a href="http://blog.troytuttle.com/2011/10/kidz-kanban.html"><span style="color: #336699;">Kidz Kanban post</span></a>, I described how my 6 year old daughter and I established a Kanban board to visualize her weekend chore work. Together, we learned 2 important things:</span></div>
<ol style="color: #262626; list-style-type: decimal;">
<li style="color: #323333; font: 15.0px Arial; margin: 0.0px 0.0px 3.0px 0.0px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif; font-size: small;">Visualizing your work can be powerful. It reduces ambiguity in our human interactions.</span></li>
<li style="color: #323333; font: 15.0px Arial; margin: 0.0px 0.0px 3.0px 0.0px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif; font-size: small;">Using the language of your stakeholders provides better engagement and shared understanding.</span></li>
</ol>
<div>
<span class="Apple-style-span" style="color: #323333; font-family: Arial, Helvetica, sans-serif;"></span><br />
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="color: #323333; font-family: Arial, Helvetica, sans-serif;">The next weekend, we were working the items on the board, when my daughter makes a surprise announcement to the prioritized list of tasks.</span></div>
<span class="Apple-style-span" style="color: #323333; font-family: Times, 'Times New Roman', serif;">
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<i>“Dad I moved the “Clean basement” sticky to the top of the list so I can do it first. Is that ok…?”</i> </div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Me: Why do we need to do that first?</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<i>“Because Grandma is coming today and she is staying overnight.”</i></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
(Full disclosure, I don’t make a habit of stowing my mother-in-law in the basement when she visits. We have a comfortably finished basement where we house a guest bedroom and bathroom.)</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-height: 17px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
My 6 year old made a quick observation when surveying her initial task list. She didn’t know definitively if the current priority would be a problem. But she intuitively knew we were at risk of not having the guest space in the basement ready for grandma's visit.</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-height: 17px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
So I asked my daughter if she thought we should show that work differently. I suggested we use an alternate color sticky note--in this case green.<br />
<br /></div>
<a href="http://lh5.ggpht.com/-9C4kjOsDAf0/Tqjf2seajOI/AAAAAAAAEb8/I-XCSCB_SnI/s1600-h/KidzKanban_class%25255B6%25255D.jpg"><img alt="KidzKanban_class" border="0" height="334" src="http://lh4.ggpht.com/-Uras6UzWYFg/Tqjf3F0HsaI/AAAAAAAAEcE/tJ_JgwekbxI/KidzKanban_class_thumb%25255B3%25255D.jpg?imgmax=800" style="background-image: none; border-bottom: 0px; border-left: 0px; border-right: 0px; border-top: 0px; display: inline; padding-left: 0px; padding-right: 0px; padding-top: 0px;" title="KidzKanban_class" width="578" /></a><br /><br />
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
My daughter decided to complete the green sticky notes first, and finish the remaining yellow notes last.</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-height: 17px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
The more astute readers, (maybe everyone) of this blog will note that we haven't done much here other than an overly elaborate prioritization scheme. Couldn't we accomplish the same effect by just re-ordering our sticky notes in the "Daddy Says" column without changing colors? We could do that, but it doesn't really tell the whole story.</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-height: 17px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
My daughter and I continued our conversation about the green ticket. I asked if the basement cleaning needed to occur immediately.<br />
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Me: When will Grandma really need to use the basement?</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<i><br /></i><br />
<i>"Well, not until she needs to go to bed tonight"</i> </div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br />
Me: Could we wait until just before she goes to bed before we clean?</div>
</span><span class="Apple-style-span" style="color: #323333; font-family: Arial; font-size: 15px;"><div>
<span class="Apple-style-span" style="color: #323333; font-family: Arial; font-size: 15px;"><br /></span></div>
<i>"Yeah, we could...... but I still want to clean it right now."</i></span></div>
<div>
<span class="Apple-style-span" style="color: #323333; font-family: Arial;"><span class="Apple-style-span" style="font-size: 15px;"><i><br /></i></span></span><span class="Apple-style-span" style="color: #323333; font-family: Times, 'Times New Roman', serif;">
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
This exchange demonstrated that our green sticky note usage could mean more than just a simple change in priority. Even though my daughter decided to work the green notes first, <span style="color: #991200;"><b>she had the option to defer that commitment until later</b></span>. This is a subtle, but very important distinction from a simple priority list. By ignoring the priority approach, we open up new possibilities. My daughter could choose to "check for ripe tomatoes" or "clean her bedroom" and tap new possibilities (value). For example, we could have fresh tomatoes in time for lunch with Grandma while we defer the basement cleaning until the afternoon.</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-height: 17px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Software teams that practice Kanban often use a similar approach called Classes of Service. <a href="http://www.dennisstevens.com/2010/06/14/kanban-what-are-classes-of-service-and-why-should-you-care/"><span style="color: #336699;">A good blog post is found here</span></a>. I first learned about Classes of Service from the original Kanbaner, David Anderson, and he describes his approach in his book, <a href="http://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402/ref=sr_1_1?ie=UTF8&qid=1320289392&sr=8-1"><span style="color: #336699;">Kanban: Successful Evolutionary Change for Your Technology Business</span></a>. </div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-height: 17px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
This example would be considered a Fixed Delivery Date Class of Service. Typically, a due date would be visible on the card. In my daughter's example, she would need a Fixed Delivery Time on her sticky note. And since we are visualizing our fixed delivery date stickies on the same board as our standard class of service, we can make instant judgments about which items to work at various points in time.</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-height: 17px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
My daughter ultimately decided against deferring the fixed date work item. That's ok. I have some work to do with her, but hey, she's only in the 1st grade. What's interesting though is how a 1st grader can show more agility than a highly-paid team of professional grade software folks--even the "Agile" ones.</div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; min-height: 17px;">
<br /></div>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Our simple weekend task board has one big advantage over many corporate software team task boards. We don't batch our work in an arbitrary fashion. How many software professionals have to tell customers "no" or provide few alternative work paths because:</div>
<ul style="list-style-type: disc;">
<li style="color: #323333; font: 15.0px Arial; margin: 0.0px 0.0px 3.0px 0.0px;">"We have to stick with our project plan so we can show we are successfully executing."</li>
<li style="color: #323333; font: 15.0px Arial; margin: 0.0px 0.0px 3.0px 0.0px;">"We can't break our iteration for this, it will mess up our velocity metric."</li>
<li style="color: #323333; font: 15.0px Arial; margin: 0.0px 0.0px 3.0px 0.0px;">"We committed to delivering this batch of stories by next Thursday."</li>
</ul>
<div style="color: #323333; font: normal normal normal 15px/normal Arial; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
I know I've experienced this in the past. If your struggling with something similar to this, you may want to consider offering Classes of Service to your customer for more nuanced team decision making.</div>
</span></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-44545039449275154062011-10-08T08:51:00.000-05:002012-01-21T15:50:23.943-06:00Kidz KanbanI have a 6 year old daughter, who has been helping with household chores for quite some time. But recently we decided to visualize our Saturday morning chore work. So I ordered a decent quality whiteboard and mounted it to a kitchen closet door—in plain view of anyone using our kitchen and laundry room areas. <br />
<a href="http://lh6.ggpht.com/-PcskIQgaBXQ/TpUevF-YzLI/AAAAAAAAEbg/onWcAAf8vS4/s1600-h/PersonalKanban%25255B14%25255D.jpg"><img alt="PersonalKanban" border="0" height="308" src="http://lh3.ggpht.com/-nWvqgiOFfrE/TpUevV7wwvI/AAAAAAAAEbk/tyiOgdYEK3E/PersonalKanban_thumb%25255B8%25255D.jpg?imgmax=800" style="background-image: none; border-bottom-width: 0px; border-left-width: 0px; border-right-width: 0px; border-top-width: 0px; display: block; float: none; margin-left: auto; margin-right: auto; padding-left: 0px; padding-right: 0px; padding-top: 0px;" title="PersonalKanban" width="532" /></a><br />
<br />
We started by creating 3 columns:<br />
<strong><br />Todo –> Doing –> Done</strong><br />
<br />
This seemed to work ok. My daughter is bright, and a good reader for her age. She understood the workflow states, so we worked our Todo list the first Saturday. <br />
<br />
Afterward, I asked her how she thought it went. She thought it was alright, except she didn’t know what a “Todo” list meant. She understood the purpose of the prioritized work items. But she didn’t understand the language “Todo”. So I asked her what she thought the column title should be. <br />
<blockquote>
<em>“Well this is the stuff that Daddy says I need to do.”</em></blockquote>
So we changed the column heading to reflect that suggestion. I asked her about the “Doing” state, and she offered:<br />
<blockquote>
<em>“That’s what <strong>I’m</strong> doing.”</em></blockquote>
I updated the board again to the new language. And immediately asked about the “Done” column. <br />
<blockquote>
<em>“That’s when we do a high five!”</em></blockquote>
Our new column headers (red arrow) now read: <br />
<br />
<strong>Daddy Says –> I’m Doing –> High Five </strong><br />
<strong><br /></strong><br />
Readers who are software professionals may be wondering what a children’s personal Kanban board has to do with software development. I think there is a lesson here that I’ve learned long before establishing a board for my daughter. <em>When modeling any process, use the language of your stakeholders. </em>It’s likely to establish a better shared understanding, and people will naturally be more engaged. I’ve made the mistake in the past of using contrived Kanban board column names on a software project. It’s something I now watch for when setting up any kind of Kanban board. <br />
<br />
If you are wondering about the smiley faces on the top bar (yellow arrow), that represents our Visual Management tool for both our girls' behavior. Smiley faces on Monday – Friday earn a trip for breakfast out on the weekend. Visualizing the “score” reduces confusion and arguments around the current state of the household behavior. Have you ever argued about the state of some chunk of software at your work place? Visualize it!<br />
<br />
See part two of this series: <a href="http://blog.troytuttle.com/2011/11/kidz-kanbanclasses-of-service.html">Kidz Kanban: Classeses of Service</a>.<br />
<br />
<br />
<br />Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-6671186884241707065.post-77364515050054976832011-06-28T21:57:00.002-05:002011-06-28T22:20:34.851-05:00KCDC Talk - Guerilla Kanban: A Toolkit for Improvement<div class="separator" style="clear: both; text-align: center;"><a href="http://dl.dropbox.com/u/1597884/blog/downloads/Guerilla_Kanban.pdf"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqycNPbna5qEtTK3iTT8AoQl8ovD0IT5VTHX30aGtFg4cSJTHgd7TlaiDZi5WvOUlHFFL3eMXbnB4iFJDZDUfgBJM6Dbv3EvU-7QTScE13DF1wEcL7MxQ-ftnjka43v5nBdckPSy3EC27W/s400/Non-deterministic_slide.GIF" width="400" /></a></div><br />
<br />
For those who attended my talk, thank you for your interest. A <a href="http://dl.dropbox.com/u/1597884/blog/downloads/Guerilla_Kanban.pdf">pdf slide deck is available for download</a>.<br />
<br />
My Guerilla Kanban Toolkit For Improvement includes the topics:<br />
<br />
<div class="O1" style="direction: ltr; language: en-US; margin-bottom: 0pt; margin-left: 1.0in; margin-top: 6.72pt; mso-line-break-override: none; punctuation-wrap: hanging; text-align: left; text-indent: -.56in; unicode-bidi: embed; word-break: normal;"><span style="font-family: Arial;">•</span><span style="font-family: Calibri;"><b>Nature of Software</b></span></div><div class="O1" style="direction: ltr; language: en-US; margin-bottom: 0pt; margin-left: 1.0in; margin-top: 6.72pt; mso-line-break-override: none; punctuation-wrap: hanging; text-align: left; text-indent: -.56in; unicode-bidi: embed; word-break: normal;"><b><span style="font-family: Arial;">•</span><span style="font-family: Calibri;">Visualize and Manage Flow</span></b></div><div class="O1" style="direction: ltr; language: en-US; margin-bottom: 0pt; margin-left: 1.0in; margin-top: 6.72pt; mso-line-break-override: none; punctuation-wrap: hanging; text-align: left; text-indent: -.56in; unicode-bidi: embed; word-break: normal;"><b><span style="font-family: Arial;">•</span><span style="font-family: Calibri;">Variation</span></b></div><div class="O1" style="direction: ltr; language: en-US; margin-bottom: 0pt; margin-left: 1.0in; margin-top: 6.72pt; mso-line-break-override: none; punctuation-wrap: hanging; text-align: left; text-indent: -.56in; unicode-bidi: embed; word-break: normal;"><b><span style="font-family: Arial;">•</span><span style="font-family: Calibri;">Estimation</span></b></div><div class="O1" style="direction: ltr; language: en-US; margin-bottom: 0pt; margin-left: 1.0in; margin-top: 6.72pt; mso-line-break-override: none; punctuation-wrap: hanging; text-align: left; text-indent: -.56in; unicode-bidi: embed; word-break: normal;"><b><span style="font-family: Arial;">•</span><span style="font-family: Calibri;">Risk Management</span></b></div><br />
<br />
I hope to address more of these types of topics in future presentations. Let me know if you have questions!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-43815165544312041632011-04-25T11:32:00.001-05:002011-04-27T10:24:30.039-05:00Open Mouth, Insert Software Toolbox<div class="zemanta-img" style="display: block; float: right; margin: 1em; width: 310px;"><a href="http://commons.wikipedia.org/wiki/File:20060513_toolbox.jpg"><img alt="A toolbox, from Biltema)" height="225" src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f4/20060513_toolbox.jpg/300px-20060513_toolbox.jpg" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; display: block;" width="300" /></a> <br />
<div class="zemanta-img-attribution" style="font-size: 0.8em;">Image via <a href="http://commons.wikipedia.org/wiki/File:20060513_toolbox.jpg">Wikipedia</a></div></div>So often we hear the phrase, “I have many tools in my software development toolbox, and I like to use the correct tool for the job.” It sounds good. It appears to be a responsible approach. After all, why wouldn’t we want someone to have multiple tools at their disposal? <br />
<br />
The whole toolbox metaphor is fine on the surface. My problem with it stems from the incidentals in the discussion. In my experience, most people who reference having a “software toolbox” are really hiding from a more direct questioning or discussion of specific practices or methods. Instead of advocating for those methods they believe work, or more importantly, listening to others advocate for their methods, many in our field throw up the “toolbox” as a defense mechanism. It makes for a clean exit too. The problem is this mechanism limits learning for everyone involved. The “software toolbox” is a conversation ender, not a conversation starter.<br />
<br />
With that said, I am going to put my toolbox where my mouth is. <br />
<br />
First, my obligatory disclaimer: <em>Individual results will likely vary. Past performance does not guarantee future success. Your specific context and corporate culture are critical factors when deciding which tools are best for you. This is not intended as a comprehensive list.</em><br />
<em><br />
</em><br />
<span style="font-size: medium;"><b>Troy’s State-of-the-Art Software Toolbox:</b></span><br />
<ol><li><strong>Small Iterative Development Cycles: </strong>Software work is knowledge based. Knowledge in software is best improved by frequent feedback cycles. Early information feedback allows the team and customer to learn and improve at a much faster rate than when iterative approaches are not used. <br />
<em>Source: Extreme Programming, Scrum</em><br />
</li>
<li><strong>Explicit Work-In-Progress Limits: </strong>Even when working iteratively, teams will often have too much WIP. Ever observe a Scrum team start every single user story by the first day? I have, and without an explicit policy limiting work-in-progress, teams and managers will try to push too much work into the system. WIP limits allow a team to begin finishing work instead of starting more work. Team context switching is minimized, giving the team the opportunity to improve quality. <br />
<em>Source: Kanban for software</em><br />
</li>
<li><strong>Just-In-Time Planning: </strong>Plan just for what you can do, and nothing more. There is no waterfall-style comprehensive requirements document with this approach. Nor is it the heavy backlog grooming practices frequently seen in some Agile teams where user stories are analyzed and specified in detail months before they are implemented. Just-in-time planning also means no commitment-based time-boxed iterations. <a href="http://leansoftwareengineering.com/ksse/scrum-ban/" target="_blank">Optimal planning</a> occurs when the the team is provided with the best thing to work on next, no more and no less.<br />
<em>Source: Kanban for software</em><br />
</li>
<li><strong>High Discipline, Low Ceremony Engineering Practices: </strong>Emphasize practices that encourage collaboration and short feedback cycles. TDD/<a href="http://en.wikipedia.org/wiki/Behavior_Driven_Development" target="_blank">BDD</a> and a continuous integration server are a great start. After-the-fact, formal code reviews are typically too late to add anything other than rework. Code metrics are fine, but be careful what you measure. Are your code metrics making the code easier to understand and change, or are you happy just to apply “standards” to your code? Covering code with tests is a good thing. But higher code coverage doesn’t automatically mean your code base is functioning the way your customer wants.<br />
<em>Source: Extreme Programming</em><br />
</li>
<li><strong>Kaizen: </strong>Continuous improvement<strong> </strong>may come from inspect and adapt, <a href="http://en.wikipedia.org/wiki/PDCA" target="_blank">PDCA</a>, or other methods. It doesn’t matter if you prefer one over the other as long as you build an <em>information feedback loop</em> into your process. At the basic level, provide enough oxygen to the team to reflect, share ideas, and improve. Some teams may require regularly scheduled retrospectives, others may perform mini retrospectives or spontaneous Kaizen events during the project. <br />
<em>Source: Extreme Programming, Scrum, Kanban for software</em></li>
</ol>I’m hoping this is valuable information for you. This is my toolbox, and these are some of the more valuable tools to me. If I show you mine, will you show me yours? <br />
<br />
Will these work for you? I don’t know, that’s for you to decide. I just know that they work for me <em>today</em>. If I were a part of a brand new software team tomorrow, this is where I would start our discussion. And hopefully we grow to an even better place. <br />
<br />
<strong><em>“Merely having an open mind is nothing: the object of opening the mind, as of opening the mouth, is to shut it again on something solid.”</em> -- G. K. Chesterton</strong><br />
<strong><br />
</strong><br />
<br />
<div class="zemanta-pixie" style="height: 15px; margin-top: 10px;"><a class="zemanta-pixie-a" href="http://www.zemanta.com/" title="Enhanced by Zemanta"><img alt="Enhanced by Zemanta" class="zemanta-pixie-img" src="http://img.zemanta.com/zemified_e.png?x-id=7c88fbde-0f11-4b94-8897-b7ce20991a2b" style="border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; float: right;" /></a></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-28885101498840928082011-02-15T00:51:00.001-06:002011-02-15T01:00:47.643-06:00Code Metrics as a Project Introduction<p>I recently started some analysis work for a new client at work. As we began our work, we were quickly confronted with a legacy codebase that would be the subject of our proposed work. </p> <p>We need to give the client some technical feedback on the code. The obvious and common approach is crack open the solution and take a look. That approach usually results in anecdotal recommendations at best, so I turned to code analysis tooling.</p> <p>In the .NET space, a popular code analysis tool is <a href="http://ndepend.com/">NDepend</a>, so we gave it a try. NDepend generates a ton of metrics on your codebase and it is easy to get overloaded with data.  So, it is important to remember what your goals are with code metrics.  Do we need raw data or actionable information that can be presented to a client?  </p> <p>In our case, we need to report to our client the state of their codebase. Specifically, we need to convey how hard it will be to make changes to this legacy code.  A nice visual cue is the Abstractness vs. Instability diagram provided in the NDepend analysis report:</p> <p><a href="http://lh6.ggpht.com/_QzFkOCCfZAw/TVoiXB73UyI/AAAAAAAAD8s/lZHv_KTTKwQ/s1600-h/abstractness%5B9%5D.gif"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="abstractness" border="0" alt="abstractness" src="http://lh5.ggpht.com/_QzFkOCCfZAw/TVoiXy7HyQI/AAAAAAAAD8w/Obd9ogjBHs4/abstractness_thumb%5B5%5D.gif?imgmax=800" width="629" height="613" /></a></p> <p>NDepend defines “abstractness” as the percentage of abstract types (interfaces, abstract classes) to concrete types. Instability is defined as the ratio of efferent coupling to total coupling. Coupling at the assembly level is an interesting metric, but I am mainly concerned with the level of abstraction here.  As the diagram shows, this client has two assemblies with good scores (orange arrows), but one assembly with a very poor score (red arrow).  This would normally be a good sign, except that about 90% of the code is contained in the low scoring assembly.  </p> <p>Assembly level metrics are fine, but the metrics I am most interested in are at the type level. Assemblies can easily be manipulated by moving code around with any decent refactoring tool.  But types are the building blocks of code and tell the true story of code quality.  NDepend provides a matrix of scores for types as shown below:</p> <p><a href="http://lh5.ggpht.com/_QzFkOCCfZAw/TVokgRwVyUI/AAAAAAAAD9E/7LVk2l_adnI/s1600-h/type_metrics%5B10%5D.gif"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="type_metrics" border="0" alt="type_metrics" src="http://lh6.ggpht.com/_QzFkOCCfZAw/TVokg-Wg1VI/AAAAAAAAD9I/dQVpQU9zRP4/type_metrics_thumb%5B6%5D.gif?imgmax=800" width="618" height="219" /></a></p> <p> <br />The pink cells identify the worst 15% of offenders.  I am most interested in CC (cyclomatic complexity), Ca (afferent coupling), and Ce (efferent coupling). If you are unfamiliar with the terms cyclomatic complexity and coupling in software, I suggest a little more reading on the topic.   For our purposes, definitions are provided by the <a href="http://www.ndepend.com/Metrics.aspx#CC" target="_blank">NDepend website</a>:</p> <blockquote> <p><em><strong>CC</strong>: Cyclomatic complexity is a popular procedural software metric equal to the number of decisions that can be taken in a procedure.</em></p> <p><em><strong>Ca</strong>: The Afferent Coupling for a particular type is the number of types that depends directly on it.</em></p> <p><em><strong>Ce</strong>: The Efferent Coupling for a particular type is the number of types it directly depends on.</em></p> </blockquote> <p>Once the analysis report is generated, a quick glance through the type metrics will give you a good indication of the relative health of the code.  Lots of pink cells mean a more difficult journey ahead for the team. </p> <p>NDepend provides some overall application metrics as well. Nothing earth-shattering, but it is interesting to know things like total number of lines of code, percentage of code comments, number of types, and percentage of public methods.</p> <p><a href="http://lh6.ggpht.com/_QzFkOCCfZAw/TVoiZetutHI/AAAAAAAAD88/nqGCH_QoH2M/s1600-h/AppMetrics%5B6%5D.gif"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="AppMetrics" border="0" alt="AppMetrics" src="http://lh5.ggpht.com/_QzFkOCCfZAw/TVoiZvQ0DoI/AAAAAAAAD9A/fJ1O7dN1i90/AppMetrics_thumb%5B4%5D.gif?imgmax=800" width="518" height="408" /></a></p> <p>This is the type of information I find useful when starting a new codebase. I hope it’s helpful when you start your new project!</p> Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-48480571893716669642010-12-13T22:28:00.000-06:002010-12-13T22:28:00.143-06:00Kanban Training with David AndersonInterested learning more about Kanban? Why not learn from the best?<div><br />
</div><div>David Anderson has announced he has available seats for his 3 day intensive Kanban Coaching Workshop in Los Angeles, CA on January 12 - 14.</div><div><br />
</div><div><a href="http://agilemanagement.net/index.php/Blog/coaching_LA-jan2011/">http://agilemanagement.net/index.php/Blog/coaching_LA-jan2011/</a></div><div><br />
</div><div>I attended in May. The course is an absolute game-changer for project managers, team leaders, and recovering scrum masters.</div><div><br />
</div><div>Contact me if interested. I can get you a discounted rate.</div><div><br />
</div><div><br />
</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-64177713739340872942010-10-20T21:57:00.001-05:002010-10-20T21:58:09.323-05:00Easy On The Eyes PleaseI'm having some thoughts and reactions tonight that don't fit easily into Tweet-sized bites, so thought I would get back into this blog thing.<br />
<br />
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. <br />
<br />
<a href="http://www.flickr.com/photos/dominik99/384027019/" title="_-_ complexity [1] by nerovivo, on Flickr"><img alt="_-_ complexity [1]" height="180" src="http://farm1.static.flickr.com/182/384027019_5e64727276_m.jpg" width="240" /></a><br />
<br />
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. <br />
<br />
Wow.<br />
<br />
<a href="http://www.flickr.com/photos/maistora/358717500/" title="Simple magic by maistora, on Flickr"><img alt="Simple magic" height="180" src="http://farm1.static.flickr.com/141/358717500_f66314abd8_m.jpg" width="240" /></a><br />
<br />
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 <i>simple! </i>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. <br />
<br />
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:<br />
<br />
1. Keep it simple (seems obvious, but very few achieve simplicity).<br />
2. Get off your architectural high horse every so often and take time to smell the flowers.<br />
3. Make your intent as clear as possible.<br />
3. Keep it simple.<br />
<br />
Thanks <a href="http://geekswithblogs.net/leesblog/Default.aspx">Lee</a>!Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-6671186884241707065.post-47743027121748794372010-07-13T22:23:00.001-05:002010-07-13T22:23:29.177-05:00Topeka DNUG Panel Discussion on Agile<p>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.</p> <p>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). </p> <p><a href="http://www.amazon.com/Kanban-David-J-Anderson/dp/0984521402/ref=sr_1_1?ie=UTF8&s=books&qid=1279077242&sr=8-1" target="_blank">Kanban by David Anderson</a></p> <p><a href="http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381/ref=sr_1_1?ie=UTF8&s=books&qid=1279077313&sr=1-1">Implementing Lean Software Development by Mary and Tom Poppendieck </a></p> <p>Enjoy!</p> Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-23478361309321904082010-06-21T09:10:00.003-05:002010-06-21T09:19:59.104-05:00KCDC Kanban Presentation SlidesMy <a href="http://kcdc10.ning.com/" target="_blank">Kansas City Developer’s Conference</a> presentation slides are available for download (<a href="http://dl.dropbox.com/u/1597884/blog/downloads/WhyKanban_KCDC_2010.pdf" target="_blank">“Why Kanban?”</a>). For those who saw my LSSC10 presentation in April, the slide deck is very similar, with just minor modifications for the intended audience. This talk is designed as an introduction to Kanban, so advanced topics like classes of service are only touched on briefly. <br />
<br />
I failed to mention the local Limited WIP Society chapter (<a href="http://groups.google.com/group/limitedwipsocietykc" title="http://groups.google.com/group/limitedwipsocietykc">http://groups.google.com/group/limitedwipsocietykc</a>) 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.<br />
<br />
Thanks for the interest in Kanban!Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-6671186884241707065.post-33743146649573575092010-06-16T00:13:00.000-05:002010-06-16T00:13:01.984-05:00Speaking at KCDC on Kanban for SoftwareI'm honored to be speaking on Kanban at the Kansas City Developer's Conference on Saturday, June 19, 2010. Details are here: <a href="http://kcdc10.ning.com/">http://kcdc10.ning.com/</a><br />
<br />
Interesting in attending? It's free! They will feed you (free again) twice during the day. And there are some great speakers. Register here: <a href="http://kcdc.eventbrite.com/">http://kcdc.eventbrite.com/</a><br />
<br />
My talk will be a variation of my presentation for the <a href="http://atlanta2010.leanssc.org/">Lean Software and Systems Conference</a> in April. Attend the conference, enjoy the networking opportunity, and ask me some tough questions!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-47266157932516477892010-04-07T09:57:00.001-05:002010-04-07T10:00:16.719-05:00Topeka DNUG Kanban Talk SlidesThank you to those who attended my Kanban talk at the Topeka DNUG. We had a good turn out, but just a little short on time for questions. If you have any follow-up questions about the presentation, please feel free to post in the comments section here.<br />
<br />
Also, if you have any feedback on presentation, please let me know through this blog or by email: troyltuttle [at] gmail<br />
<br />
<a href="http://dl.dropbox.com/u/1597884/blog/downloads/WhyKanban_usergroup.pdf">Slides Download</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-17667453624891561672010-03-16T22:12:00.000-05:002010-03-16T22:12:51.118-05:00Kanban at Topeka DNUGI am excited to be speaking at the April 6 edition of the <a href="http://groups.google.com/group/topekadotnet/browse_thread/thread/7978b6fe9f5aef6e">Topeka DNUG (.NET User Group)</a> at <a href="http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=federal+home+loan+bank,+topeka,+ks&sll=38.984949,-94.864121&sspn=0.011976,0.02281&ie=UTF8&hq=federal+home+loan+bank,&hnear=Topeka,+KS&z=13&iwloc=A">FHLB Topeka</a> in Topeka, KS. <br />
<br />
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.<br />
<br />
Where: Federal Home Loan Bank Topeka<br />
When: April 6, 2010 at 11:30 am<br />
What: <i>Learn about Kanban!</i><br />
Food: Yes, <b>lunch </b>is provided, but please <a href="http://topekadotnet.wufoo.com/forms/topeka-dnug-meeting-attendance/">register to attend</a>. Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-64447219092559440412010-02-17T09:50:00.006-06:002010-03-17T22:54:40.326-05:00Guerrilla KanbanAfter speaking to a few <a href="http://groups.google.com/group/limitedwipsocietykc" target="_blank">local Kanban practitioners (and aspiring practitioners)</a>, 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 <a href="http://www.limitedwipsociety.org/" target="_blank">Kanban and Lean software online</a> 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<b>Background</b> <br />
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.<br />
<br />
<b>Making Improvements</b> <br />
<a href="http://www.agilemanagement.net/" target="_blank">David Anderson</a>, 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.<br />
<br />
<b>Mechanics of Kanban</b> <br />
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: <br />
<blockquote><i>Needs Prioritized –> Prioritized –> Dev –> Ready for Test –> User Testing –> User Accepted</i> <i>–> Released</i></blockquote>Represent the value stream on your board and track <b>every</b> work item (figure 1).<br />
<br />
<b>Figure 1.</b> <br />
<img alt="Gurilla_kanban_highlights" border="0" height="445" src="http://lh4.ggpht.com/_QzFkOCCfZAw/S3o08xkGSAI/AAAAAAAACv8/pBVxptgAR-4/Gurilla_kanban_highlights%5B6%5D.jpg?imgmax=800" style="border-width: 0px; display: inline;" title="Gurilla_kanban_highlights" width="595" /> <br />
<br />
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. <br />
<br />
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. <br />
<b> <br />
Figure 2.</b> <br />
<img alt="excel_backlog" border="0" height="123" src="http://lh6.ggpht.com/_QzFkOCCfZAw/S2-q2JJ-q7I/AAAAAAAACwA/w1VKgRKFAWw/excel_backlog%5B1%5D.gif?imgmax=800" style="border-width: 0px; display: inline;" title="excel_backlog" width="602" /> <br />
<br />
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. <br />
<br />
<b>Figure 3. <br />
</b> <img alt="excel_historicaldata" border="0" height="148" src="http://lh4.ggpht.com/_QzFkOCCfZAw/S2-q3TDnDMI/AAAAAAAACwE/_DgbC15h4qE/excel_historicaldata.gif?imgmax=800" style="border-width: 0px; display: inline;" title="excel_historicaldata" width="601" /> <br />
<br />
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?<br />
<br />
Once again, in the short term, Project X is primarily concerned with calculating cycle and lead time values for the development stage. <br />
<ol><li>Average cycle time is easy: (sum of cycle times / count of cycle times).</li>
<li>Lead time measures the backlog and average cycle time: (backlog count * average cycle time).</li>
</ol><br />
For Project X, this simple dashboard is posted beside the Kanban board (figure 1 red highlight) and emailed to stakeholders every week. <br />
<br />
<b>Figure 4.</b> <br />
<img alt="excel_metrics" border="0" height="465" src="http://lh5.ggpht.com/_QzFkOCCfZAw/S3o093bzGaI/AAAAAAAACwM/OZRUPcMFv6o/excel_metrics%5B13%5D.gif?imgmax=800" style="border-width: 0px; display: inline;" title="excel_metrics" width="616" /> <br />
<br />
<b>The Goal</b> <br />
We have two immediate goals with our Guerrilla Kanban implementation: <br />
<ol><li>Generate useful metrics to assist with immediate project planning needs. </li>
<li>Provide visibility to make observations and improvements to the process over the short and long term. </li>
</ol>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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<b>Reflection <br />
</b>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.<br />
<br />
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.<br />
<br />
I hope this inspires you to start your own Guerrilla Kanban!Unknownnoreply@blogger.com10tag:blogger.com,1999:blog-6671186884241707065.post-66535714708858746402010-01-20T10:30:00.000-06:002010-01-20T10:30:54.295-06:00LWS Kansas City DinnerWe 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. Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-74874071998415156302010-01-19T12:44:00.001-06:002010-01-19T12:45:19.647-06:00Speaking at the Lean Software and Systems Conference 2010I was quite pleased to learn my <i>Why Kanban</i> presentation submission was accepted for the Lean Software and Systems Conference 2010!<br />
<br />
I am very excited to meet and learn from some of the brightest thinkers in the Lean software development community. <br />
<br />
Want to learn more about Lean and Kanban? Check out the speakers and topics at LSS2010:<br />
<a href="http://atlanta2010.leanssc.org/">http://atlanta2010.leanssc.org</a>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-6671186884241707065.post-12196301687065889322009-12-11T22:07:00.000-06:002009-12-11T22:07:04.196-06:00Limited WIP Society KC Lunch!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. <br />
<br />
Send email to tuttle.troy at gmail (dot) com for details.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-46922841225242563362009-12-10T13:21:00.001-06:002009-12-10T16:31:35.283-06:00Kanban 101 SiteJanice Linden-Reed, an active member in the Kanban community recently announced an introductory Kanban site: <a href="http://kanban101.com/">Kanban101.com</a>.<br />
<br />
Great content with simple to understand definitions.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-62594854525061357562009-10-28T23:34:00.004-05:002009-10-29T16:02:23.944-05:00Kanban Slides Available from 10/28/2009 AgileKC MeetingMy Kanban presentation <a href="http://dl.getdropbox.com/u/1597884/blog/downloads/WhyKanban.pdf" target="_blank">slide deck</a> is available for download. Thank you to all who attended. Great questions and discussion afterward.<br />
<br />
My slides contain a references page with links to pertinent materials. Here are a few resources we discussed: <br />
<ul><li><a href="http://leansoftwareengineering.com/ksse/scrum-ban/" target="_blank">Scrum-ban</a> – Corey Ladas explains how to implement some Lean and Kanban principles on your Scrum team.</li>
<li><a href="http://www.amazon.com/Implementing-Lean-Software-Development-Concept/dp/0321437381" target="_blank">Implementing Lean Software Development: From Concept to Cash</a> - Poppendieck (published before Kanban for Software was coined, but very good resource for Lean organizations)</li>
<li><a href="http://www.limitedwipsociety.org/" target="_blank">Limited WIP Society</a> – the <i><b>best</b></i> Kanban resource available on the web (resources page)</li>
</ul>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-6671186884241707065.post-69609798137567463352009-10-26T12:54:00.000-05:002009-10-26T12:54:09.546-05:00What Others Are Saying About Software - 10/26/2009<a href="http://www.noop.nl/2009/10/self-organization-vs-evolution.html" target="_blank">Self-Organization vs. Evolution</a><br />
Another take on complex systems and team software from Jurgen: <i>"These teams are non-deterministic and therefore able to heal themselves, while an automated or controlled system is deterministic, and therefore not self-healing."</i><br />
<br />
<a href="http://leanandkanban.wordpress.com/2009/10/24/kanban-results/">Kanban Results</a> <br />
A Kanban report card from David Joyce at BBC in London. Inspirational!Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-47135740951398924322009-10-20T22:49:00.000-05:002009-10-20T23:29:17.282-05:00Kanban Presentation, AgileKC Meeting 10/28/2009<p>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.</p> <p>More information can be found at the <a href="http://groups.google.com/group/KC_Agile" target="_blank">AgileKC group site</a>.  </p> <p>I am honored and excited to speak to the local Agile organization.  Hope to see you there! <br /></p> <p><a href="http://www.flickr.com/photos/snapperwolf/2739817226/" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: inline; margin-left: 0px; border-top: 0px; margin-right: 0px; border-right: 0px" title="3208456912_cccec3bf91" border="0" alt="3208456912_cccec3bf91" align="left" src="http://lh4.ggpht.com/_QzFkOCCfZAw/St6OCGi90tI/AAAAAAAACcU/gEaFyPXWmh4/3208456912_cccec3bf91%5B10%5D.jpg?imgmax=800" width="244" height="164" /></a></p> Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-34272102210551714402009-09-23T22:27:00.000-05:002009-09-23T22:27:13.961-05:00Why Kanban? Presentation Slides AvailableI would again like to thank everyone who attended my presentation, "Why Kanban?" at the Kansas City .NET User Group meeting on Sept. 22.<br />
<br />
My presentation slide deck is <a href="http://cid-b850f49f44646e0f.skydrive.live.com/self.aspx/Public/WhyKanban/WhyKanban.pdf">available for download</a>. <br />
<br />
More Kanban-related content to come soon! Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-59798604707234407642009-09-14T23:14:00.002-05:002009-09-15T00:13:34.344-05:00Speaking on Kanban, KC .NET User Group, Sept. 22I will be speaking to the <a href="http://www.kcdotnet.com/">KC .Net User Group</a> 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<a href="http://groups.google.com/group/kcdotnet"> google groups mailing list</a>. Hope to see you there!<br />
<br />
Interested in participating further in Lean / Kan<span style="font-size: small;">ban discussions? Join the new </span><span style="font-size: small;"><a href="http://groups.google.com/group/limitedwipsocietykc">Limited WIP Society KC</a> mailing list. </span>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-4878691708211760712009-09-14T22:38:00.001-05:002009-09-14T22:40:01.398-05:00Announcing Limited WIP Society KCI am pleased to announce the establishment of the <a href="http://groups.google.com/group/limitedwipsocietykc">Limited WIP Society KC group</a>. 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). <br />
<br />
The group will be loosely associated with the parent site, <a href="http://www.limitedwipsociety.org/">Limited WIP Society</a>, the best collection of Kanban material on the web.<br />
<br />
As stated on the Google Groups page, the goals for the group are:<br />
<br />
<ol><li>Sign up software professionals and start an online discussion once critical mass has been achieved.</li>
<li>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. </li>
<li>Provide a support structure for software professionals to exchange ideas about Lean software approaches (Kanban).</li>
</ol><br />
I hope to see you on the group!<br />
<br />
<div style="text-align: center;"></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6671186884241707065.post-90172412963301159692009-07-30T10:17:00.006-05:002009-07-30T13:43:55.659-05:00What Others Are Saying About Software - 7/30/2009<a href="http://www.noop.nl/2009/07/commit-to-sprint-planning-or-definition-of-done-not-both.html">Commit to Sprint Planning or Definition of Done, Not Both</a><br /><span class="entry-author-name">Jurgen Appelo provides great blog content in a succinct package. </span>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. <br /><br /><a href="http://www.sep.com/lk2009">Lean and Kanban 2009 Video Archive </a><br />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.Unknownnoreply@blogger.com0