www.hans-eric.com

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

Summary

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.

Cheers!

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

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?

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.

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.