Archive for January, 2007

Is Earned Value Management valuable?

January 26, 2007

Eric Brown talks about Earned Value Management. I know that this is a respected practice recommended by the PMBOK amongst others. I have had more than my fair share of disagreements about the need to implement EVM.

I have one fundamental problem with EVM: it takes too long to track this information. I find that for the vast majority of projects that I or one of my PMs run, the team ends up tracking too much information for too little real benefit. I define benefit as the team delivering more working software features in production faster.

As Eric points out, one needs to track the following

1. Planned Work – What work is scheduled to be completed?
2. Cost Estimate for Planned Work – What is the cost estimate for the scheduled work?
3. Actual Work – What work has been completed?
4. Cost Estimate for Completed Work – What is the cost estimate for the work that has been completed?
5. Actual Costs – What costs have actually been incurred?
6. Variances – Cost difference, Schedule difference, Estimate Difference.

If you compare this to a Scrum burn-down chart, or a cumulative flow diagram, you’ll see there is a good deal of time that needs to be spent on overhead, instead of where management focus should be: identifying and removing constraints to the team delivering value. Also, I find this type of management information is too easily used (sometimes inadvertently) by the business to beat up IT on why variances between estimates and actuals are so large. What the business really cares about is seeing software features which they value working in production. Once you have a good idea of a team’s velocity, leave it at that. The velocity — or the number of features that you delivered last iteration — enables a good prediction of what will be delivered next iteration. Even if this does not work to plan, the business is generally very happy with getting a working set of features in production on time and within spec.

With the resources — be they money, manhours or a technical environment — you are using on implementing EVM, consider investing this in your team delivering software directly.

Technorati Tags: ,

Advertisements

CodeMonkey

January 25, 2007

VentureBlog has some great stuff to say about Jonathan Coulton and CodeMonkey and, as usual, he’s right. As he points out, Jonathon has marketed himself in a particularly successful and simple way: licensing himself Creative Commons license, then blogs about his fans’ music videos, their using it on slideshows, remixing it etc. He’s also got some cracking songs to listen to. More power to him.

How can you not like this?

“Code Monkey get up get coffee
Code Monkey go to job
Code Monkey have boring meeting
With boring manager Rob
Rob say Code Monkey very dilligent
But his output stink
His code not ”functional“ or ”elegant“
What do Code Monkey think?
Code Monkey think maybe manager want to write god damned login page himself
Code Monkey not say it out loud
Code Monkey not crazy, just proud

Code Monkey like Fritos
Code Monkey like Tab and Mountain Dew
Code Monkey very simple man
With big warm fuzzy secret heart:
Code Monkey like you”

Technorati Tags: ,

Why do we link in blog posts?

January 24, 2007

Douglas Galbi notes (or should that be motes?) in purple motes » unsocial non-networks that only 2% of blog posts link to other posts or have posts that link to them (via Telepocalypse). His interpretation is that blogging is less a social activity than a means of self-expression.

It’s pretty obvious that a simple way to get your blog more traffic is to have more links into it. After all, this is the way that PageRank works, and apart from Google just about every other search algorithm has some form of estimation of rank authority incorporated in it nowadays. In my head, I differentiate three types of post:

  • original content
  • tracking down and passing on original content
  • both — i.e. where the comments are also valuable

I like all three, but i like to know which I’m dealing with. I firmly believe that either of the first two will create more incoming links than the second, and a blog with plenty of original thought will create more valuable content, in turn getting more links.

I also note that different types of content go stale more quickly over time.

For instance, I blogged about the iPhone a couple of days after it came out. I got a few clicks from Technorati and other blog and search engines since I had tagged my post with iPhone. I’m pretty sure that there will be less clicks on the iPhone tag now that the buzz has died down. Some blogs that I read are almost solely concerned with what’s new, with posts whose value drops within a few days. I prefer blogs which take (relatively) old news but surround it with a good deal more thought. As an example, The Quest for Great Software has few posts and they are posted irregularly — once every one or two months. However, I read posts, the posts which they link to and then re-read the posts again. The posts that are there are so thoroughly saturated with good ideas, great thinking and links to other valuable content, it’s one of my favourite blogs.

Technorati Tags: ,

Don Park’s Daily Habit – Visual Security: 9-block IP Identification

January 23, 2007

Don Park’s Daily Habit – Visual Security: 9-block IP Identification is a cute readily identifiable figure (that he hesitantly called identicon) which he creates on the fly from a blog commenter’s IP address with the aim of reducing impersonations.

