Limited 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. 

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

Kanban 101 Site

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

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

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

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

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

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

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:

1. Sign up software professionals and start an online discussion once critical mass has been achieved.
2. 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.
3. 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

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

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

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:

1. Team members sound like they are reporting rather than sharing.
2. A significant number of team members are visibly nervous before their update.
3. The team starts to dread the daily standup meeting, whether stated or observed.
4. The standup meeting is directed (choreographed) by someone.
5. 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

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

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

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

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

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

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

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

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