Recently I wrote a blog post on why software developers are typically so bad at estimation. I also gave a preview of the presentation that I am giving today to the Agile2010 conference on how to combat some of these problems by building range estimation techniques into a Scrum burndown. You can see that slide deck on slideshare.

To briefly recap, I pointed out that Agile team estimation and Planning Poker (or Scrum Poker) is great, but one big problem I have with it is the reliance on single point estimates in the burndown.

That’s why we have built range estimation into our Scrum Poker and burndowns at OpenSource Connections, and we find it to be more effective. By holding two cards instead of one, each team member is indicating a range estimate and communicating lot more about the risk and complexity that they see in that project.

So how does it work? In this blog post I’m going to describe how we do it using Google Spreadsheets.

How to build a burndown using ranges

Ingredients needed:

• Spreadsheet of any sort (I like google spreadsheets for easy sharing)
• Scrum Poker cards
• An engaged team!

Steps:

• Build a normal Scrum spreadsheet with a list of tasks on it.
• Estimate each task using Scrum poker. Have each participant hold up two cards to indicate the range of their estimate.
• The Scrummaster should encourage debate about the estimates when they vary widely in the size of the estimates or the width (ie risk) of the estimates.
• Once the team agrees on a range, the low and high values are entered in the spreadsheet.
• The spreadsheet calculates an estimate which is 2/3 of the way between the low and high estimate.
• Use the “2/3 estimate” as your ideal burndown to zero and to see how many tasks fit in your sprint.
• Use the low and high estimates as a band of reasonable deviation from the ideal burndown. They should both slope to zero at the same rate as the 2/3 estimate.
• Use the ranges to encourage more conservative adoption of tasks into a sprint, and to communicate risk and progress more clearly with customers.

In the end, we come up with a burndown similar to this, which represents the low and high estimates, and is a representation of the risk of the sprint or as a band of acceptable divergence from the estimate.

Make Google Spreadsheets (or Excel) do the Hard Work!

The next thing to show is how we represent this in a Scrum spreadsheet, and derive the formulas to build that pretty burndown. The vertical image is an example scrum spreadsheet like we use at OpenSource Connections, and the following sections will describe the major formulas being used in that spreadsheet.

This is a little tricky the first time, but then just copy the sheet from then on.

Low Estimate (D6-D8) and High Estimate (E6-E8) are entered by the team as they agree on estimates for each task in sprint planning.

Initial Estimate per task (F6-F8) is calculated by the spreadsheet, and is a single integer weighted 2/3 of the way from the low estimate to the high estimate:
F6 = (D6*0.33)+(E6*0.67)

2/3 Estimate (F2 and duplicated in F3) is just a sum of the initial estimates across all the tasks.
F3 = sum(F6:F8)

2/3 Estimate per day (G3-K3) is a calculated field, which decreases the estimate for each day down to zero by the end of the sprint. This provides the “ideal burndown” line for your chart at a 2/3 estimate.
G3 = F3-($F3/[Days in Sprint])
H3 = G3-($F3/[Days in Sprint]) … and so on

Low Estimate (F4) is a sum of all the low estimates: F4 = sum(D6:D8)

Low Estimate per day (G4-K4) is a calculated line showing the path down towards zero for our low estimates. It uses the slope of the 2/3 line.
G4 = IF((F4-($F3/[Days in Sprint]))>0,F4-($F3/[Days in Sprint]),0) … and so on

High Estimate (F5) is a sum: F5 = sum(E6:E8)

And High Estimate per day (G5-K5) is calculated similar to the low estimate per day:
G5 = F5-($F3/[Days in Sprint]) … and so on

Then developers update estimates each day as usual, and this makes the “Actual” line in the burndown.

That’s really all there is to it!

Once you’ve got your spreadsheet setup, you can just copy it from sprint to sprint, and then it really doesn’t take any more time in sprint planning to use ranges instead of single points. But using ranges with a 2/3 weighting like we do will help force your team to think a little more about the risk involved in their estimates and to estimate more conservatively. This allows you to better communicate with your customer and more reliably predict what you can commit to in a sprint.

