Tag Archives: kanban

Life, The Universe, Startups, And Everything

Recently I finally figured out what I’m doing in my startup.

Not how to succeed — growing very large is still ahead of me — but how to know what to do next. Here’s what I learned.

I have two theories to test, a value hypothesis and a growth hypothesis.

Value hypothesis: if I present this to you, in this format, you will exchange with me something that I find valuable. Perhaps money. Perhaps your time.

Growth hypothesis: if I do these things, I will be able to present my value proposition to X number of new people.

One of these is called sales, the other marketing. But do not be concerned with business-sounding words. You don’t have to start reading tons of business blogs or building imaginary worlds with spreadsheets. In fact, that can be very dangerous, as it causes you to emotionally bake-in ideas that most likely are completely fallacious. Just look at it like all you have is these two very tenuous theories.

Your job is to make very precise and defined hypotheses — if I do X, Y will happen — then run a test on them to see if they hold up. You are a scientist studying a completely unknown field of study. Come up with two hypotheses, one value, one growth, then test them. If they fail, change the hypotheses until they pass. A failure is a good thing! But it means you need to decide whether to give up or pivot. Most new people to startups build some huge product — one hypothesis — and never really test it. Good startups build dozens of testable hypotheses and test rapidly. Bad startups take forever to get to a test. Or they run out of money long before they ever get around to it.

Here’s the critical thing: The goal is the passing test, nothing else.

Value hypothesis: if I show a bunch of people a bushel of apples while they are at the flea market, 5% of people will buy one for one dollar.

Growth hypothesis: if I give you half-off an apple in return for your wearing an “I bought the best apples ever at Joe’s Booth!” badge, you will bring by two other people who will also buy apples.

By creating and continuing to define these hypotheses, you build a self-sustaining system of creating value, or a business. One way to break down your two theories into finer hypotheses is like this:


But there are others. As you make your hypotheses more and more detailed, you start creating a very defined structure to the test. This structure is your business model. A business cannot succeed — or fail — without creating and testing hypotheses. If you’re not testing hypotheses, you have an expensive hobby, not a business.

Want practical value? Create a Kanban board around the hypotheses you are testing, color-code your tasks to match up to what you are testing (Trello is really nice for this). Then you’ll know that every thing you do each day is for a reason. You’ll also be able to prioritize your time and energy better.

Write these down. Put them in a public, visible place for you. Everything you do — go to seminars, learn how to sell, read a book on startups, watch a video on programming, life, the universe, and everything else for a startup — everything fits into this model.

Use it.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Video Series Kicks-Off

A month ago I was talking to a client when the subject of Agile reporting came up. There was a lot of discussion around tools and meetings and all sorts of complexity that might occur in a large Agile program.

Feeling a bit flustered, I walked away and started drawing on a nearby whiteboard. What’s the maximum amount of visual indicators you would need to run a large, complex Agile program? It’s a small, finite number, and maybe by just getting it all out on the wall it would be clear that the real work is in running the program, not all the tooling and pretty displays. You should be able to capture, report, and analyze program status in just a few minutes per day. The rest of your time should be spent, well, working.

Took about an hour to draw it all up, and folks liked it enough to put a big “Don’t Erase!” on the board. Last I saw it was still on there.

But what really sucked was that I could see myself having the same exact conversation with another client in a month or two’s time. And having to draw it all over again. Was there some way to capture these kinds of whiteboard chats so they could be reused and shared more easily?

Turns out yes, yes there was. Using a graphics tablet and some software, I could capture a whiteboard chat and not have to repeat it. Way cool.

So then I thought, what’s the most helpful question I could answer for folks on the net? Something that they would have a difficult time getting from others?

I felt the answer was “How to prepare for Agile Adoption” because there are so many opinions, it’s tried so many different ways, and vendors have a conflict of interest — many times they’d much rather take your business and hope they can straighten things out later than tell you up front you’re doing it wrong — especially if you’re willing to sign the contract with somebody else. By being a talking head I could offer up my years of experience and not have “skin in the game”. I’m just sharing what I’ve seen.

Well this was getting to be a lot more fun than electric cooking, so, of course, I had to do a few more. After all, what would be the fun in just two? Today I finished up “Scrum Vs. Kanban”, which is a look at the two methodologies and how to apply them in your organization.

I have a list of a dozen or so topics I’d like to do, but I’m not sure if I’ll be able to do all of them. This is a new format for me and I like it because it combines teaching, movie-making, and technology development.

For those of you interested in the business side of things, the videos provide a calling card for me, they point traffic at my micro-publishing site, Tiny Giant Books, and since they’re about management in general and not some specific technology, hopefully they should hang around on the web for a long time.