(via LinkBlog)

Technorati Tags:

Effective feedback

January 17, 2007

Let’s define effective feedback as information about a message that helps that the message produce the desired response.

People find it easiest to follow instructions that tell them what to do. Telling them what not to do leaves them with the burden of what to do. It’s a little harder for you to think what they should do instead of what they should not, but it’s dramatically more productive. Try it out: next time you are informing someone of what they you don’t want them to do, give them one or more examples of what you would like to see instead. Notice that little extra work you need to do and the result of you what you say. Sometimes the reason that the recipient of the feedback has not done this is that it’s a lot harder for them to think of alternatives that for you to. As you give successively more focussed feedback and they successively get closer to the desired response, it become easier for them to do so.

Leaving how to do it, but what to do instead, allows them to make the best choices in the domain in which they, not you, are more expert. Again, this is tougher, because it requires trust and investing in the relationship. Investing in the relationship often means doing so when times are toughest, e.g. when your back is against the wall and folks are making mistakes.

The response that a message produces can be partially correct. Great feedback pins down succinctly what worked so that it will continue to work next time. It also highlights what can be done in addition to get a response closer to that which is desired. These two elements can be combined a variety of ways:

  • Plus /delta: the plus says what works and the delta says what to do differently
  • 10/10: the first number says what works and how to get a 10 says what do differently
  • Keep / try: the keep says what to keep and the try says to do differently

Keep / try is a way of giving feedback that Alistair Cockburn mentions in his Crystal Clear: A Human-Powered Methodology for Small Teams. He uses it in his Reflection Workshops, short sessions held frequently to reinforce what works and to look at how to improve. In these workshops, he also recommends including a “problems” section allowing a least a little venting. Depending on who you have in your group this can be useful. It can also be very beneficial to get everyone to give feedback about what doesn’t work in the form of how to change.

Note: what is important here is for the team to get fluent in using one of other of these techniques. In the early stages, some will ‘get it’ and others still be explaining how badly their team members screwed up. In later stages, sincerity becomes steadily more important: it becomes facile for some to simply say “You did great but this is how you can do better”. This can open the door to a good deal of (justified) sarcasm. Instead, sincerity necessitates that team members really think through why they value the input from the rest of the team. A little goes a long way and leads to a virtuous circle: everyone leaning on everyone else.

Technorati Tags: , ,

Reducing waste by introducing testing earlier

January 17, 2007

I was browsing Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck & Tom Poppendieck, and found some great information about reducing waste. We have just started examining how we can improve our test processes as a way of introducing Test Driven Development. We have found two or three practices that remove most of our pain. Re-reading the book showed me that we have re-created some of the best practices that the Poppendiecks wrote about. Perhaps surprisingly, the practices are not about testing, but about development.
We have found that most elements of testing simply cannot wait until the end of the project or iteration. They need to be integrate much earlier. For instance, one legacy architecture is tightly coupled, not modular and with an amazing mountain of crippling ‘testing debt’, i.e. we have not built unit, functional or regression tests for the code. This means that more often that not, testing is the bottleneck around which we should plan, not development. In turn, this means that building a release plan around development estimates does not make sense: the critical path for our software lifecycle comes from testing. Therefore, we need our test manager involved in release planning.

Similarly, the earlier we can generate good tests of the software the faster we highlight and can fix bugs. The longer we leave these to fester throughout the development life-cycle the more damage they cause. Our ideal is making the user acceptance testing a verification rather than flushing out new bugs. We approximate RTY, the manufacturing measure of first time right by measuring how many features work without bugs in UAT. The goal is to drive this to 100%.

“According to Shigeo Shingo, there are two kinds of inspection: inspection after defects occur and inspection to prevent defects [See Shigeo Shingo, Study of ‘Toyota’ Production System, Productivity Press, 1981, Chapter 2.3]. If you really want quality, you don’t inspect after the fact, you control conditions so as not to allow defects in the first place. If this is not possible, then you inspect the product after each small step, so that defects are caught immediately after they occur. When a defect is found, you stop-the-line, find its cause, and fix it immediately.”

“The job of tests, and the people that develop and runs tests, is to prevent defects, not to find them. A quality assurance organization should champion processes that build quality into the code from the start rather than test quality in later. This is not to say that verification is unnecessary. Final verification is a good idea. It’s just that finding defects should be the exception, not the rule, during verification. If verification routinely triggers test-and-fix cycles, then the development process is defective.”

Technorati Tags: , , , , , ,

Where to find the books on this blog

January 17, 2007

