Scrum Masters Should Be Cross-Functional

December 7th, 2010 Comments off

I have enjoyed a two day Certified Scrum Master course with Chet Hendrickson and Henrik Kniberg as teachers. A big part of the course was dedicated to questions and answers (implemented as a Scrum exercise) and lots of interesting subjects were elaborated upon by Chet and Henrik. I figured I’d document some of them on this blog, starting with this question:

“Should Scrum Masters code?”

Both Henrik and Chet agreed that the Scrum Master role may or may not be a full time job depending on several circumstances like team size, the maturity (in Scrum a sense) of the team, etc. In fact, a Scrum Master should strive for making her role redundant.

The Scrum Master is needed the most in the beginning, but once the worst impediments are removed and the team gets more comfortable with the process, the role becomes less important. At that point, the Scrum Master work load becomes unevenly distributed, and tends to be concentrated towards the beginning and end of the sprints. When that happens, you have basically two options:

Alternative 1: Make the Scrum Master role for this team a part time assignment.

Alternative 2: Keep the full time Scrum Master but have her or him participate in development activities when there’s time for that.

Of these two, the second one is much preferred, mostly because a “drop-in” Scrum Master will be less effective in discovering and removing impediments. So, in that perspective having a Scrum Master that is cross-functional seems like a good idea.

Categories: software development Tags:

I Have a New Employer

October 29th, 2010 Comments off

When I was young…er a friend of mine barged into a role playing session (Yes I was a nerd. Am.) with the following question: “Do you notice anything different about me?” He had his newly acquired driver’s license taped to his forehead…

I would do something similar now to mark an equally great change in my life, but  I haven’t figured out how to make my newly acquired employment stick to my forehead. So, here it is instead, in plain text:

I have gotten myself into consulting.

My new employer is Know IT, a fast growing Swedish IT company mainly targeting the Scandinavian IT sector.

I’m quite happy with the change. Although I enjoyed the seven years with my previous employer very much, I hope the new position will bring me diversity and professional growth.

If you’re thinking about changing your own work situation, but haven’t found the guts to do so, then I can recommend reading the inspiring post by Justin Etheredge. He, obviously a couple years ahead of me, quit consulting and started his own company. I can totally relate to that. But one step at a time, right?

Cheers!

Categories: Anouncements Tags:

Phone Agony

August 4th, 2010 Comments off

A year ago I began the process of replacing my Palm Treo with something, well, not so ancient. The choice was simple, then. Palm had just released Palm Pre, with a brand new operating system that breathed innovation and promised the best developer experience.

The phone hadn’t been released in Sweden (or Europe) yet so I waited. And waited. Then Palm got financial troubles and was sold to HP, while I – loosing faith – entered into a state of irresolution.

That was until a friend of mine showed me an app he purchased for his iPhone. It enabled him to point his device towards the night sky and get information of the stars and planets in view. Fantastic. Breathtaking. I had to get myself an iPhone.

Of course, that was before Chad Fowler moved to Android. Now what am I to do? I guess I should try and make an informed decision.

The requirements:

  • UMTS capable
  • Starmap or equivalent application
  • Fun to develop for

iPhone seems to have the best user experience, and integrates beautifully with other devices from apple. On the flip side is the vendor lock-in.

Android has Google Sky Map, not as good looking as Starmap on iPhone but the important  functionality seems to be there.

Developing for Android gives you several alternatives. iPhone, on the other hand, has only one allowed option. I can’t decide if having to learn Objective-C should be considered an advantage or disadvantage for iPhone.

I can’t seem to make up my mind between iPhone and Android. I’ll probably end up flipping a coin, so any input that can help me choose is much appreciated.

Cheers!

Categories: off-topic 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.

Cheers!

Generic Types are Litter

July 28th, 2010 2 comments

The short version of this post:

Do not spread generic types around. They are ugly and primitive.

Allow me to elaborate.

Generics are great