Arin Sime is a Senior Consultant with OpenSource Connections, specializing in Agile process consulting, Solr search, and development consulting. You can follow Arin’s tweets at ArinSime

Recently I had a chance to speak about Agile with experienced IT professionals from the 2011 class of the UVa McIntire School of Commerce’s MS in Management of Information Technology. This was a particular pleasure for me since I graduated from the same program earlier this year as part of the 2010 class. My talk was an introduction to agile practices, and talking about the values inherent in an agile team. You can see the slides here:

http://www.slideshare.net/o19s/intro-to-agile-practices-and-values

The discussion covered a lot of overview topics in Agile, in fact too many topics to fit into our one hour time slot! But true to form, the students in the class were great – they asked a lot of questions and we had a very engaging two-way conversation. I much prefer being “agile” in my presentations and having to skip material because the audience is engaged. It’s a lot better than a command and control presentation where only the speaker is talking!

Among the many great conversations were two that I want to highlight on the blog.

Tip #1: Failing Fast does not mean sacrificing quality

Agile’s value comes in iterations

One of the big values of agile development methods is the emphasis on short, iterative development cycles. This allows you to push changes to the customer more often, get their feedback, and incorporate that feedback into future releases. Iterative development allows you to get some incremental value from your work right away, instead of waiting until the “big bang deployment” when all features have been completed and are all released at once. Big bangs are riskier because you haven’t received any customer feedback yet or seen how the customer will use your software.

Failing Fast means knowing what the customer really wants
In agile, we talk about “Failing Fast” because if a customer doesn’t like or doesn’t use a feature we are working on, we want to know that as soon as possible. That way we don’t expend any unnecessary effort on developing a feature that the customer will never use (also referred to in some cases as “gold plating”).

I like the term “Failing Fast”, but it’s important to understand (as one of the MSMIT students pointed out) that the failure we are willing to accept in agile is failure of the business value. In other words, if we are building something that doesn’t deliver the expected value to our customers or our business, we want to know about that failure sooner rather than later, so we can adjust to it.

Failure does not mean failure in the quality of the code.
Code we deploy in agile development methods should still be well tested (preferably using Test Driven Development methods and Continuous Integration), and we should be highly confident that what we are deploying will work as designed. We just aren’t confident yet if the customers will like what we have designed – and that is what we want to find out as soon as possible!

Tip #2: Avoiding Bad Standups

Another particularly interesting discussion we had was about what makes a good “standup.” Many teams believe they are agile because they have standup meetings. The reality is there’s a lot more to agile than daily standups, and if that’s all you’re doing, you’re probably not even doing the standup correctly in an agile way.

Basic rules to follow when conducting your standups

• Stand ups should be no more than 15 minutes.
• Each developer only discusses the three items (What did I do yesterday, What am I doing today, Am I encountering any obstacles)
• All other items of discussion should be taken off line after the stand up, and only involve interested parties, not the whole team.
• Product owners are always invited to the stand ups, but they should be a listener only. If they have questions they can bring them up with individual developers offline.
• As I saw posted on a discussion board recently, standups should be “by developers and for developers.” They should be run by developers, not project management or clients.

Make sure everyone on the team values the standups
One team lead in the class asked how rigidly I believe you should adhere to the 15 minute length. He said that his team is spread out remotely, and so this is often their only form of communication daily, and that their meetings are more typically 30 minutes, but that it seems to be going well.

My first question was “Who thinks it’s going well at 30 minutes? You as the team lead? Or have you asked your team?” I was intentionally being slightly confrontational to make sure he realized that the point of the stand up is developer communication, and to see if he had a true sense of what his developers thought of these daily meetings.

The pitfalls of standups “in name only”
Often times when the stand ups are run by traditional project managers, they quickly become long daily meetings, and the only person who actually likes them are the project managers or team leads. The developers are bored, get distracted and annoyed that they aren’t doing something more productive (like developing code!), and they tune out. Because they tune out, they aren’t even listening to what the other developers are saying, and they lose all benefit of the conversation. The conversation becomes a hierarchical conversation between each individual developer and the project manager running the meeting, not a conversation between developers.