You’ll find a few links to Amazon spread throughout this blog. Most links will take you to Amazon.com, unless the books aren’t available there in which case they’ll go to Amazon.co.uk, or wherever you can find them. The primary intention is to take you somewhere where you can get the books, not for me to get a cut — although I’m happy to if you are still paying the lowest price. If you know somewhere to get the books cheaper let me know.

Myself, I mostly use O’Reilly’s Safari Books Online. Safari lets you read and search just about any technical book you like. You pay a monthly subscription ranging from $10 to about $35 which gives you from 5 to 30 books respectively on a bookshelf. You can search books that are not on your bookshelf but only read about a page from them. The books stay on your bookshelf for a minimum of a month. You can also download chapters (for an extra subscription cost of $5 per month) and buy the books at a discount to list price. In my experience, you’re cheaper off going to Amazon.com to buy.

The search is really well done. Initially you get suggestions as you type, and then you’ll see all books that mention the search term. e.g. I can search for Xgrid and find a few sections and pages from completely disparate books. Browsing through them, I can add one or two to my bookshelf, and download a relevant chapter for offline reading too.

For me, this works well, since I enjoy dabbling in a range of technical subjects. The breadth of books is stunning. In addition, as you read online, Safari makes (pretty good) suggestions for other books that you might enjoy.

Technorati Tags: ,

Lean software development from concept to cash

January 17, 2007

Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck & Tom Poppendieck is one of my favourite books right now. The book is not a big selection of agile recipes you can apply to different situations, instead the Poppendiecks take us back to first principles. They show how these principles drive the different agile practice. Ultimately they demonstrate how to think about your software development and what it means to become more effective. If you have decided to embark on making software development better, then this book can help you choose what it most important and what to do about it. The authors cover a history of lean and the seven principles of lean software development, ripped from their first book (Lean Software Development). The meat of the book covers off value, waste, speed, people, knowledge, quality, partners, and the journey ahead.

A couple of things made the book different for me: firstly, it is a great mix of sage advice, first principles from the grandfathers of lean, real-life stories and practical exercises. Secondly, it really covers the full value stream from your first ideas about software to ringing up the sale.

Technorati Tags: , , ,

W h i t e s p a c e

January 15, 2007

A List Apart has a great article on Whitespace. Mark Boulton talks both about macro whitespace, or the space used on the page, and micro whitespace, or the space used in between letters. He also covers active and passive whitespace, and how the whitespace gives us the visual clues to determine whether a design is classy or down-market. Design is not what I do for a living — we have folks that are a whole lot more capable than myself at this, but I enjoy trying to analyse the results. Micro and macro white space provide some simple tools with which to explore the IYP world.

Have a look at our recent re-design of goudengids.nl:
200701150914-1

Macro whitespace is used to break up the page and my eyes are naturally drawn to the listings. Within the adverts themselves, the font is a little smaller to allow sufficient space between the lines, which makes the listings easier to read more at a glance. Overall, a clean design.

Compare this to telefoongids.nl:
200701150919-1

Maybe some of this is so messy because the site just doesn’t work on Mac OS X and Safari. You can see that they have chosen to use more graphical elements such as boxes to split up the listings. This does not work as well. The lack of micro whitespace means that the ads seem crowded.

Compare again to superpages.com:
200701150940

I find the macro whitespace acceptable: the ratings and reviews are broken out from the listings, although I think the sponsor columns is a little unbalanced. In the listings themselves I would have liked to have seem more use of whitespace to make them a lot more readable.

Technorati Tags: , ,

Success is less than just features

January 12, 2007

DancingMango says (correctly) that Success is more than just features. He uses the “DeLone and McLean model for Information Systems (IS) success [pdf].” to show that the benefits come from (what I would call) impacts, not the features themselves.

DeLone and McLean model for IS success.  Slightly modified.

What is not obvious from this explanation is that more often that not feature bloat or gold-plating code are major hygiene factors, i.e. they need to be removed and simplified in order to deliver system, information and service quality. If you like, you can think of a parallel input to quality: simplicity instead of features.

This is initially a hard idea to sell to the business: deliver more benefits by delivering less features. The customer often thinks it’s her job to increase the number of features. After all, agile is about increasing throughput, right? We all need to remember user-valued features working in production that is the important measure. Non-user-valued features or features that are hard to find detract from the quality of the system, information and service and dissatisfy the user.

Removing hygiene factors that dissatisfy is often a quicker way to benefits than increasing features to try to satisfy.

Technorati Tags: , , ,