Before we got Generics (2004 in Java, 2005 in C#, and 2009 in Delphi) the way to enforce type safety on a collection type was to encapsulate it and use delegation.

class OrderList
{
private ArrayList items = new ArrayList();

public void Add(OrderItem item)
{
items.Add(item);
}

// Plus lots of more delegation code
// to implement Remove, foreach, etc.
}

Nowadays, we can construct our own type safe collection types with a single line of code.

List<OrderItem> orders = new List<OrderItem>();

That alone is good reason to love generics, and there lies the problem; many developers have come to love their generics a little too much.

Generics are ugly

The expressiveness of generics comes at a price, the price of syntactic noise. That’s natural. We must specify the parameterized types somehow, and the current syntax for doing so is probably as good as anything else.

Still, my feeling when I look at code with generics is that the constructed types don’t harmonize with the rest of the language. They kind of stand out, and are slightly negative for code readability.

OrderList orders = new OrderList();
// as compared to
List<OrderItem> orders = new List<OrderItem>();

This might not be so bad, but when we start to pass the constructed types around they become more and more like litter.

List<OrderItem> FetchOrders()
{
//…
}

double CalculateTotalSum(List<OrderItem> orders)
{
//…
}

void PrintOrders(List<OrderItem> orders)
{
//…
}

Besides being noisy, the constructed types expose implementation decisions. In our case the list of orders is implemented as a straight list. What if we found out that using a hash table implementation for performance reasons would be better? Then we’d have to change the declaration in all those places.

Dictionary<OrderItem, OrderItem> FetchOrders()
{
//…
}

double CalculateTotalSum(Dictionary<OrderItem, OrderItem> orders)
{
//…
}

void PrintOrders(Dictionary<OrderItem, OrderItem> orders)
{
//…
}

Comments redundant.

Generics are primitive

A related problem is that the constructed generic types encourage design that is more procedural than object-oriented. As an example, consider the CalculateTotalSum method again.

double CalculateTotalSum(List<OrderItem> orders)
{
//…
}

Clearly, this method belongs in the List<OrderItem> type. Ideally, we should be able to invoke it using the dot operator.

orders.TotalSum();
// instead of
CalculateTotalSum(orders);

But we cannot make that refactoring. We cannot add a TotalSum method to the List<OrderItem> type. (Well maybe we can if we make it an extension method, but I wouldn’t go there.) In that sense, constructed generic types are primitive types, closed and out of our control.

So we should hide them

Don’t get me wrong. I use generics a lot. But for the previously given reasons I do my best to hide them. I do that using the same encapsulation technique as before, or – at the very least – by inheriting the constructed types.

class OrderList : List&lt;OrderItem&gt;
{
double TotalSum()
{
//…
}
}

So, the rule I go by to mitigate the downsides of generics, is this:

Constructed types should always stay encapsulated. Never let them leak through any abstraction layers, be it methods, interfaces or cl

That is my view on Generics. What is yours?

Cheers!

P.S.

Just to be clear, the beef I have with Generics is with constructed types alone. I have nothing against using open generic types in public interfaces, although that is more likely to be a tool of library and framework developers.

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;
doSomething(si);

Into this?

doSomething((SomeInterface)someObject);

What about code like this?

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

Into this?

string someString = a &gt;= 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.

Cheers!

D Brush For SyntaxHighlighter

July 22nd, 2010 Comments off

I’ve been looking for a way to display prettier code snippets on this blog. The SyntaxHighlighter by Alex Gorbatchev, nicely packaged into a WordPress plugin by Viper007Bond, had what I was looking for.

I’ve been using the plugin for a couple of months now and I’m quite happy with it. The only problem, for me, has been that it doesn’t support The D Programming Language. Since I couldn’t find any on the internet, I decided to implement a D brush myself. (It’s quite simple.)

Following Viper’s advice I implemented the support as a tiny WordPress plugin. If you’re using SyntaxHighligher Evolved and want to be able to display syntax highlighted D code, feel free to download shBrushD from my new Shared Stuff page.

Cheers!

The Essence of Project Management

July 20th, 2010 Comments off

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.

Cheers!

Two Halves Make One Whole

July 17th, 2010 Comments off

I invested an hour watching a recorded speak by Martin Fowler and Neal Ford at some Paris convention. It was a well spent hour — as always with Martin Fowler — with some interesting angles on communication and feedback, and on why agile works. Especially the part regarding pair programming caught my attention.

According to Martin Fowler and his companion pair programming is an effective development practice because:

  1. We can only use one part of our brain at one time, and
  2. “The driver” and “the navigator” of a pair programming unit are using different parts of their brain and are thus complementing each other.

I have no idea if this is a proven truth, but it certainly conforms to my own experience with pair programming. The driver (the one with the keyboard) usually ends up in a state of completing-the-task-at-hand focus, while the navigator, a little more detached, makes bigger sweeps and thinks more on the big picture. For me pair programming has always resulted in better design, less bugs and a lot more fun.

If you want to watch for yourself, but don’t want to spend the full one hour, you’ll find the pair programming part 36:20 into the presentation.

Cheers!

Great Bug Reports

May 25th, 2010 Comments off

Is your team maintaining a bug report dump? When new issues get reported at a pace the team cannot keep up with it’s in trouble. At some point the team must yield and bug reports will start to pile up. The unattended bug reports lose their value over time and become a terrible waste.

Shallow Testing

There are many possible reasons for a bug tracking system to turn into a dump of wasted effort. One reason is when the testing team is practicing shallow testing. That is when the testers file bug reports right after discovering bugs, leaving any further investigation to the developing team. This is convenient for the testers but bad for the overall process of finding and fixing bugs.

The shallow testing technique results in many bug reports, most of them with poor quality. But the measure of effective testing is not how many bug reports it produces. What counts is the amount of bug reports that lead to bug fixes. To be effective we need great bug reports.

Great Bug Reports

So, what does a great bug report look like? We need to ask another question to answer that. What does the developer need to fix a bug? The first step of a successful bug elimination is to reproduce it in a controlled development environment.
In order to do that he needs to:

  1. Put the system in a state from which the error can be produced.
  2. Perform the actions that produce the error.
  3. Know how to identify the error.

Most bug reports contain enough information to make step 2 and 3 clear. Clues toward step 1, on the other hand, are usually missing. As a result the developers end up doing additional testing to pin down the problems.

If we do a better job with our bug reports we can get two really important effects. We help developers spend less time on each bug and instead fix more of them, and we increase the chance that the report will be acted upon. This is why thorough testing on behalf of the testing team is so important.

Focus On the Right Things

The basic formula to produce great bug reports is as follows.

  1. A descriptive name.
    The most important details of the bug presented in a sentence.
  2. Steps to reproduce.
    This is the part that distinguishes great bug reports from lesser ones. A well-described sequence of action steps that describes how to reproduce the bug removes uncertainties and signals thorough research. Developers are therefore more inclined to act upon such a bug report than a fuzzy one.
    It’s also important that the reproduction steps start at a known state, preferably at a clean program start.
  3. Expected results.
  4. Actual results.
  5. Any possibly relevant attachments, for example screen-shots and data.

Depending on the system you’re using, a multitude of additional parameters may be set to categorize the bug further. Provide the extra information if applicable, but it’s not essential so don’t let it steal focus from the basic formula.

Bug Mining

The foundation of a great bug report is built with great testing. Great testing is hard work and requires a special mindset: the love of bugs and the willingness to spend a lot of time examining each new specimen.

When a great tester discovers a bug the first thing she does is not to fire up the error reporting tool and start describing it. She leaves that for later. Instead she goes about to find the answers to these two questions:

  1. Can I reproduce this bug?
  2. If so, what is the smallest number of steps I need to do so?

This usually requires several program resets, attacking the bug from different angles. I like to call this process Bug Mining and it’s the tester’s most important task.

Why all the hard work?

Why should the tester have to do all this work, you might ask. After all, the developers introduced the bugs in the first place so they should clean up their own mess, right? Besides, isn’t it better if the testers spend their time testing and finding more bugs?

The problem is this: If the testers prioritize quantity over quality we’ll end up with a very ineffective test-correction-test cycle, and an ever growing mountain of unresolved bugs.

The more time developers spend on each bug the fewer bugs get corrected. And if fewer bugs get fixed, more time will pass between bug discovery and bug correction, making it even more expensive to fix.
Since the developers are the only ones that can make the bugs go away you really need to think twice before making them do work someone else can do just as well. This is especially true for Bug mining.

Guiding Principles

As a summary, here are some guiding principles to produce great bug reports:

  • Focus your effort on the steps to reproduce the bug. They should be clear, complete and as short as possible.
  • Only one bug per report.
    Handling several bugs as one is problematic for several reasons. For example, what should you do if the bug report contains bugs with different severity? Also, it’s difficult to describe several bugs in the name sentence so some might be overlooked. A third reason is the communication problem that happens when only some of the reported bugs get corrected.
  • A few really good bug reports is better than plenty of not so good ones. Quality is better than quantity when it comes to testing.

Cheers!