Agile Learning Labs

Kevin Thompson: "Deep Scrum"

We'd like to welcome Kevin Thompson's Deep Scrum to our blogroll. Why do we like Kevin's blog? Because of irreverent writing like this, from a post titled When Scrum is Too Much:

Let’s think about some examples of projects for which Scrum is not particularly useful.

I don’t use Scrum to make a cheese sandwich. I use a waterfall process, following a template devised long ago: I get out two pieces of bread, slice enough cheese for the filling, and assemble the sandwich.

I also don’t use Scrum to build a set piece for a play. Instead, I collaborate with as many other volunteers as we can reasonably use, and work on the piece until we have to quit for the day, or until it is done. After one or more work sessions, we finish the piece and move on to the next. This process is neither Scrum nor waterfall in nature, but bears more of a (rather vague) resemblance to Kanban.

So what do these examples tell us? Basically, they say that Scrum is much less useful when the work is thoroughly understood in advance, or when the delivery date is not specified, and not cyclic.

Long Live Lucky Oliver

On Wednesday, I'm doing a presentation on doing presentations. One of the little gems that I was looking forward to passing on was Lucky Oliver. It has been my favorite source for images for presentations and the web. The quality and variety of the images has been consistently great, and the prices were more than affordable. Today I discovered that Lucky Oliver will be closing down on May 15th. I'm sad to be losing this source for great photos, and sad to see the business fail. Best of luck to Bryan, and everyone else at Lucky Oliver.

Now where am I going to get my images? Any suggestions?

Cheers,

Chris

Agile Estimates, Release Planning, Sprints, and Kanban

Karl Scotland has an interesting post over on the Agile Practitioners Forum. He describes how and why his team moved to a Kanban system.

" The primary issue was that during Sprint planning, the development team were unable to accurately identify and estimate appropriate tasks"

I once led a team that built shrink-wrapped software using a modified version of Extreme Programming (XP). For this team, release planning played an import role in solving the problem Karl describes. The team modified the XP notion of 'stories' into something they called 'features'. We didn't have the 'Minimum Marketable Feature' terminology, but that was the idea.

At release planning time, we would discuss each feature until the group seemed satisfied that they understood what was involved. We would then estimate the size of the feature, as a group. Our units were 'Ideal Hours' and we limited our granularity to Fibonacci Numbers (...3, 5, 8, 13, 21, 34...). Each developer had a small deck of note cards with a single Fibonacci number on each. At the same time, we would each hold up the card with our estimate. Usually, we quickly had consensus.

When our estimates didn’t agree, we would dig deeper to find out why. Sometimes the feature need to be further clarified. Occasionally, one member knew of a technical hurdle or shortcut that the others did not. Other times the feature was too big to get our heads around and we would ask the product owner if it could be broken down into smaller sub-features, that would still be valuable.

The product owner developed a sense for which features were likely to be difficult for the group to estimate. Before the planning meeting, he would often seek out members of the development team and consult with them to confirm his suspicion and seek ways to better define or perhaps divide the feature. This helped minimize the number of times the team got stuck during release planning. The result was that release planning didn’t take long, and we walked out with a plan that each person understood and believed in.

When we planned a sprint, or an iteration, as we called them. We would have a developer own each feature. That developer would do their own estimate in terms of ideal hours for them. Since the feature had already be defined well enough for the team to make a consensus estimate at release planning, individuals usually felt that they had enough information and understanding to make their own personal estimate at iteration planning time. Letting the person who was going to be responsible to deliver the feature own the estimate allowed us to better plan the iterations by taking into account things like experience level, new information that had come to light, and so forth.

Both release planning and iteration planning went smoothly and produced useful estimates. The team maintained high morale and delivered a series of releases on time, feature-complete, with verifiably high quality.

Lunch With Joel Spolsky

I'm sitting in a Starbucks in the 'Multimedia Gulch' area of San Francisco, having just shared some fine San Francisco Burritos with Joel Spolsky. It's been a few years since we last chatted, and much has changed. Joel's company, Fog Creek Software, has more than doubled in size. They have mostly filled their recently expanded office space and Joel is busy figuring out how much space they should get to accommodate future growth. A new version of FogBugz has just been released and Joel is doing a demo tour. I think he still has space available in a few of his Bay Area demos. If you get a chance, check it out. I'll be there tomorrow morning in Mountain View.

We explored the question of how big can an engineering group get before it needs formal leadership and management structure. Fog Creek is still below the threshold. When I joined FactSet, we were just getting there. I remember fondly the time when all the projects where single-person affairs. It is a much more efficient way to work, as each person that gets added to the team adds exponentially to the communication overhead. OK, exponential is really more theoretical (think fully connected graph) than practical, but the point remains that as the team gets bigger, more time is spent communicating.