But the biggest reason to do these is that all the pieces just came together. I had the tools, the material was already put together, I had deep knowledge in an area that many might find useful, and it looked like an opportunity to help lots of folks. It was just a no-brainer kind of moment.

If you have any ideas for topics or feedback from the videos you’ve watched, let me know! I’m enjoying learning this new media, and it the more feedback I get the better the result for everybody.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Making Of Agile Program Management In 15 Minutes

Yesterday I finally got around to doing something useful with one of my Christmas presents, a Wacom Intuos5 digitizer tablet. For a sample project, I created a 15-minute video about #agile program management — “Agile Program Management in 15 minutes

I bought the tablet because I found myself doing a lot of training using the whiteboard, and I’d like to re-use some of that training instead of having to sketch things out over and over again. (Videos and pictures of whiteboards work, but they’re far from optimal)

So this video came straight from a talk I gave to some Agile program managers (RTCs) a few weeks ago — all the material was on photos on my cell phone. I re-sketched the diagrams using Photoshop and the digitizer — while recording with Camtasia Studio

Later, using CS, I sped up the drawing (you don’t want to watch me draw) and added the narration. Of course, there’s a lot more I could do once I get this format down — callouts, hotspots, loops, user input, adding web cams, etc. But for now this was just a proof-of-concept.

The original diagramming took about two hours. Doing it all for the first time like this took about 8 hours, with another 2 or so spent in video editing mode. Fair warning: video editing uses a freaking lot of HD space and memory. I think for the 15 minutes of video I produced (around 15MB) the raw footage was over 70GB.

Fun stuff, though! Can’t wait to do the next one.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Who Moved My SMEs?

Working in a team in a large organization? Having to use SMEs? What’s the best way to do that?

SMEs (Subject-Matter Experts, pronounced “Smees”) are an integral part of any large group of developers. They are the guys who know a bunch about how a certain thing operates and are helping the team dealing with it.

Many times they have a special role and title. A Project Manager is an example of a SME — sometimes PMs have multiple teams, so they “visit” each team and help them. A DBA could be a SME, as could an expert in some business process. SMEs know so much they have to get spread around.

SMEs might not have deliverables. Maybe you need the online marketing expert to sit in on team planning sessions while you build-out a new website. They’re spending 2 hours a week with you, but you don’t get a new widget when they’re done.

The problem for Agile teams is twofold. First, is this person on your team or not? From a pigs-and-chickens standpoint, obviously they’re part of the gang. The entire reason for them to be there is to speak up and participate as much as possible. But from a team commitment standpoint, the most they can do is provide feedback on whether they think stories can be accomplished or not. So the answer is “it depends”. They’re a little of both. Pigkens. Chickpigs.

Weirder still is the viewpoint from the SMEs standpoint. So you have a team of specialized experts. They are tasked out to dozens of teams all over the organization. Is this an Agile or Scrum team?

To be more specific: does this team make group commitments to clear, testable deliverables inside of fixed timeboxes? Can they predict when any item on their backlog will be delivered? Is there a Product Owner that prioritizes work and elaborates on how it is to be completed?

I think the answer is no, they are not a Scrum team in any kind of traditional sense. They can certainly use many Agile practices, though, like stand-ups, paired-work, 40-hour-work-week, and so forth.

They also can certainly use Kanban to track and somewhat prioritize their work. Perhaps over a long period and lots of data, you can even start to spot and predict patterns.

The bigger question is: do you really need SMEs? I think in a large organization you end up having them one way or another — it’s just the way the math works out. If you are employing 1,000 people, while 90% of them might be perfectly cross-trained, I can guarantee you that 100 or more are going to be there especially because of a targeted knowledge area that they have mastered that is not easy to share. I’m all for making as many things as possible into skillsets; things like project management, database work, or user interface design. Teams should have various skillsets, and organizations should manage and encourage cross-training.

But as noble of a goal as that is, you just can’t do it with everything, especially in BigCorps. This is the difference between how we’d like the world to act and how it actually is. We run into this in the Product Owner role quite often.

SME’s, and SME groups, are probably here to stay. The question now is: are we managing them as efficiently as we should?

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Kanban Vs. Defect Hell

Do you have a huge pool of defects, bugs, and fixes waiting to work on? So much that you find it impossible to balance it with other project work?

I’ve heard three versions of the same story about how teams fixed this problem over the last year. I’m always cautious of over-generalization, but once our sample size gets to three it’s time to share.

