Browse by Tags

• Agile
• kanban

• Done For Real

  I had the good fortune to sit in on a day long session with Dave Hussman (who is awesome, by the way) on the topic Agile coaching as a lead in to the Atlanta APLN meeting . It was chock full of tips and I recommend getting out to see Dave if and when you get the chance; he packs a lot of knowledge into a short amount of time in an extremely entertaining way. One of the questions he asked is: when is a feature done? This is a perennial topic with Agilists and it's a very valid question; how do we know when a feature is "potentially shippable?" I piped up with my answer: a story is done when it's in production use . That was a little different than the answers from the others in the room. Think about it: we're not delivering value until that value has been delivered. That's a very Yogi Berra way of saying that until the user's using, that feature you made isn't contributing to business value. In a way that's one of the original premises of Agile: release early, release often. This is the reason why I like the cycle time measure over the velocity measure. Cycle time tells us how long the feature took from the time it was green lit to the time it went into production. This gives us a real measure of how long it takes to deliver business value. Velocity simply tells us how long a feature took to develop (unless, of course, we have release-per-iteration) Agile asked us to work better as software development teams and deliver in tiny little batches. Lean asks us to do the same thing, but put the software team in the context of the larger organization and from the customer perspective. Think globally, act locally. Doesn't matter how rockin' a development team is, if those features are being held in inventory until waiting for some deployment event, they're not done; they're only done as far as you're concerned , and, last I checked, there were more than developers and testers involved in the process of delivering software. Posted Sep 26 2008, 09:03 AM by CodeBetter.Com - Stuff you need to Code Better! Filed under: Lean, Agile, kanban

• Identifing Waste, the Lean Way

  As mentioned in a previous blog post, waste elimination is usually the most obvious and least resistant way to improve value and flow in a product. So I’m just going to jump right into some of the waste factors that are usually easy to identify, evaluate, modify and sustain their solutions in software product development. Not going to cover all forms of waste, just the most common ones. Bugs and Defects. A bug, in simplist terms, is any behavior of the system that do not meet the expectations of the customer. Defects have a bit broader scope of who’s definitions cross into other forms of identifiable waste. A defect may not be a symptom of the product itself, but rather of the team, or communication patters, or materials transportation, or processing and production. Missing a deadline is a defect, but it is a defect of a larger entity than the product itself, same as missing information (most commonly found in requirements gathering, prioritization, feedback loops). Bugs cause rework. Rework is waste. Retest is waste. Every single bug and defect, no matter how large or small, has an impact on the overal production cost of a product, due to having to revisit ideas and code that have been addressed in a previous cycle. Movement of Artifacts and Materials in Excess (Transportation) Unnecessary movements are wasteful activities, and by unnecessary, I mean movements that do not add value. Routing is probably the largest culprit of excess transportation. Routing of materials is usually something that has room to be streamlined and improved and should be looked at promptly. Signature requirements, too many eyes involved, processes out of sync or sequence, lengthy lead times, report approvals, data replication techniques, poor configuration management, lengthy feedback loops; all of these are usually causing too many movements to be involved in order to achieve a goal and end up increase the cost of production. One thing not so obvious? Office layout. Yes, the layout of the facility in which teams work in very often causes excess movement of resources. Think about that one. Wait Waiting overlaps into excess movement a bit, but still has its own caveats. Feedback loops. This is where most software teams have room to improve in waiting. In manufacturing, its usually materials and inventory shortages that cause excess waiting. When you wait, you waste. That’s obvious and simple. Waiting pops up in so, so many ways in software development. Document generation and reviews, bugs and defects, resource shortage (not enough staff), somebody on vacation when collective code ownership is not practiced, no continuous integration, no unit tests, wrong kanban levels, manual and lengthy deployment scenarios, poor workflow… I could go on and on. Usually in software, like mentioned in the beginning of this paragraph, its feedback loops. And more common, is feedback from your own product, not the customer themselves. Feedback in the forms of unit tests, integration tests,... Posted Sep 04 2008, 08:00 AM by CodeBetter.Com - Stuff you need to Code Better! Filed under: Lean

