Archive for the ‘project management’ Category

The First Rule of Holes

January 26th, 2011 7 comments

We don't have time for reevaluation. Keep digging!

At some point someone made a promise. Now the team is in a bad position and struggling hard to meet the deadlines of the original plan.

I’ve been in that position more than once, and as a Scrum Master I have used the same strategy:

  1. Working with the customer to lower expectations and make the plan more aligned with reality.
  2. Find more time for the team to do its work.

The second part would make me cancel everything not immediately helping the team accomplishing its short-term goals. The retrospective meetings were always the first thing that went out the window, and I felt like I was helping the team by doing it.

That was before the first rule of holes was brought to my attention (by Henrik Kniberg).

The first rule of holes: When you’re in one stop digging.

That wonderful quote by Molly Ivins really got me thinking. To bring a derailed train back on track, the solution is not to make the engines run faster. Instead we need to make a careful evaluation of the situation, and find solutions that will help us achieve the end goal of getting the passengers and cargo reach its destination on time.

In software development terms, when the going gets tough, we need our retrospectives the most.

Another way I’ve violated the first rule of holes is the thing I wrote about in my previous post. Although I know that automated tests is one of the best ways to increase productivity, I came up with all sorts of excuses why “it wasn’t for us”. So, I’ve let my teams dig deeper holes and making a bad situation worse.

Yet another common violation is the building up of technical debt. We’re so busy digging for new features that we forget that we have to be able to ascend from the pit. We need to stop digging and clean the small messes before they become drainers of effort.

What holes have you created or ended up in? What did you do about it? I’d love to hear your stories.


Categories: learning, project management Tags:

Martin Fowler: Agile Doesn’t Matter That Much

July 30th, 2010 4 comments

Martin Fowler has an interesting post up called Utility vs Strategic Dichotomy. The point he’s making is that there are essentially two kinds of software projects, which he names utility and strategic, and that they need to be treated entirely different in the way you staff and run them.

Utility projects, he defines, are the ones that provide functions that are often necessary and crucial to run the business, but not a differentiating factor in competition with other companies.

A classic example of a utility IT project is payroll, everyone needs it, but it’s something that most people want to ‘just work’

Then he delivers hammer blow number one.

“Another consequence is that only a few projects are strategic. The 80/20 rule applies, except it may be more like 95/5.”

What Martin Fowler is saying is that a vast majority of us are doing work that is of no strategic importance to the business we support. I’m sure this statement cuts a wound in many developer’s and project manager’s self images, mine included. But I’m with Martin on this one. It’s time our sector gets its feet back on the ground and we start to realize that we’re here to support the business. Not the other way around.

Hammer blow number two.

Another way the dichotomy makes its influence felt is the role of agile methods. Most agilists tend to come from a strategic mindset, and the flexibility and rapid time-to-market that characterizes agile is crucial for strategic projects. For utility projects, however, the advantages of agile don’t matter that much.

I have a little harder swallowing this one. That the agile movement doesn’t “matter that much” while developing utility systems doesn’t ring true to me. Yes, time to customer is not as critical as in strategic projects, but that doesn’t mean that building the right system isn’t important to utility projects as well. And the agile values will help reducing cost and risk in any project, be it utility or strategic.


The Boy Scout Rule

July 26th, 2010 4 comments

You may have heard of The Boy Scout Rule. (I hadn’t until I watched a recorded presentation by “Uncle Bob”.)

You should always leave the campground cleaner than you found it.

Applied to programming, it means we should have the ambition of always leaving the code cleaner than we found it. Sounds great, but before we set ourselves to the mission we might benefit from asking a couple of questions.

1. What is clean code?
2. When and what should we clean?

Clean Code

What is clean code? Wictionary defines it like so:

software code that is formatted correctly and in an organized manner so that another coder can easily read or modify it

That, by necessity, is a rather vague definition. The goal of being readable and modifiable to another programmer, although highly subjective, is pretty clear. But what is a correct format? What does an organised manner look like in code? Let’s see if we can make it a little more explicit.

Code Readability

The easiest way to mess up otherwise good code is to make it inconsistent. For me, it really doesn’t matter where we put brackets, if we use camelCase or PascalCase for variable names, spaces or tabs as indentations, etc. It’s when we mix the different styles that we end up with sloppy code.

Another way to make code difficult to take in is to make it compact. Just like any other type of text, code gets more readable if it contains some space.

Although the previous definition mentions nothing about it, good naming of methods, classes, variables, etc, is at the essence of readable code. Code with poorly named abstractions is not clean code.

Organized for Reusability