Those type of “standups” lose their value because when developers aren’t talking to each other or paying attention, they will not offer to help remove obstacles for each other or offer advice. It becomes more of a traditional command and control situation and de-emphasizes the collaborative nature of productive Agile teams.

The particular team lead who asked the question was perhaps a bit taken aback by my response, and paused a moment to consider it. Ultimately he said that his team does also see value in the 30 minute daily standups, but I hope that my response gave him pause to consider if everyone really saw the same value in longer meetings that he does. It’s always worth asking your team!

Dealing with remote teams in a stand up

With remote teams, it’s understandable that you might have longer phone calls so people can socialize a little bit (just a little though please!). But in those cases, as I recommended to the team lead, at least still focus on keeping the stand up itself to only 15 minutes. If people want to stay on the line and discuss things for another 15 or 30 minutes, that’s fine.

But if you get the real standup done first within your 15 minute time limit, then at least those who are not interested in socialing or further discussing that day will feel free to leave the call. By incorporating more detailed discussions and socialization into the stand up itself, you are forcing everyone to stay around for the whole call every single day. And that is definitely not going to be efficient for everyone.

In conclusion…

It’s often said that you can understand the basic concepts of agile in a couple of days, but it takes a lifetime to master. The concepts of iterative development, failing fast, and stand ups really are pretty simple if you stick to a few simple rules. But if you don’t master the underlying values of why you are doing Agile, and trying to empower your whole team (not just project management!), then you will inevitably revert back to a control & command environment and lose the benefits of whatever agile practices remain.

I’m pleased to be doing some follow up agile process consulting work this week for one of the students’ teams. If OpenSource Connections can help you improve your adoption of agile, please don’t hesitate to contact us for a consultation!

The Agile CIO is a series of blog posts advising IT leaders on how best to incorporate Agile techniques into their organizations. For more information about OpenSource Connections’ Agile process consulting services, please contact the author at ASime@OpenSourceConnections.com.

Where are Eric and Youssef?

This year two OSC folks are working remotely for extended periods of time. Youssef spent 6 weeks in Lebanon earlier this year, and I am spending the month of July in the mountains of Western North Carolina. We had talked about some of the rewards as well as challenges of working effectively when you are in a new/fun/exciting/[insert superlative here] place. Youssef and I came up with a few tips to make balancing work/play easier!

Tip 1: Establish a Routine

Youssef says: There will be no shortage of distractions, specially during the World Cup season. A trip to the mountains, a music festival or a friend’s unannounced (or announced) visit are all good reasons to drop what you’re doing and enjoy the place you are in. The only way to both get your work done and have fun is to know when is the appropriate time for each. I found that establishing a routine worked best for me. I woke up early every morning and took advantage of the early quiet hours of the day. Started work at 8am and got plenty done early on. Then I gave myself a couple of hours of break time for unscheduled events (a friend’s visit, a trip to the store to get souvenirs, or even a couple of hours at the beach). Then I resumed work till the evening when I had a conference call scheduled every day at 5:45pm. After the call I was free to do whatever I wanted and that gave me plenty of time, specially in a city like Beirut that does not sleep.
Eric says: I know that I sometimes struggle to get started working in the morning. And being in the office makes it simpler because everyone else is working. So having a specific schedule of when I am working helps me shift my brain out of family/vacation mode and into work mode!
(more…)

Agile teams should be based on talented development staff with multi disclipinary skill sets. This allows team members to easily trade tasks and keep the iteration moving forward. As a consultant, I have seen and worked in many environments where development staff are very silo’d in their skill sets. In most cases they are very good at what they do, but at various times each team member can become a bottleneck because they are the only person who knows how to do a particular task or work on a certain legacy system.

But multi-disclipinary skill sets are not the only key to fluidly switching people between tasks. You must also be able to change technology or development environments easily as well, and this is an area that I find almost all development environments suffer from.

As an IT leader, when you bring in a team of consultants to augment your team and give their velocity a shot in the arm, you expect them to integrate quickly and be productive right away. And that’s what the consultant wants too. But are you giving them the tools they need to be effective right away? Or do you expect each of them to go through the same development environment setup that you ask new hires to do?

