April 8, 2014
I Don’t Estimate Software Defects, but it's not as simple as just that. If you follow my advice, you'll also have a zero-defect mentality and you'll fix defects as soon as you find them. In general, I want a conservative measure of velocity, so I don't record in my velocity anything that was unplanned. Therefore, I likewise Don't Estimate Spikes.
I'm fond of The Theory of Constraints and Brooks’ Law. In that post I evaluated Brooks' Law in light of the Theory of Constraints in a way that I hope helps the reader understand both concepts.
Lack of Predictability is Your Biggest Problem. The senior leadership in most organizations I work with seem to agree. They aren't very interested in agile's agility. They want their design-build-test teams and their program teams to be able to make and meet commitments so they can make appropriate capacity constrained commitments across the portfolio and to external stakeholders.
Agile Health Metrics for Predictability was perhaps my most popular post on LeadingAgile's blog.
In Bottom-Up Implementation & Top-Down Intent, I discuss my recommended approach to agile transformations.
Related to that, I wrote a post arguing that you should fix your Structure 1st: Why You Should Not Start With Practices
Part of your structure involves your design-build-test teams, also known as your Scrum teams. In Use Feature Teams. Yes, Use Component Teams I explaining these approaches and why I recommend using both.
What do Scrum teams do during the Release Sprint? Good question. This post has the answer. In short, many things, but not developing code that can't be tested immediately.
Oh, I also published an article in Agile Journal entitled Identifying and Improving Bad User Stories along with my friend and co-author Chuck Suscheck. We put another article up on sticky-minds: The Problems with Overachievers on Agile Teams.
January 15, 2014
I'm committed to limiting my Work In Process (WIP) and to "stop starting / start finishing" but some stories/tasks just need to be put aside. I'm not talking about tasks that are blocked, waiting on someone else. Those I'll either flag or move to a Waiting/Blocked column. Rather, this post is about stuff that I need to stew on or need to come back to when my mind is ready. What do you do with those? Herein I'll tell you what I do, but I'm really interested in what you do. Please post your thoughts and ideas in the comments.
I don't have a HOLD column on my personal kanban wall. Hold seems to be a misnomer for me. It's a kind of lie. The work really still is in progress. It's WIP. I'm going to come back to it this week, maybe tomorrow, maybe even today. It ain't done.
I could split my task or story each time I feel the need to set one aside, putting part of it in DONE and part of it back in a ready column, but I kind of like my definition of what is a story, what is a task and what is a next-action (or sub-task). I don't want to monkey with that. Anyway, splitting stories is a kanban hazard.
PROJECTS, STORIES, TASKS, NEXT-ACTIONS & SUB-TASKS
For the following discussion you need to understand my context:
Getting Things Done (GTD), I note the next-action, or next several actions, on the Story stickie. Often, each one of these next-actions might take 5 minutes or less, so they don't seem to be a Story deserving of a stickie of their own.
So here's what I do for those tasks in that nebulous state of not done but not active either. I'd love for you to add your thoughts in the comments.
Some of my to-dos need time to stew, such as writing a blog post. I have lots of outlines and rough drafts. I create drafts quickly when the idea comes to me. Such activity never enters my personal kanban. In the spirit of GTD, if it takes less than a couple minutes to do, just do it. I very rarely create a Task or Story for such activity.
I'm pretty satisfied with how I do that.
IT'S DONE FOR TODAY AND A TODO FOR TOMORROW
I don't usually leave those in DOING for the week. If I've done it for today, I don't like leaving it in the DOING column. I usually move them back to some ready column each day. But it's still in progress for the week.
I'm not completely satisfied with how I do that. Sometimes I've left such a story in DOING.
What do you think about this? Do me a favor and post your thoughts in the comments before you go.
June 10, 2013
I recommend each team come to agreement on what's an acceptable maximum size for a spike. I recommend a day, or maybe two. If it will take more time than that, split it, just like you would for a story. Spikes need to have a clear acceptance criteria, a very specific question to answer. When the time-box is over, share the results with the team.
Often, such larger spikes are related to a user story and typically must be resolved before the story can be estimated. But for the spikes themselves, I recommend NOT estimating them. We want velocity to represent value added stories -- we want to measure the rate at which we add value. Either way, when using your velocity, when making release plans, you must understand your system and take into consideration when and how you come up with spikes and when you solve them. Do you find them late? Do you know about them but implement them late? If so, that represents unknown schedule risk.
I used to say that a consistent stream of day-sized spikes is good, but when I said that I would often forget to explain my context and assumptions. Having a continuous stream of new spikes that you solve almost as you create them makes sense if you are also doing continuous planning (without batching into large releases or without release commitments). Solving small spikes regularly keeps this activity from making velocity unstable.
Conversely, if you batch requirements into releases greater than, say, a couple months and if your organization is making release commitments, then in that case spikes represent risk in your backlog. Might want to knock out all spikes for the release right off the bat.
Wow, this is just my first post this year. I've been very busy with my LeadingAgile clients. It's time to get back to my writing!
November 15, 2012
Here are the sketchnotes from my November Agile Immersion workshop.
These sketchnotes were done by a business partner of mine, Jenny Trautman of evenview. Sketchnotes aren't the main thing evenview does -- sketchnotes are an artifact. What evenview does is help people bring innovative strategies into focus. They lead fun, high-energy meetings using interactive visuals that draw a team together. With their support, groups collaborate to develop a shared vision, create a plan for action, and implement their ideas. Use them for your next strategy meeting or kickoff.
By the way, this workshop is designed for everyone. No agile experience or programming skills required. All types of roles have found it benefical: product managers, marketers, managers, office managers, business development executives, developers, testers, CFOs, and etc. Check out this interesting blog post from a recent non-developer attendee.
October 29, 2012
At the end of each week I do a quick retrospective on my use of Personal Kanban, the tasks I've completed, and the week in general. I don't do anything elaborate or time consuming. Just a simple evaluation of how I'm doing.
I use two particular approaches to my personal kanban retrospectives more than any other.
+s and Δs
Most Successful / Least Successful
I'll take notes, again on an index card, on these high points and low points.
Not a Commitment
What I don't do is compare my actual achievement against a plan. I do "plan" my week, but it's not a commitment to specific tasks. It's more of a re-prioritizing of the backlog and preparation for the days ahead. I use that time to make sure I don't miss any commitments or fail to prepare appropriately.
I hope you found this useful. What kind of Personal Kanban Retrospectives do you do?
Register now for my 11/5/12 Agile Immersion Workshop. This low cost day-long hands-on workshop will guide you through an agile project, from inception through the first couple iterations. Through this immersion, you'll understand agile 1st hand. Lunch is included.
October 24, 2012
Not long ago I wrote about some changes I made to my personal kanban. Today I'm writing about why I do this. Much has been written about the benefits of using Personal Kanban and Getting Things Done (GTD) so I'm going to stick to what I personally get out of it.
I get uneasy when I have lots of unfinished projects around the house, half-read books languishing, things I've started and have forgotten about. ADD runs in the family so I'm likely an undiagnosed sufferer. When I rediscover something I once thought was important and have since forgotten, I remember why I thought it was important and feel bad for having not finished it. I feel stressed about needing to put one thing aside and finish the newly rediscovered badger. It's a little stressful. Not "I can't take it anymore!" stressful. Just a nagging background stress. There are plenty of stressors in my life so I don't want to add more if I can help it. And I can help it.
When I first started using them, GTD and Personal Kanban made matters worse. And better. It made me feel worse because now everything is visible -- all the half finished projects and incomplete initiatives. Yet it made me feel better, knowing that I won't forget anything. It also helped me prioritize my work explicitly and stick with that prioritization for as long as that prioritization made sense. My kanban helps me remember why things are in the state they are in, being intentional about what I choose to do.
After a while, GTD and kanban helped me reduce the backlog of partially completed work. It helps me focus on work already started. It helps me not start new activities that are of equal or lower priority -- or things that have a lower Cost of Delay. Seeing how much I have in process helps me to stop starting new work and to start finishing what I've already got going on.
I also discovered how much longer it takes me to finish tasks than I thought. Oh, yeah, "blog post"; I'll just typety type, a little proof reading, maybe a picture and I'll be done in half an hour. Heh. No, not really. Takes me a bit longer than that for the type of posts I do and the care I put into them. And there are all the other things: tweet it, email it to the person who requested I write about it, put a notice about it on some appropriate LinkedIn group, get interrupted for dinner, go to an Agile Atlanta meetup, decide to finish it tomorrow after work, and ultimately edit this post again because I thought of something else that should go in, like this paragraph. Anyway, kanban helps me understand that I'm an overly optimistic estimator. Understanding that helps me put stuff in the backlog instead of just starting it.
Now I feel much better. Sure, there are new things that come along that are Important, Urgent or have a High Cost of Delay, and I'll increase my WIP for a while. And that can be stressful. But it's a different kind of stress. No more is it "I have all this work and it's out of control". Now it's "I have some important work to do, but I know what it is, what state it's in, where it is stored, when it's due, and I feel in control." I still have a lot I want to do. But I'm in control.
October 2, 2012
Matt's tweet is provocative: Sprint "commitments" are an amortized death march.
If sprint commitments lead to a death march, something is wrong in your organization. Sprint commitments could be used by poor managers to browbeat the team.
The risk of a death march, however, is not the reason to not have a strong sprint commitment. You can (possibly) fix that problem. You can (possibly) have good, enlightened managers. Besides, there are many ways to use Scrum poorly. Should we throw out every misused practice?
No. But sprint commitments are dubious.
It's not the sprint commitment we are after. It's not what we really want in the end. It has no value on its own. What we're after is that thing we hope to get from having the sprint commitment. What we hope to get is a team that is committed to each other, working together to finish what they set out to do. We hope everyone works on what we agree to work on rather than whatever darn thing anyone wants to do. We hope to not have unfinished work at the end of the sprint.
Too bad this is a fallacy. The fallacy is that for each desired outcome B there must exist a cause A.
In complex adaptive systems it doesn't always work out that way. I might even say it rarely works that way. Whether the sprint goes well or poorly, there are side effects of such policies. But this post isn't about the side effects. For the manager, though, when the sprint goes poorly the best possible outcome is...
If what is committed to is generally kept low (appropriate), pace should be sustainable over the long run even with some rare overtime. When appropriate overtime does happen:
In this way, sprint commitment should drive careful planning.
But is careful planning in batch necessary or is it waste? It can be useful in some contexts, but bogus in others. What's the point of a sprint commitment if you are committing to something very small, knowing that you are going to add more work to the sprint? If we plan less work to meet a strong sprint commitment, and also plan to add more work to the sprint later, then we are approaching continuous planning and might as well make the jump to iteration-less flow (e.g. and use Kanban).
We want a stable velocity. We want teams to be predictable. But requiring a strong sprint commitment is neither necessary nor sufficient. It's other stuff that makes us predictable, namely: finishing sprints cleanly every time; good backlog grooming practices; good story estimation practices (if using Scrum); limiting WIP; not starting work you can't finish in time; the "keep it working" principle; refactoring and SOLID design principles; good release planning and intelligent use of spikes; and so forth.
Just work directly on that stuff.
Truthfully, I've used sprint commitments and have also gone without them. They are useful in certain context, and dangerous in others. I consider the leadership, the managers and scrum masters, the team's agile experience, and how much time I'll have to coach the team before making the call on sprint commitments.
Matt Barcomb wrote a nice article on good and bad commitments. Go read that and the very thoughtful comments posted in reply.
I briefly touched on sprint commitments in my post on unstable velocity.
September 22, 2012
The Distance Theory
The likelihood of a team voluntarily using an agile space...
- is indirectly proportional to their proximity to each other.
Teammates are unlikely to use the shared space if their cubes are only three steps apart.
- is directly proportional to the sum of the distances between the cubes of the team members.
The more scattered the members are, the more likely they are to meet in a common location. Therefore, the likelihood of a team using the space may be proportional to the team size. This rule holds as long as that aforementioned sum of the distances is greater than the sum of the distances from the cubes to the agile space.
- is directly proportional to their proximity to it relative to their proximity to each other.
No one will use an agile space that is much further away than whichever cube is most central.
The Equipment Theory
The likelihood of an individual voluntarily using an agile space...
- is directly proportional to the computer speed and display size of the team computers relative to that of the computers in their cubes.
Equip the agile space with the most powerful PCs and beautiful monitors, and keep it that way.
The People Theory
The likelihood of a team voluntarily using an agile space...
- is directly proportional to likelihood that the team-lead (or some core, key individual(s)) can usually be found the lab.
Social aspects and the exchange of info/ideas matter.
- is directly proportional to the cohesiveness of their tasks.
Programmers working on disjoint tasks are less likely to use a shared space.
- is indirectly proportional to the number of teams using that space.
I can easily listen in or tune out discussions between my team members. Discussions between members of other teams are not easily tuned out. (Cognitive dissonance.)
The Environment Theory
The likelihood of an individual voluntarily using an agile space...
- is directly proportional to the positiveness of daylight.
Daylight is a positive and negative factor.
- Daylight good.
- Glare bad.
- Looking at distant objects good. Reduces eye strain.
- Heat bad.
- Working shades are good.
- Dysfunctional shades are bad.
September 10, 2012
The point here is that they were innovative in coming up with a BVC that radiates status and helps them communicate. Too many teams get stuck in a rut, using the same old ineffective ways of doing their standup. And often abandon the practice altogether.
The ToursIt was neat to see the Kanban being used by one of the teams and to talk about how they were using it and what they were getting out of it. It was cool to talk about their facilities and compromises they made and how the layout impacts pairing and team size. And we had good discussions about estimating tasks and stories. And other stuff too.
We've had prior tours as well and in each the host has had surprising candor, discussing the honest state of their agile practice including their current struggles.
Alex Kell wrote a nice post about the earlier Agile Tour @ Allure.
And the RedPrairie Agile Tour was neat because we got to sit in on an end of iteration innovation demo, a kind of a technical show and tell across several teams of some neat new technologies they've experimented with or put into place.
I'm planning other tours as well. Follow me on twitter and subscribe to the Agile Atlanta yahoo group to make sure you don't miss the next one.
Each company that has hosted a tour has gotten something out of these tours as well. Let's set one up at your company. Give me a call or drop me an email today.
September 5, 2012
Writings about the Kanban Method eschew story estimation as being both waste and inaccurate. Even relative estimation. So instead, they recommend understanding your system well and gathering the metrics on average lead time. With that data you can compute how long it would take to complete a backlog of work. Even some Scrum teams are beginning to use this approach. I like this method.
But to use this approach you must truly understand your system. I'm talking about understanding the behavior of the system and in particular the actors in the system.
For example, it's common to split stories once they get higher in priority and closer to development. That's a good thing and it happens in Scrum and in Kanban. This refinement may happen many times to a story during it's lifetime. I guess that most teams are completely unaware of just how many times stories are split along the way. Often I see stories indirectly split; Setting out to rewrite a set of stories, the set will be thrown away and a new set written, with no one noticing that there are more, and finer grained, stories in the new set.
A similar effect happens in Scrum when teams estimate defects and include those points in their velocity. They most often have no estimate for defects that have yet to be discovered (neither in quantity nor magnitude of effort). If a significant number of new defects are coming in all the time, then such teams are inflating their velocity and underestimating the magnitude of their backlog. This is a recipe for disaster. Such teams wonder why they never hit their dates. Others blame it on a quality problem.
As an aside, any commitments regarding the completion of the backlog have to be in concert with the stability of the backlog. You need to compute a new end date whenever the backlog changes. But that's the same whether you are using lead time or relative estimates with velocity.