Formatting code is easy. Designing for readability, on the other hand, is harder. How do we organize the code so that it is easily read and modifiable?

One thing we know, is that long chunks of code is more difficult to read and harder to reuse. So, one goal should be to have small methods. But to what cost? For instance, should we refactor code like this?

SomeInterface si = (SomeInterface)someObject;

Into this?


What about code like this?

string someString;
if (a >= b)
  someString = “a is bigger or equal to b”;
  someString = “b is bigger”;

Into this?

string someString = a >= b ? “a is bigger or equal to b” : “b is bigger”;

In my opinion, the readability gains of the above refactorings are questionable. Better than reducing the number of rows in more or less clever ways, is to focus on improving abstractions.

Extract ’til you drop

Abstractions are things with names, like methods or classes. You use them to separate the whats from the hows. They are your best weapons in the fight for readability, reusability and flexibility.

A good way to improve abstractions in existing code is to extract methods from big methods, and classes from bulky classes. You can do this until there is nothing more to extract. As Robert C. Martin puts it, extract until you drop.

That leads me to my own definition of clean code.

• It is readable.
• It is consistent.
• It consists of fine grained, reusable abstractions with helpful names.

When to clean

Changing code is always associated with risk and “cleaning” is no exception. You could:

• Introduce bugs
• Cause build breaks
• Create merge conflicts

So, there are good reasons not to be carried away. A great enabling factor is how well your code is covered by automatic tests. Higher code coverage enables more brutal cleaning. A team with no automatic testing should be more careful, though, about what kind of cleaning they should do.

Also, to avoid annoying your fellow programmers it’s best to avoid sweeping changes that may result in check-in conflicts for others. Restrict your cleaning to the camp ground, the part of the code that you’re currently working on. Don’t venture out on forest-wide cleaning missions.

If the team does not share common coding rules, there’s a risk that you end up in “Curly Brace Wars”, or other religious software wars driven by team members’ individual preferences. This leads to inconsistency, annoyance and loss of energy. The only way to avoid it is to agree upon a common set of code rules.

With all that said, I have never imposed “cleaning” restrictions on my teams. They are allowed to do whatever refactorings they find necessary. If they are actively “cleaning” the code it means they care about quality, and that’s the way I like it. In the rare cases excessive cleaning cause problems, most teams will handle it and change their processes accordingly.


The Essence of Project Management

July 20th, 2010 No comments

I have a very simple philosophy when managing software development projects. It keeps me from derailing in this ever changing environment that is our craft. Regardless of whatever methodology and practices we currently use, I turn to these three questions for guidance.

  1. Is the team as productive as it can be?
  2. Is it doing the right things?
  3. Is it delivering on expectations?

To me those questions represent the essence of project management. Finding the answers, identifying the impediments and removing them are what I consider my most important tasks as a project manager; not to impose a particular methodology.

Productive teams

Good questions to ask while analyzing the productivity of a team might be:

  • Does the team contain the right people?
  • Is it getting rapid answers?
  • Is it getting quick feedback?
  • Is it optimized for long term or short term productivity?

In software development, the only measure of team productivity is its ability to produce working software. So if you want to maximize your team’s productivity you should focus on those capable of creating software. Make sure they can spend as much time as possible producing customer value.

For that reason, I think twice before I ask my developers to perform some compliance activity, like writing a report. It’s almost always better to have someone else do stuff like that. If I need information I can always ask, and if writing a report is necessary, I can collect the information and write the report myself. That way I contribute to keeping the team focused and productive, which is more important than to ease my own work load.

Monitoring the team’s productivity is an important task of the project manager. I do this mainly by being around the team a lot. Taking an interest in each individual’s working situation and task at hand is the best way to pick up problems and impediments.
Other important sources of information (although not as efficient as MBWA) are the daily meetings and iteration retrospective.

If you’re really lucky; with the right material and inspiring goals, the team jells and becomes hyper productive. That is every project manager’s dream, but few get to experience it.

Efficient teams

But being productive is not enough. What we really want is efficiency, and to be efficient you need to be both productive and produce the right things. Right in this sense means the right features, with the right quality, in the right order.

To eliminate the risk of producing wrong features you need to work closely with the customer. Make the feedback loop as short as possible, preferably by utilizing an onboard customer, or at least by holding regular review meetings.

Another thing you’d really want to do is to have the planned features prioritized. For some reason many customers (here in Sweden at least) are generally unwilling to do this for you.
“I decided what I want to include in the release, didn’t I? All those features are equally important.”