We posited that very often, a company bumps into the need for more 'management' or leadership when they take on the task of building the second product. While the company's original product may have evolved organically over time, starting as the brainchild and fruit of one person and growing head-count slowly, companies often try to accelerate the process with subsequent products. They have the bodies now, so they should be able to build out the product faster by assigning 10 or 20 people to the project from day one; right? Maybe, but such an effort takes leadership. Put 20 brilliant software developers in a room and tell them that the company needs them to build a snazzy new product and you will often get 20 radically different ideas about what that means how they should proceed. This is a perfect recipe for a bunch of thrashing, but not much progress toward a good product.

We sparred a bit over the value of agile development methods, especially Extreme Programming (XP), but that conversation quickly ended with us both agreeing that good teams can use such practices effectively and that dysfunctional teams can abuse them. In the end, it's the people that matter the most.

Joel On Software Stuff

I just read this rambling interview with Joel Spolsky, over at ACM Queue.

He mentions the early days of Joel on Software, even before he started Fog Creek Software. Back then he had a bit more time for writing, and created some essays that I still consider required reading. Examples include:

• Command and Conquer Management
• The Guerrilla Guide to Interviewing
• Painless Software Schedules
• Things You Should Never Do, Part 1
• Top Five (Wrong) Reasons You Don't Have Testers

Wait a minute! I’m basically giving you the links from his archive, starting at the bottom and working up! You can do that for yourself. Go to the archive, and start at the bottom. The old stuff is generally good and generally still relevant. I do have a personal soft spot for this one, if only because I was there for the birth. Joel shared the idea with me on May 30th, over lunch in New York City.

In the Queue article, he mentions evidence-based scheduling. The idea is very interesting and I’m going to make a point of picking his brain about it when he’s here. Oh yeah, Joel is coming to town in October. He has 4 demos scheduled in the San Francisco Bay area. They are free, but space is filling up quickly. Register here.

Speaking of techdirt...

I was recently invited by techdirt’s Mike Masnick to be a part of the Techdirt Insight Community. The idea is really interesting:

The Techdirt Insight Community is a service that lets a company engage a dynamic and diverse group of experts who provide analysis and insight tailored to meet your specific needs quickly and cost effectively. Our qualified community of expert bloggers tackles your issues through an interactive online conversation and quickly provides you with the answers you need to drive your business forward.

I’m looking forward to it!

Plug and Play

I just met with Shobeir Shobeiri and Kayvan Baroumand at Plug and Plug and Play Tech Center. It has been almost a year since I was there for techdirt greenhouse (one and two). The place has really come along. I think that they were hosting about 20 companies back then. Shobeir told me that they now house over ninety!

Complaints!

Heads up! The Chief Happiness Officer is urging people to complain at work. His point is that complaining in a constructive way can make the workplace better. Fair enough, but what if you are a new manager and you are the one listening to all of these complaints?

I once had a direct report that was constantly finding things to complain about. He was well-intentioned, smart, and one of the most productive engineers on the team. The things that he was complaining about were all things that could, in fact, stand some improvement. He thought that by pointing out everything that could use fixing, he was doing his part.

Next time he came to me with a complaint, I asked him what he thought could be done to improve the situation, and specifically what could he do to help implement a fix. He happily went into problem solving mode and generated several potential solutions. We then discussed the merits of each and compared the costs to the benefits. We chose a course of action and each of us committed to taking some specific actions to improve the situation. After that session, he almost always came armed with potential fixes to go along with his complaints.

It’s OK to complain. It is often much more useful to propose a solution, especially one that you are willing to implement.

The Soul of an Entrepreneur

Whether you're an aspiring entrepreneur yourself or just an entrevoyeur, there's much to be gleaned from the musings of a distinguished group of business adventurers over at My Way, The Entrepreneur Collective, which aggregates feeds from a dozen individual entrepreneurs' blogs.  Blogging here are some really superb and entertaining folk, including Tom Evslin, whose post Why A Great Programmer is Worth 50 Good Ones is a classic all managers should read, the always brilliant Chris Yeh, and Ben Casnocha, whose Business Rules of Thumb wiki is full of gems like this:

First-rate men hire first-rate men...second-rate men hire third-rate men...these third-rate men will then employ the bulk of your company's employees and they tend to select fourth-rate people. - Richard M. White. 

Here be much wisdom.

Welcome

to the Technical Management Institute blog.