When you hire a new person, perhaps it’s worth the time to have them setup everything about their development environment. They learn about the nuances of your system, and a few days or a week of their time is nothing compared to the long term investment you expect from having them work for you for several years.

When you bring in a consultant, it’s different. You may only expect to have them for a few months, and their time is more expensive then your internal staff. And they are not going to benefit much from the learning experience of setting up a dev environment.

And even for your full time staff, what happens when they have to upgrade their machine a year from now, or their system dies and they have to rebuild from scratch? Do you really want to have them spend another week trying to remember how to get past that one install bug that they encountered a year or more before?

One answer to this problem is to develop code using virtual machines. Instead of having your first developer start by setting up the toolsets and plugins on their machine, have them start with a clean virtual image, using a tool like VMWare Player. Keep a bare bones image around with your basic development tools, or start with one from a similar project. After the developer gets the code started and everything basically working, then they should make a copy of that image and distribute it to the rest of the development team.

A backup copy of this image should also be kept on a network share or external drive so that when you add in consultants, or bring in a new hire, they can get started on code just as soon as they copy the image over to their machine. Instead of spending a week getting everything installed and picking the brain of your development staff, or Googling on obscure error messages, the only time delay is how long it takes the image to copy to their local machine (probably no more than an hour in most cases).

Now you can spend their time where it’s valuable: Bringing them up to speed on the nuances of your code itself, not the right service pack or magic incantations to get the development tools working.

You might be thinking that with cloud computing and languages like Ruby on Rails, shouldn’t this be a non issue? I just pull down the code from svn or github, and I’m ready to go! In my experience, while that is usually the case with relatively small projects or with projects started in the last year or two, it’s not always the case with lots of other code that exists in the world and that we have to work on.

I was reminded of this because of a client I recently worked with is still using version 1.1 of the .NET framework, and so is required to run Microsoft Visual Studio 2003. As part of the project we’ll probably end up doing an upgrade to more recent versions, but we still have work we have to do first. And unfortunately I discovered on my first day on the project that Windows 7 does not play well with Visual Studio 2003. Once it installed, it wouldn’t connect to IIS in debug mode. After doing some googling and seeing that this is a common problem with no easy solution (I tried many of the recommended solutions to no avail), I decided it was time to just get an image of Windows XP going. The rest of the dev team is on XP, but they are not using virtual machines to do it unfortunately.

So I started creating a new XP image under Virtual PC, only to have it started failing on certain files. Even though the install continued, I ended up with an image that could not talk to the outside world and was clearly half-baked.

So then I started over with VMWare Player, and as I write this, my XP image with Visual Studio 2003 already installed is nearly done. 3 days later. Before I start changing code on it, I’ll be setting the image aside to give to another consultant joining the team in a few weeks, so he doesn’t have to go to the same level of pain. I’ll also make sure the client has a copy of that image to make their life easier in the future the next time they bring us in or make a new hire.

Before you attribute the delays I experienced to Microsoft, I’ve seen similar challenges on Php projects and to a lesser degree on Groovy on Grails projects.

Virtualization is great for reducing the size of your server room, cutting down on power bills, and becoming more green. But don’t let it stop there. A little bit of time spent up front on virtualizing your development environment will save you a lot of heartache and expenses later down the road, and make your IT shop much more agile.

The Agile CIO is a series of blog posts advising IT leaders on how best to incorporate Agile techniques into their organizations. For more information about OpenSource Connections’ Agile process consulting services, please contact the author at ASime@OpenSourceConnections.com.

I’m looking forward to speaking next Tuesday night at AgileCville about range estimation in Scrum. It’s been a while since I’ve been able to attend AgileCville meetings regularly, so I’m excited to reconnect with everyone. I hope to see you there!

AgileCville
Date: Tuesday, June 15th, 2010
Time: 6 PM to 7:30 PM
Venue: OpenSpace
455 Second Street SE, Suite 100
Charlottesville, VA 22902

Its not exactly easy to get people to read requirement or technical specifications, much less write them. It’s also hard to get  developers to write tests. Its even harder to get them to write solid usable tests.

B.D.D (Behavior Driven Development) which is a spin off of T.D.D (Test Driven Development) focuses on the language of testing and and quality assurance of software, in hopes to make creating tests easier as well and specifications.