The problem with leaving priorities to the team is that the system will be developed in an arbitrary order, most likely with the easiest features first. While that may have a value in some situations, the downside is that it decreases the project’s chance of success. The reason is, that without customer value as the leading beacon, chances are that you’ll end up with a lot more bells and whistles than you can afford. And when you find that out it’ll be too late to rectify.

Dealing with expectations

How do you define project success? Here is one definition:

If the output is in line with what the customer expects, the project is successful.

The good thing with this definition is that it implies another variable to work with besides output, namely customer expectations. If the answer is yes to both questions 1 and 2 above, we know we are maximizing the output. But if that still isn’t good enough, we have only one option left. We must change the customer’s expectations, or fail.

Again, the best way to tune the customer expectations is a tight feedback loop. If the customer sees the progress regularely, she will adjust her expectations accordingly, or have a chance to react to reality. Either way, the chance for success increases.

Never lose focus on the end goal.


I am a ScrumBut

March 26th, 2010 No comments

Many organizations that are going agile are experiencing difficulties in applying the whole concept. Most of them yield and make some kind of adaption to better suit their current situation. Ken Schwaber, the father of Scrum, thinks this is just a way to avoid dealing with the true problems in the organization. He calls them “ScrumButs”.

In my organization we only fulfill two thirds of the Scrum Checklist, so I guess that makes us ScrumButs. I’m not going to feel bad about it though; Change takes time and we’re pretty happy we’ve gotten as far as we have. But Ken’s right, we really should do something about our most difficult problems and go the full ten yards. Maybe later. 🙂


APM Delivers Nothing

January 22nd, 2010 No comments

I’m reading Jim Highsmith’s book Agile Project Management. It’s a good book, as the frequent use of my marker pen shows, except for maybe this one sentence:

“APM reliably delivers innovative results to customers within cost and schedule constraints.”

Let me take that sentence out of its context and make a point I believe needs to be stressed. Software development methodologies (Agile Project Management in this case) delivers nothing! People, on the other hand, do.

Some years ago I developed a special interest in software development methodologies. Since then I’ve spent much time reading literature on Scrum, eXtreme Programming, etc, aiming to optimize the processes we use in our projects. During that time I’ve learned a lot, but also come to realize that I’ve been focusing too much on the wrong things.

In the past I thought the problems we were experiencing were problems with the methodology, an easy conclusion to draw from the propaganda-like information out there. However, I’ve found that the methodology matters little in comparison to the quality of my project team. Today I focus more on the team, the product, and the customer, and less on the latest within agile.

Thus, my formula for a successful project is this:

  • Spend less energy on the methodology; i.e. pick a simple one and adapt it when (and only when) needed, or stick to the one you’re currently using
  • Do more to get the right people
  • Make sure they are motivated and connected
  • If you think you’ll fail, do it fast


If we focus too much on the methodology, and give it too much importance, we risk loosing sight on the real goal, namely producing the right system. And for that you need the right people.


Tools of The Effective Developer: Rule of Three!

December 3rd, 2007 2 comments

I’m an impatient person, of the kind that are comfortable with making quick decisions on loose grounds, but prepared to change when more information gets available. This attitude has served me well, but also put me in trouble when important decisions were made too hastily. That’s why I always use The Rule of Three nowadays.

I first came across this version of The Rule of Three in Johanna Rothman and Esther Derby’s excellent book, Behind Closed Doors. The idea is to brainstorm solutions to a given problem, and not stop until you have at least three options to choose from. Listing the pros and cons of each solution helps you make a good decision.

With The Rule of Three I’m forced to think broader. I need to widen my view to find possible solutions other than the first that springs to mind. I’ve found that this process makes me explore the original solution better, and the risk of overlooking a good option is greatly reduced. Also, two different solutions can sometimes be combined into a new, even better one.

The Rule of Three can be applied in many ways, within a group or by yourself. It’s a cheap way to build better foundations for your decisions. That’s why I embrace The Rule of Three.

Previous posts in the Tools of The Effective Developer series:

  1. Tools of The Effective Developer: Personal Logs
  2. Tools of The Effective Developer: Personal Planning
  3. Tools of The Effective Developer: Programming By Intention
  4. Tools of The Effective Developer: Customer View
  5. Tools of The Effective Developer: Fail Fast!
  6. Tools of The Effective Developer: Make It Work – First!
  7. Tools of The Effective Developer: Whetstones

The Firepower of Teams

November 28th, 2007 4 comments

I just finished reading an interesting post by Ben Collins-Sussman. In an attempt to argue that distributed version control is not the silver bullet, he classifies us and puts us into two groups, which he calls the 80% and the 20%.