The first part of the story goes like this: after releasing super-cool whiz-bang 4.0, the team is given a lot of fixes to make. For a while, everybody works on them, but management has other ideas: it’s time to work on super-cool whiz-bang 5.0, guys! Surely you can do this other stuff in the background.

So the “other stuff” is taken up by one or two guys, or it’s farmed off to India, or a couple of guys come in on the weekends for a bit to try to tidy it all up. There are a lot of plans for how it’s all taken care of.

Only it doesn’t work the was it was planned.

Instead, the load becomes bigger than the guys can handle. Not only stuff from 4.0 is in the list, there is still stuff from 3.0, 2.0, and 1.0 that hasn’t been fixed. The list gets huge.

Acting logically, you set up a triage. Things come into the list. You take a bit of time to estimate how big it is. Is it 1 day? 2 weeks? 3 months? Once you know roughly how big items are, then the business guys can make decisions about priorities. So the next thing to set up some kind of field for priorities, maybe low, medium, and high. Maybe forced ranking. Of course you use some kind of online system. After all, this is the 21st century! All important things must happen online somewhere. If it’s not online, it’s not important.

But wait a dang minute, here. Some things are mission-critical fixes, like when production tanks. You can’t keep working on fixing a report when the whole thing is broken. So you make a rule that when production tanks, everybody stops work and fixes it. Then they go back to whatever they were working on.

After a bit of time, you notice that not only is the list huge, it just keeps growing bigger and bigger — much faster than you could ever hope to catch. You’ve just entered Defect Hell, where a big dump-truck comes by once a day and piles an endless stream of crap on top of your head.

This is bad for everybody. For customers, things are broken and never get fixed. For other people in the company, they start losing faith in the ability of the team to fix problems quickly. For the team itself, they’re on a demoralizing death-march without end.

Bad. Bad. Bad. And if you’ve worked in a big organization at all, you’ve seen it.

In most places, the response to this problem is to simply keep over-complicating the plumbing. Perhaps you add another field to your list, like “severity”, or “impact”, or “will cause loss of customers” Maybe you create little automated email systems, flashing lights, or loud sirens. The hidden message is obvious: you dumb defect fixers need us to help kick you in the butt so that you’ll work faster.

That never works, so then, sadly, organizations will invent completely new ways of fixing the problem. Instead of complicating the existing system, another system will grow up alongside the first in order to “really once and for all fix the defect problem” Perhaps it has red flags, or little stuffed animals that explode. The safe money says it’s something that looks very serious and has a lot of complexity underneath. Maybe there’s a class or a little gold star you get to wear.

The problem here is outhouse process engineering, or the idea that a few smart guys can sit around with a team of super-users and pinpoint the exact nature of the defect-tracking system to a degree necessary in order to design a one-size-fits-all solution.

Yes, Six-Sigma Guys, I’m looking at you.

But you are by no means alone. Not at all. All of us in technology believe we can over-generalize and then over-apply those generalizations.

And we are most always wrong when we do it. Technology development, no matter how much we’d like it to be, just ain’t manufacturing. It’s R&D.

Here’s how the second part of the story is turning out for some folks:

Take a look at your data. How long does it take to fix a defect on average? For our story let’s say the answer is 25 days.

Throw out all the other complexity. We know on average it takes 25 days to fix any defect. Yes, it will vary by the individual case, but the variance is not important right now. Addressing it causes more problems than it solves.

Second, eliminate any sort of up-front sizing, prioritizing, or tool-based data nightmares. Simply make a list. Once again, the overhead creates more problems than it solves.

Third, create a kanban board with some steps you think might be common for all defects. On one side might be “start” on the other side “test” Don’t worry if it’s perfect, just throw it out there. If it doesn’t work for you, change it. Immediately. It’s your board, not anybody else’s. It doesn’t exist as a rule anywhere.

Fourth, pick a number that represents your maximum capacity, i.e., the amount of stuff you can work on at any one time. let’s say you’ve got a couple of people working on things and everybody decides that number is 3. But it could be 7. Just like the layout of your board, don’t spend a second over-engineering it. Pick something and then adapt. it’s important to get buy-in from your customers on this, but the critical thing is that you have to pick some number that everybody agrees on. This number represents work saturation — when you have 3 defects on the board, you’re loaded. You’re not allowed to add more on the left until one comes off the other end.

At this point, you have a simple question for people submitting things to the list: what would you like to have done in 25 days? They can flip for it, arm-wrestle, conduct decision-facilitation meetings — it doesn’t matter. From the team’s standpoint, just let them know. The business must self-organize to work through this.