The concept was coined by Dan North. Since then new libraries like rspec, cumcumber, specflow, nbehave, machine spec have come about.

I can agree that sometimes changing the business language can help people with making associations and understanding of processes easier. And using “Behavior” instead of “test” does help in understanding that you need to validate how the software or code is supposed to behave.

Questioning The Boilerplate Human Readable Specifications

Where people need to be more skeptical is the question of is there real business value in getting code to generate boilerplate systematic specifications?

For an example, I’m pulling this from a cucumber example from github.

# language: en
Feature: Addition
  In order to avoid silly mistakes
  As a math idiot
  I want to be told the sum of two numbers

  Scenario Outline: Add two numbers
    Given I have entered <input_1> into the calculator
    And I have entered <input_2> into the calculator
    When I press <button>
    Then the result should be <output> on the screen

  Examples:
    | input_1 | input_2 | button | output |
    | 20      | 30      | add    | 50     |
    | 2       | 5       | add    | 7      |
    | 0       | 40      | add    | 40     |

We live in a time surrounded by constant news, media, following four subplots instead of one. Its hard to get people concentrate for long periods of time or sit still, much less to get them to read technical or requirement specifications.

Now I was to write this scenario for a requirement out as a spec, it would read like the following.

The mad scientist2 with his destructo calculator enters input 1
and input2. He manically presses said red button . The output
must be the sum of input 1 and input 2.

(i1 + i2 = output)

So why are we creating specifications that repeat words like I,As,When,Given,Then like bad boilerplate code? They might be human readable, but the questions of being understandable, easy to read, enticing to read, is a whole different story.

I have to honestly question that even if a developer takes their time and makes sure the code is up to spec. The question is are the specs kept up to day (requirements change). And are lay people going to want to sit through and actually read these things?

Is this a real business value?

I don’t see any at this point. I see no real return on time invested to write boring systematic specs and just to have them match up in some way with code.

Specifications, like any documentation worth it’s salt, needs to be able to:

• be engaging and appeal to more than the logical side.
• provide the meat of information that is digestible.
• avoid templating that read like government contracts.
• be terse and yet expressive.

We have been here before

Their have been tools like this before, (Fit, Finesse) before Dan North was really doing this thing. Yet you don’t see much usage from them across projects.

I think the reason why cucumber has caught on, is because the rails community has been keeping momentum from going from one “next big thing” onto the next one. Cucumber is the new pink.

But the end result is the same. Less than specular on par with boring. Hard to digest boiler plate specifications.

Don’t get me wrong, having specifications to work from is important. It helps to drive development and allows others to collaborate and work together. But this doesn’t mean B.D.D is on the right track with its story/QA methodology.

I think there is value of translating specs into code to some degree and testing against requirements.

I think the value is lost when:

• coders who might not fully understand the business are writing specs.
• business analysts who have no clue to code write specifications that affect how code is written.
• specs written  in a templated manner that is the antithesis of being terse.

Should vs Must

Also the domain language is for B.D.D. a bit off.

If you’ve read technical specs, you know there is a vital difference between “Should” and “Must”. Should is something software could do, but doesn’t have to. Must is an absolute requirement. If you don’t believe me, check out the W3 specs sometime.

Yet, we’ve chosen “should” for some reason to put everywhere inside of our “specification” code. If we’re going to write specifications, we must chose words that fit.

Conclusion

B.D.D. isn’t evil or bad, but still needs to evolve, be debated, thought on, expounded.

I think the software community as a whole needs to watch out from getting caught up too much in trends for the sake of being first to do something and buying the t-shirt to say he/she was there.

Last week was the crucial week on my current Lucene -> Solr project for making our goals.  A lot of work the previous couple of weeks came together.  I wanted to take a couple of minutes and just record some of the little things that I’ve been learning about:

Solr

Sunspot is the up and coming solution for integrating Solr into Ruby on Rails, and fortunately enough, the 1.0 release (followed quickly by 1.0.1!) has just come out last week.  Between acts_as_solr and Sunspot, Sunspot wins hands down for it’s support of a master/slave Solr configurations, embedded Solr for testing, richer indexing semantics, and not being tied to ActiveRecord.  The companion sunspot_rails gem does give wonderful ActiveRecord integration however.