The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.

The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They’ve never used Linux, and aren’t very interested in it anyway. Many have never even used version control. If they have, it’s only whatever tool shipped in the Microsoft box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough to get their job done, then go home on the weekend and forget about computers.

Ben took a lot of heat for his oversimplification. People, it seems, don’t like to be categorized, a fact I too discovered when trying to make a distinction between Developers and Programmers. They especially don’t like to hear that they’re mediocre, not special, or less worth, which is the undertone of Ben’s 80% category.

During my military service I learned that statistically, only two soldiers in a group of eight would be effective in a combat situation. The rest would be pinned down, unable to return fire. Thus, one could say that the firepower of a squad comes from a fraction of it’s soldiers. I think this is often true for development teams as well. A few members are accountable for a majority of the produced value.

The funny thing is, that some of the best value-bringers I’ve met in my career does not fit the 20% alpha-geek group defined by Ben. And many of the “elite” programmers, the ones that do fit the description, have been remarkably inefficient. One reason for this could be that bleeding edge isn’t always the best strategy to achieve business value.

So, the question we should ask ourselves is not whether we’re in the 20%, it’s: Do I add to the firepower of my team? What can I do to bring more value?

Part time project engagement – no thanks!

August 20th, 2007 No comments

I am currently employed at a government owned, medium sized company. The company’s IT-division is struggling to satisfy the diverse needs of the other divisions, and is constantly undermanned. One clear indicator of this is multiple project engagement among developers. It has become the default state.
It’s understandable that management give in to the pressure and tries to squeeze the most out of its staff, but unfortunately it is counterproductive. It’s because the more goals you push onto someone, the less commitment he or she can put into each one. And as we all know: if commitment goes down, production goes down.

You form a project to achieve a specific goal, a goal you want to reach as soon as possible. So projects are all about focus, and you can not focus on more than one task at a time. It’s inevitable that you’ll lose time juggling projects. Thus, part time engagement makes projects move slower.

So, what to do? The same things you always do when resources are scarce: prioritize, divide and conquer. Always form teams that work full time on a single project. They will be more productive, and if you’re lucky they might even jell. Let the teams finish before you assign a new task. Instead, see to it that projects are small and can be completed within relatively short time. If a project swells and get big, find the smallest set of features that would still be useful, and form the project around that. Remember, the process of iteration can be applied at the project level too.

Project iteration has several advantages: it increases the closure frequency which helps keeping the teams performance rate high, it increases the chance of success for the individual project, and it releases something useful to the users sooner. And, it provides a constant stream of opportunities for you to make new strategical decisions based on small manageable projects.

To conclude this rather messy post: Don’t mess with my team, let us stay focused and finish what we have set out to do.

Is your team jelled?

August 13th, 2007 No comments

Do you work in a team that jell? Then you know the feeling that comes when the team starts to do everything right: solving problems before they even surface, finishing every iteration early, delivering high quality software – while having fun. That feeling is something you will never forget, and you should consider yourself extremely lucky to have experienced it. It’s very uncommon.

One cannot make every team jell. All you can do is provide the basic ingredients and hope for the magic to kick in. All teams in a jelled state have this in common:

  • A jelled team has a specific goal, a goal that is shared by all members.
  • All members of a jelled team have a high sense of responsibility and commitment.
  • All members of a jelled team feel they are accomplishing something of value.
  • All members of a jelled team take interest in each others work, since it’s part of their goal.
  • The members are enjoying themselves. They long to get to work to spend time together while moving the project forward. Laughter is frequent.
  • A jelled team has great communication: with customers, management and in between members.

As a project manager, if your team enters the jelled state you should step back and let the team dynamics do the work. Concentrate on keeping the team jelled, which most of the time is the same as doing nothing at all. Focus on protecting the team from unimportant external interference, and on stuff that boost the team’s confidence and wellbeing.

Appreciation and the sense of completion is very important to keep a team jelled for a long period of time. I once read (don’t remember where) about a team manager that hung a bell in the center of the workplace. The developers were instructed to ring the bell whenever they had done something good. It may sound silly but it’s actually one of the best ideas I’ve ever heard to boost team spirit. Whenever the bell rung people left whatever work they were doing to join the bell ringer and hear about his accomplishments. That team fed appreciation to itself, and provided a constant feeling of accomplishment.

So, how do you know if your team is jelled? Well, one way would be to hang such a bell in a strategic location. If the bell starts ringing on a regular basis chances are good that your team is jelled. If people also leave their workstations to cheer with the happy fellow – then you know for sure.