There are a lot of objections to this setup, mostly because it ditches a lot of complexity that we just “know” is important. What about things that have to happen immediately? Well, make sure they get pulled next. What about things that finish early? The way kanban works is that once something is finished, the next item at the top is pulled. What about people trying to submit new feature requests disguised as bugs? That’s a common worry, but as it turns out it only happens a very small percentage of the time, maybe 2 or 3 percent of the total submissions. When the team finds one, let them escalate if you like. It’s not a big enough deal to add complexity to the system. Why are we giving up the step of sizing the effort before it goes in the list? Because teams that look at the data are finding they spend between 25-40 percent of their time simply sizing defects that may never get fixed. What about things that stay on the list and nobody ever puts it in the top three? Things on the list over six months get booted. If they’re important, somebody will put them back on the list. If not, they won’t.

Once all the objections are satisfied, what I’m hearing is that this is good for everybody. For the teams, it gives them some amount of sanity: they know what they are working on and have freedom to adapt and improve how they solve problems.

For the business partners, they start having to have real conversations about how much they can do and what needs to be done next, instead of just tagging everything “urgent” and throwing it in an electronic bucket somewhere. It also cuts a lot of the cruft out. The question of “what do we want done in 25 days” is a solid question with real impact. Checking little boxes on a form somewhere is just an exercise in frustration and futility.

Also the business starts to note that things are arriving as scheduled. Many things are done in much less than 25 days, but somehow even the outliers get pulled in under the limit. The business starts trusting the team more.

And, after a few months, as the team relaxes into a flow and starts self-optimizing, the 25-day lead time starts decreasing. It’s 22 days, then 18 days. As the lead time decreases, velocity through the system increases.

In all three stories I’ve heard, on huge messes it took perhaps a year or two to completely fix. You don’t clean up a problem that took years to accumulate in a week. But even within a few months, it was clear to everybody that things were on the right track. Every one of these guys were extremely happy — to the point of recommending kanban for just about everything in the world.

Which, of course, is the problem. The same “disease” that caused folks to create cumbersome tracking and allocation systems in an effort to help defect teams can also cause successful defect teams to create systems that may or may not work for other folks. Beware over-generalization and premature optimization.

So no, there’s no magic potion, but as they say in the news business, a pattern of three makes a trend, which makes it newsworthy. I am putting this in my arsenal of suggestions for any type of team that has a situation that looks like this, including program-level defect teams, where this defect hell thing can drive everybody crazy.

Whatever it’s actual value for your particular situation, it’s an nice tool to have sitting in the tool-chest.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

E-Books and Pricing — is $99.99 Okay?

After writing up a small e-book for my wife (shameless plug: Best Hamburger Casserole Recipes rocks!) I decided this past week that I think I’m ready to actually become an e-book author.

Getting started, I found some things were easy to figure out and some things I don’t have a clue about. I’ll share them with you in case you decide to go down this road too. When I got to pricing, I was really surprised at my conclusion.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Managing Technology Means Being Wrong a lot

A friend yesterday twittered and posted into FaceBook a status update about Kanban and programming teams:

“list of electronic tools for lean and kanban teams http://bit.ly/6WW8cS #kanban”

(Kanban is a way of doing work where you use a board to show a “flow” of work and limit the number of activities in any one stage to a certain number)

To which a friend of his replied:

“Yeah, the whole idea of managing the pipeline in a structured way makes a lot of sense. In fact, strange as it sounds, I can see how you could apply the principles to a larger enterprise waterfall of iterative project[s]. You could use it to focus the team on the immediate pipeline…


Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

How to Really Measure Software Teams 3

Ever do the retrospective dance? You know the one, where at the end of the sprint everybody plays all the retrospective games: start-stop-continue, timeline, word-pong, or sprint-painting — and then nothing in your team actually changes? Maybe somebody takes notes, there’s an “action list”, you create new stories, or whatever, but the next sprint there you are with the same items all over again?

That’s a fun game, right?

Teams do this all the time. They’re really good at going through the motions of doing a retrospective — after all, everybody knows retrospectives are the most important part of agile — but they suck wind when it comes to actually improving themselves.

Makes you wonder: are these teams really agile?

There are all sorts of tests out there to tell if a team is “really” agile — the Nokia Test comes to mind as a popular example. Based on my experience, I have one simple rule for whether you’re an agile team or not: you have to be constantly improving through the use of an efficient feedback cycle.

If you are constantly improving, you can start with nothing and end up with a hyperperforming team. It might take a while, but it’ll happen. If you are not constantly improving, no matter how many of the rituals and behaviors you do, you’re never going to amount to anything.

Which gets us back to the retrospective dance.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.