Solr cores are the bees knees!  We’ve built a simple RoR webapp using HTTParty and the Solr API that allows you to perform all the admin functions for cores, and allows you to quickly clone a core for your own nefarious purposes!  Simplifies hacking around with a new schema or configuration without having a local copy of Solr running.  Allows multiple QA environments to potentially share a single Solr infrastructure.

Solr master and slave setup in a single VM.  While pointless from a scaling perspective, it’s a really great way to work out the kinks!  It’s funny to see a slave core polling the same Solr VM its in for updated segments!

JRuby

Doesn’t suck after all.  Actually, maybe I should say that JBoss, when combined with JRuby, means that JBoss doesn’t suck so much.  I had the aforementioned Solr core admin tool bundled up as a WAR file with JRuby, and was able to deploy it to an existing environment that had JBoss installed!  I didn’t have to install ruby on the box, (or JRuby for that matter!)  I just deployed the WAR file and bamn, off to the races.  Ops folks get the JBoss they love, I get the Ruby on Rails that I love.

And on a related note, Warbler was the key to thinking JRuby is cool.  I’d never actually had to package up a RoR app, so Warbler came to the rescue.  And you know what?  It was nice to build a single file that I knew had everything that I needed in it that could be scp’ed around!  And thanks to some cool code in the environment.rb, my app was able to load up the right configuration file for the environment based on an environmental variable set in JBoss.

Virtual Machines

I recently migrated a Linux VPS based RoR + Solr app (see a trend in tech choices )  to a Windows environment.  And to deliever the new Windows environment, I used VirtualBox to host the Windows Vista environment on my Mac laptop.

A couple of notes:

• VirtualBox may not have all the snazzy integration points of Parallels with the host computer like seamless application sharing, but it seems to be much lighter weight.  Starts up quicker, and I don’t get the spinning beach ball of death as much.
• If you are shipping a 11 GB file, you can’t use a 16 GB USB Memory Stick…  Turns out the biggest file is 4 GB.  (Although I never tried formatting the stick as NTFS, maybe that would have allowed a single 11 GB file???)
• Uploading 11 GB to a remote out on the internet server will take a long long long time.  Even on a really fast network. connection.
• If you need to format an external USB hard drive as NTFS on a Mac, it is possible!  Just fire up your trusty Windows Vista image in Parallels, plug the USB drive in, download and install the correct USB drivers so the drive doesn’t show up as a network share mapped to the Mac, and then use the built in reformatting tools!  Warning: This will take a loooong time!
• Lastly, if you are using VirtualBox, and you attempt to create a Windows XP machine, and attach a Windows Vista hard disk image to it, VirtualBox will let you!  And then Windows won’t start.  sigh.

Today, Microsoft announced that it was abandoning development of the FAST search engine for Linux and Unix.  Given that Microsoft paid $1.2 billion for FAST, the move is an apparent revelation of a strategy to get non-Windows based users to move to an enterprise Windows platform rather than to continue to support FAST.

This move seems to be risky.  The Microsoft bet is that its FAST customers are more loyal to FAST than they are the operating platform, and the perception of switching costs are higher for moving from FAST to another enterprise search engine rather than the opposite–a loyalty to the operating system and a perception that search engines are interchangeable.

Microsoft might be right for most of its customers, but this announcement will certainly be grist for the mill in IT departments over the coming weeks.  Many companies built their IT infrastructure around a Linux-based platform, and being forced to change to a Windows environment may be a pill that is too hard to swallow.  The alternative will be to look to other search engines, which can do nothing but help Solr and Lucene.  With an established user base, enterprise grade support packages from companies like Lucid Imagination, and a significantly lower total cost of ownership than the FAST + Windows package, Solr will appeal to many a CTO who might otherwise have continued to gladly pay the licensing costs for FAST but is now forced to reconsider his or her decision.

Rather than supporting FAST on both platforms at the cost of a few developers, Microsoft may lose many more customers and revenues because of its insistence on one platform.  It will be interesting to see how companies like Lucid respond to the new opportunity.