• An entry into lean

  I, like many others, have been head deep into lean methodologies such as kaizen, kanban, 5S, value streams and lean in general. As I continue to learn and practice these things, I’m going to start publishing, much like Laribee is with his focus on Kanban , in order to gain feedback and ideas. I’m going to cover things in a bit more general matter than just approaching one methodology, but hope to hit on them all. Today I just want to give a primer into lean so those of you who haven’t done much reading into it have a foundation from which we will build. When you hear lean, its difficult not to throw the word efficiency into every sentence under discussion. Efficiency is a metric and is easily measured for most things. If your car is rated to get 20 MPG and you are achieving only 15 MPG, then your car is 75% efficient as it relates to its gas mileage. Efficiency has its counterpart, however, and this is waste. Many people will tell you lean is about eliminating waste, but that is not entirely true. Lean is about improving efficiency, and waste elimination is typical the least expensive, most effective way to improve efficiency, but its not the only thing. Thus, don’t focus soley on waste elimination, but on the improvement of efficiency itself. For developers, obvious waste is easy to spot. Phone calls, emails, ESPN.com and things of the like are main culprits. You have to stop and ask yourself and evaluate each activity: does this activity help me achieve my goal for the day as it pertains to adding value to my client/product/service etc. Identify – correct – sustain. Kanban, as Dave has been implementing, is one system that helps with waste elimination by having a feedback loop and a continuous work flow by pulling downstream from upstream and current status evaluations. Other methodologies have different principles behind them, but to achieve the same goals, and I will be talking about those as they each are forms of lean used to Identify Inefficiencies – Make Corrections – Sustain Positive Process Improvements. Lean literature is everywhere. Take some of the keywords I’ve talked about here and search the web for them. You’ll find lots of great information. Posted Aug 28 2008, 06:50 AM by CodeBetter.Com - Stuff you need to Code Better! Filed under: Lean

• Introducing Kanban at Xclaim

  We've rolled out Kanban at my company Xclaim Software. Prior to this we were following a more-or-less XP process evolved and tweaked over some two years. Even though our team has been doing the Agile thing with good results, there are times that the process seems a little opaque and wasteful. I've noticed that it's hard to surface where we're encountering bottlenecks or impediments. Planning and maintaining a large inventory of backlog creates waste; planning can take several hours for large batches of new stories and, while I think there's good value in preparing a as-full-as-possible backlog at the beginning of a project, I see very little value in maintaining a backlog over three months at a maximum. There's simply too much risk of redundancy and re-work in a large backlog. For a while now I've seen iterations as an arbitrary nuisance. We all know velocity is a yardstick measure that's imprecise and best used for rough planning. We can also take points delievered over any two points of time and compare this number to previous durations to develop a trendline. Over a longer history we can use these numbers as a measure of throughput and improvement. Why then do we need to make them reset every Wednesday? If we're using similarly-sized items -- which we are -- it seems that feature cycle time (time from 'activation' to 'in production') is equally useful and much more understandable by both customer and developer. A big source of waste, waste due to over-processing , is the planning, retrospective, and customer demo ceremonies. It's easy to burn a half-day or more in these meetings and the fact of the matter is that a lot of these things can just be JIT'd on an as needed basis with the right people getting us much closer to the lean concept of pull. Is it too much of a stretch to say project determines process ? Every project we work on and environment we work in will come with requirements that drive a customized process. Of course we can't get there from day one. We need to setup a good baseline with the practices we know have broad applicability, acceptance, and tolerance: TDD, rolling wave planning, etc. Good Agile teams, however, continually adjust their process to fit their product and the needs of their customers. In a sense, we're designing our process as we go and this is something I see Kanban encouraging. There's a few things to say about this Kanban thing we've got going on, and I'd like to tackle this as a mini-series to make the posts digestible. I'll continue with five installments to start: 1. Why bother? Pull, flow, throughput and constraints. 2. Anatomy: queues, buffers, work-in-process, standard work and order points. 3. Developing and introducing a Kanban in your team. 4. A tour of our initial Kanban pipeline. 5. Handling rework and the zero defect mindset. 6. TBD If you're interested in Kanban, I highly recommend subscribing to the Yahoo! Group... Posted Aug 24 2008, 09:10 AM by CodeBetter.Com - Stuff you need to Code Better! Filed under: Lean, Agile, kanban