Contents tagged with Agile

Mike Cohn is blogging

Sunday, June 24, 2007
Agile
No Comments

Or maybe I'm just slow on the uptake? I got word via Mountain Goat Software, Mike's company, that his blog Succeeding with Agile is now available. However there are posts there dating back to January. In any case, whether it's new or not, it's a blogger to read. Mike has always been there for me with little tidbits of extra info and sending me resources when I was swimming in Agile questions. He's an excellent speaker and I look foward to his blog entries, even if they're only going to be once a month (hey, he's a busy guy). Check it out and consider adding him to your blog roll as he's on of the key guys in Agile software today.
An attempt at working with eScrum

Friday, June 15, 2007
Agile
8 Comments

Okay, first off this tool wins the "Most Horrible Name Marketing Could Come Up With" award. I mean seriously, eScrum? Well, I guess when Scrum for Team System is taken what else do you do?

I took a look at eScrum but after an hour of configuration and various error messages I gave up. I'm the type that if I need to spend half a day to try something out, something that I kind-of already have, that's half a day wasted. I personally think most of the people out there that are saying this tool is "pretty nice" haven't actually installed it (or tried to install it).

So take this blog entry with a grain of salt as I didn't complete it to get to the finish line.

What is eScrum?
Anyways, eScrum is a web-based, end-to-end project management tool for Scrum built on top of TFS. It allows multiple ways to interact with your Scrum project:
- eScrum web-based UI
- TFS Team Explorer
- Excel
- MS Project
Like any Scrum tool, it offers a one-stop place for all Scrum artifacts like product backlogs, sprint backlogs, retrospectives, and those oh-so-cool burndown charts.

Installation is pretty painless. That is until you realize that you need a bevy of Microsoft technologies and tools installed in order to run eScrum. eScrum uses a variety of web and back-end technologies and you need to install of of them before getting your eScrum site up and running, although you can install them before or after eScrum, your choice.

You'll need to install:
- Microsoft .NET Framework v2.0 (well, duh)
- Microsoft Team Foundation Server and Microsoft Team Explorer
- ASP.NET 2.0 AJAX Extensions 1.0 and the AJAX Control Toolkit
- Anti Cross-Site Scripting Library
Once everything is installed hang on a second kids, there's still configuration to be done! eScrum is a bit of a pain to configure. Configuring eScrum is like installing Linux, there are a lot of steps and at any point you can really screw things up.

ASP.NET AJAX Control Toolkit Version Conflicts
Since the release site of the AJAX Control Toolkit does not allow download of previous versions and eScrum is compiled with a specific version, you may need to update the web.config file to allow automatic usage of a newer version of the AJAX Control Toolkit. eScrum has not been tested with newer versions, but may work well.
Add following XML to the eScrum web.config file after the </configSections> close tag. Afterward, update the newVersion attribute to the version of the control toolkit that you are using.

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="AjaxControlToolkit"
                publicKeyToken="28f01b0e84b6d53e"
                culture=”neutral”/>
            <bindingRedirect oldVersion="1.0.10301.0" newVersion="1.0.CHANGEME.0"/>
        </dependentAssembly>
    </assemblyBinding>
</runtime>

Setting up SharePoint Templates
Oh yeah, the fun still continues and we're still not finished. The eScrum TFS Template includes a team SharePoint portal template which gets installed when a new TFS Project is created with the eScrum template. The SharePoint templates must be added to the server before creating a TFS Project with the eScrum Process Template.
Deployment Steps. Follow these instructions to get this step done:
1. Log on to the target server
2. Open a command prompt and change directory to: <SystemDrive>\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN
3. Add the new templates using
4. Type IISRESET to reset IIS
Setting up an eScrum TFS Project
eScrum uses eScrum TFS Projects as a back end storage and management, so you won't be able to use it on existing projects. Once you have added the eScrum Process Template to your TFS server, you will need to create a new TFS Project using the eScrum Template.

First you'll need to get the templates uploaded via Team Explorer (or inside Visual Studio). Make sure you don't have even the Word document open while you're uploading the template or it will fail when it tries to create the zip file.

Once you've uploaded the templates and they're available, you need to create a project using the eScrum template:
1. In Team Explorer, right click your server and select "New Team Project…"
2. Name your project and use the eScrum template
3. Add yourself and your team members are all added to the Project Contributors (or Project Administrators, depending on your preference) security group.
Finally!
There are some other installs they want you to do and I suggest you follow the various installation and configuration guides but for my test this was good enough to get something up and running.

Now browse to where you installed it and you'll see something like this:

Creating Projects
eScrum is a little odd, but it seems to align to the Scrum process. Of course the thing with Scrum is that it's adaptable. There is no golden rule of how it works. There are guidelines and people generally follow them but for example in eScrum you must have a product. The eScrum project you create isn't good enough, it needs something actually called a "Product" (using the concept that multiple products form a project). I don't personally do Scrum that way so found it a little frustrating. The other frustrating thing when setting up a project (oh sorry, "product") was that I couldn't save it until I Product contributors were added (team members) and it wouldn't let me add team members until I created groups and that's where I stopped before my brain exploded.

Enough Configuring, I give up!
Yes, I gave up installing and configuring the beast as it was just too much. I mean, I'm all for tools and setting up websites but after an hour of screwing around (even though I knew what I was doing) I said enough was enough. Realistically, give yourself a half day (if you rush) or a full day with some testing to get this puppy up and running.

In fact, even after I had the template setup and a test project created I had no idea (other than through the Web UI) how to create a product? (which I couldn't do because of the security issues) It didn't look like I could create one in Team Explorer as all it would let me create was a bug, product details (but it needs a product first), sprint details, sprint retrospective, or a sprint task. WTF?

Yeah, the SharePoint Scrum Master was lost so either I'm an idiot (possible) or this tool isn't very intuitive, even for someone who thinks he knows what he's doing.

I wasn't going to go through the rest of the steps and who knows what else was needed, thus I wasn't able to get screenshots with projects configured and sprint backlog items, etc. I'll leave that for another soul to give up his day for.

I do however have some images for the various tabs so you can get a feel for what eScrum has to offer:

Product Page

Sprint Page

Daily Scrum Page

Retrospective Page

Bottom Line
Was it worth it? Was it worth all the installing and configuring and configuring and installing?

IMHO, no.

I'm very happy with Conchango's Scrum for Team System and hey, to install that I just had to upload a new process template from Team Explorer. No mess no fuss.

Once you do get the configuration and installation out of the way, eScrum looks interesting. It's got a nice dashboard for tracking your sprint, lets you keep on top of the daily Scrum electronically, and offers a bevy of Scrum reports like burndowns, metrics, and a product summary (none of which I have seen because I didn't take it that far when setting it up).

There are problems with the setup (even though I didn't finish). For example the SharePoint template contains entry into the Links list pointing to http://eScrum and http://eTools, none of which are correct so you have to fix this (and frankly, I don't even know what the eTools link is supposed to be). The SharePoint templates are just custom lists with a few extra fields, nothing special here. Even the logo for the site was broken in the template so it's obviously this is either rushed or nobody cares about the quality of presentation of the tool (and I wouldn't call this a 1.0 release).

Other things that immediately are a problem I had with this, you had to modify an XML config file every time you needed to add a project (and it's called a "Group" inside of the config file). Maybe you can do it through the web UI, but it looked to me like you had to modify this for each project.

I think for any kind of adoption, Microsoft needs to put together an installer for this as we don't all have a day to kill configuring a tool that should be seamless (after all, it's just a website and a TFS template remember). They also should have some documentation/guidance on this. From the looks of what I could get up and running there's very little actual "guidance" on using the tool and frankly, from the websites there's very little anything about this tool. Does MS think you install it (assuming you have the gumption to go through the entire process) and it'll just work and people will understand it? Even Scrum for Team System has nice documentation written on the process that goes along with the tool. Tools and technologies alone do not make for a good package.

If you want to use Scrum with TFS, stick to Conchango's Scrum For Team System template. It has it's own share of flaws but installs in about 5 minutes.
Extending the Notification Pattern Example

Monday, June 4, 2007
.NET Agile
6 Comments

Recently I've been looking at implementing the Notification pattern as described by Martin Fowler here. The UI calls methods on the domain to validate the data which is held in a Data Transfer Object (DTO). The DTO contains both the data needed by the class (for reconstituting domain objects) and a class for holding errors returned by the validation method. It's a nice way to remove managing errors in your domain layer but still have them available to your presentation layer.

One thing I've always found with Fowlers posts is that the code is very thin (and it should be since it's just an example) and sometimes not complete. So for you guys I decided to put together a working example based on his sample for checking a policy claim number. A couple of things I've done to go beyond the example on Martin's page are:
- Working solution file that compiles and runs (C# 2.0 although with slight modifications [removal of generics] it could work under 1.1)
- Implementation of the Model View Presenter pattern. Martin uses the Autonomous View approach in his sample because he's really focused on Notification, but I thought it would be nice to show it implemented with MVP. Autonomous View is a pattern for putting all presentation state and behavior for a window in a single class, but that really doesn't support a base approach that I prefer namely MVP and separation of concerns so the MVP pattern is here for completeness.
- Added Rhino mock tests to show how to test the presenter with a mocked out view. I thought this was important as the example is all about UI validation and this would be a good example to mock out a view using Rhino.
The Tests

It starts with the tests (it always starts with the tests). As I was re-implementing an example my tests were slighted a little bit towards how the sample worked. However I was focused on 3 main validations for the UI:
- Policy Number is present
- Claim Type is present
- Incident Date is present and valid (cannot be set in the future)
With those tests in mind, here's the check for the missing policy number (with mock setup and teardown):

   20 [SetUp]

   21 public void SetUp()

   22 {

   23     _mockery = new MockRepository();

   24     _view = _mockery.CreateMock<IRegisterClaimView>();

   25 }

   26

   27 [TearDown]

   28 public void TearDown()

   29 {

   30     _mockery.VerifyAll();

   31 }

   32

   33 [Test]

   34 public void MissingPolicyNumber()

   35 {

   36     Expect.Call(_view.PolicyNumber).Return(INVALID_POLICY_NUMBER);

   37     Expect.Call(_view.IncidentDate).Return(VALID_INCIDENT_DATE);

   38     Expect.Call(_view.ClaimType).Return(VALID_CLAIM_TYPE);

   39     _view.ResponseMessage = "Not registered, see errors";

   40     _view.SetError("txtPolicyNumber", "Policy number is missing");

   41     _mockery.ReplayAll();

   42

   43     RegisterClaimPresenter presenter = new RegisterClaimPresenter(_view);

   44     presenter.RegisterClaim();

   45 }

The constants are defined so it's easier to read and are defined like this:

   13 private const string INVALID_POLICY_NUMBER = "";

   14 private const string VALID_POLICY_NUMBER = "1";

   15 private const string INVALID_CLAIM_TYPE = "";

   16 private const string VALID_CLAIM_TYPE = "1";

   17 private static readonly DateTime INVALID_INCIDENT_DATE = DateTime.MinValue;

   18 private static readonly DateTime VALID_INCIDENT_DATE = DateTime.Now.AddDays(1);

The view is mocked out (which is what we're testing) so we expect calling the 3 properties of the view (that match up to the UI). There's also a ResponseMessage property which displayed if there are errors or not. The SetError method needs a bit of explaining.

In Martins example, he uses Autonomous View which is great and the way he resolves what control is causing what error it's easy to wire up. All the controls are there for the picking. When I implemented the MVP pattern I had a bit of a problem. I wasn't about to pollute my presenter with controls from the UI (otherwise it would be easy) so how could I get the view to wire up the right error message to the right control. The only way I could do it (in the implemenation of the view) was to pass in the control name as a string. Then in my view implementation I did this:

  115 public void SetError(string controlName, string errorMessage)

  116 {

  117     Control control = Controls[controlName];

  118     showError(control, errorMessage);

  119 }

Then showError just handles setting the error via the built-in .NET error provider:

   37 void showError(Control arg, string message)

   38 {

   39     _errorProvider.SetError(arg, message);

   40 }

Once I had the missing policy test working it was time to move onto the other requirements. MissingIncidentType and MissingIncidentDate are both the same (except there's no such thing as a null DateTime so I cheated a bit and returned DateTime.MinValue). The other check against the Incident Date is to ensure it's not set before the policy date. Since we don't have a policy screen I just stubbed it out in a stub Policy class and set it to the current date. So an invalid date would be something set in the past:

   76 [Test]

   77 public void CheckDateBeforePolicyStart()

   78 {

   79     Expect.Call(_view.PolicyNumber).Return(VALID_POLICY_NUMBER);

   80     Expect.Call(_view.ClaimType).Return(VALID_CLAIM_TYPE);

   81     Expect.Call(_view.IncidentDate).Return(VALID_INCIDENT_DATE.AddDays(-1));

   82     _view.ResponseMessage = "Not registered, see errors";

   83     _view.SetError("pkIncidentDate", "Incident Date is before we started doing this business");

   84     _mockery.ReplayAll();

   85

   86     RegisterClaimPresenter presenter = new RegisterClaimPresenter(_view);

   87     presenter.RegisterClaim();

   88 }

The presenter is pretty basic. In addition to just registering the view and talking to it, it has one main method called by the view (when the user clicks the submit button) called RegisterClaim. Here it is:

   25 public void RegisterClaim()

   26         {

   27             saveToClaim();

   28             _service.RegisterClaim(_claim);

   29             if(_claim.Notification.HasErrors)

   30             {

   31                 _view.ResponseMessage = "Not registered, see errors";

   32                 indicateErrors();

   33             }

   34             else

   35             {

   36                 _view.ResponseMessage = "Registration Succeeded";

   37             }

   38         }

Basically it calls saveToClaim (below) then calls a service layer method to register the claim. Information is stored in a Data Transfer Object which contains both the data from the view and any errors. The claim DTO has a Notification object which has errors (or not) and the presenter will tell the view if there are any problems, letting the view set the display accordingly.

First here's the saveToClaim method in the presenter that will create a RegisterClaimDTO and populate it with information from the view:

   67 private void saveToClaim()

   68 {

   69     _claim = new RegisterClaimDTO();

   70     _claim.PolicyId = _view.PolicyNumber;

   71     _claim.IncidentDate = _view.IncidentDate;

   72     _claim.Type = _view.ClaimType;

   73 }

The RegisterClaim method on the ClaimService object will just run it's own command (which does the actual registration of the claim and checks for any errors). The core part of the validation is in the Validate method on the RegisterClaim object:

   39 private void Validate()

   40 {

   41     failIfNullOrBlank(((RegisterClaimDTO)Data).PolicyId, RegisterClaimDTO.MISSING_POLICY_NUMBER);

   42     failIfNullOrBlank(((RegisterClaimDTO)Data).Type, RegisterClaimDTO.MISSING_INCIDENT_TYPE);

   43     fail(((RegisterClaimDTO)Data).IncidentDate == RegisterClaimDTO.BLANK_DATE, RegisterClaimDTO.MISSING_INCIDENT_DATE);

   44     if (isNullOrBlank(((RegisterClaimDTO)Data).PolicyId))

   45         return;

   46     Policy policy = FindPolicy(((RegisterClaimDTO)Data).PolicyId);

   47     if (policy == null)

   48     {

   49         Notification.Errors.Add(RegisterClaimDTO.UNKNOWN_POLICY_NUMBER);

   50     }

   51     else

   52     {

   53         fail((((RegisterClaimDTO)Data).IncidentDate.CompareTo(policy.InceptionDate) < 0),

   54             RegisterClaimDTO.DATE_BEFORE_POLICY_START);

   55     }

   56 }

Here it checks the various business rules and then uses the Notification object to keep track of errors. The Notification object is an object embedded in the Data Transfer Object, which is passed into the service when it's created so our service layer has access to the DTO to register errors as it does it's validation.

Finally coming back from the service layer, the presenter checks to see if the DTO's Notification object HasErrors. If it does, it sets the response message (mapped to a textbox in the UI) and calls a method called indicateErrors. This just runs through each error object in the DTO through a method to check the error:

   44 private void indicateErrors()

   45 {

   46     checkError(RegisterClaimDTO.MISSING_POLICY_NUMBER);

   47     checkError(RegisterClaimDTO.MISSING_INCIDENT_TYPE);

   48     checkError(RegisterClaimDTO.DATE_BEFORE_POLICY_START);

   49     checkError(RegisterClaimDTO.MISSING_INCIDENT_DATE);

   50 }

checkError is a method that takes in the Error object which contains both the error message and the control it belongs to. If the Notification list contains the error it's checking, it then calls that ugly SetError method on the view. This will update the UI with the appropiate error message attached to the correct control:

   56 private void checkError(Error error)

   57 {

   58     if (_claim.Notification.IncludesError(error))

   59     {

   60         _view.SetError(error.ControlName, error.ToString());

   61     }

   62 }

And that's about it. It's fairly simple but the sample has been broken down a bit further hopefully to help you understand the pattern better.

Here's the class diagram for all the classes in the system:

And here's how the classes break down in the solution. Each folder would be a layer in your application (or split across multiple assemblies):

Application Layer
RegisterClaim.cs
ServerCommand.cs

Domain Layer
Policy.cs

Presentation Layer
FrmRegisterClaim.cs
IRegisterClaimView.cs
Program.cs
RegisterClaimPresenter.cs

Service Layer
ClaimService.cs
DataTransferObject.cs
Error.cs
Notification.cs
RegisterClaimDTO.cs

So other than the ugly SetError method which takes in a string for a control name, I think this isn't bad. Maybe someone has a suggestion out there how to get rid of the control name string but like I said, I didn't want to introduce UI controls into my presenter so I'm not sure (other than maybe an enumeration) how to hook up the right error message with the right control. Feel free to offer a suggestion for improvement here.

You can download the entire solution with source code here. Enjoy!
Scrum for SharePoint

Thursday, May 17, 2007
Agile Scrum SharePoint
1 Comment

Agile teams are all about co-location and communication. We have a wall where tasks are posted. The wall is life. It is the source of truth. From the wall, the ScrumMaster (me generally) enters in the hours remaining for tasks and updates some backend system (in our case, VSTS with the Scrum For Team System templates).

There are many tools out there to do Scrum, XP, etc. and keep track of your items. I think I did a round up of the tools out there but I missed one. SharePoint. Yup, my two favorite topics, SharePoint and Agile, come together.

A friend pointed me to an article on Redmond Developer News (a new feed I didn't even know about and one that looks pretty cool) by David Christiansen called Building a Virtual Bullpen with Microsoft SharePoint. Basically he walks you through creating a digital bullpen, complete with product backlogs and sprint backlogs all powered by SharePoint. And easy to do, with a few custom views and all standard web parts and controls.

I remember Scott Hanselmen mentioning that they used SharePoint for Scrum awhile back on an episode of Hanselminutes. He said it worked well for them. I've setup clients using standard out-of-the-box lists to track Product Backlog items and such. The only thing 2003 won't give you are burndown charts. With Excel Services, a little bit of magic, and MOSS 2007 behind the scenes this now becomes a simple reality.

Check out the article to get your virtual bullpen setup and drop me a line if you need a hand (or just want to share with the rest of the class).
A Scrum by any other name...

Wednesday, May 16, 2007
Agile Scrum
3 Comments

I'm not getting it. I'm seeing a lot of posts about "Feature Driven Development" (or FDD for short) but I'm just not getting it. All I see is Scrum with different terminology. I was reading the Igloo Boy's blog where he's off at DevTeach 2007 (man I'm so jealous, Montreal in the summer time with geeks) and he posted his review of a FDD session with Joel Semeniuk and I just don't see the bru-ha-ha about FDD.

Definition
FDD is defined as a process defined and proven to deliver frequent, tangible, working results repeatedly. In other words, what we try to achieve when using Scrum in software development.

Characteristics
FDD characteristics include minimum overhead and disruption, Delivers frequent, tangible, working results, Emphasizes quality at each step, Highly iterative. Again, Scrum on all fronts.

Features
FDD centers around working on features (Product Backlog Items in Scrum) which have a naming convention like:

<action> the <result> <by|for|of|to> a/an <object>

Like user stories where:

As a/an <role> I would like to <action> so that <business benefit>

Feature Sets
FDD Feature Sets is a grouping of features that are combined in a business sense. In Scrum we've called those Themes.

So am I way off base here or are we just putting lipstick on a pig? Are we just packaging up Scrum with a different name in order to sell it better? Wikipedia lists FDD as an iterative and incremental software development process and a member of the Agile methods for software delivery (which includes Scrum, XP, etc.).

There are differences here between Scrum and FDD, like reports being more detailed than a burndown chart (however for me, a burndown chart was more than enough information to know where we were and where we're headed). Practices include Domain Object Modelling (DDD?) and teams centered around Fetures, but again this is just (to me) just Scrum organized a certain way. I would hazard to say I already do FDD because to me it's all about the domain and business value.

Or maybe this is a more refined take on Scrum. Scrum with some more rigor around focusing on the goal? A rose by any other name... I must be missing something here.
Read it, live it, love it!

Wednesday, May 16, 2007
Agile
No Comments

If you're struggling with getting in touch to deliver what your customers really want, try this. To me, this is what Agile is all about.

Print out the big version of this (available here), put it up on your wall (in your face) and read it every morning before you start. Really.

Hugh is brilliant.
Have you tried out Planning Poker?

Friday, May 11, 2007
Agile Cool Tools
No Comments

I'm a big fan of the Planning Poker technique for estimating. It basically is a process where everyone in the room gets together with cards and estimates effort for user stories. Each card has a number on it (a modified fibinacci sequence) of 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. Then everyone reveals their estimate for a given story at the same time. Any estimates on the fringe are challenged and justified and an estimate is arrived, then the process is repeated for the next user story.

Mike Cohn and the Mountain Goat Software people have put together a fabulous website to solve a problem with planning poker, that is the one of remote users. It doesn't help planning poker if the users are off in another city so planning poker, the site solves that. You create an account (free and only requires 4 fields of information) and log in. Then someone creates a game and everyone participates online. Its a great way of doing this, and you can export the results to HTML and CSV at the end of the session. There's even a 2 minute timer that you can invoke once you've discussed enough about a story and a ready to estimate. Some people have even used it internally by everyone bringing their laptops to the session rather than even using physical cards.

So check out Planning Poker for yourself as it might be useful in your next planning session. Here are some screenshots that walk you though creating user stories and estimating them with the planning poker site.

When you log into the site you can view the active or complete games. Complete games can be re-opened if you need to do them across a few days:

To create a new game, click on the link and fill in the name and description. If you have stories already ready to estimate, you can paste them into the field here from a spreadsheet. The first row should contain the field names.

To add a story for estimating, just enter it in the form As a/an <role>, I would like to <function> so that <business value>. There's also room for notes that might be something you want to capture but make it light, this isn't the place for requirements gathering details here.

Once you've added a story, the estimating game begins. Select a card from the screen for that story.

Then you can accept or play again with that estimate. Your estimate shows up along with others (if they're logged into your game).

If you were wrong with your original estimate or there's debate on something and you really do agree it's larger/smaller, click play again and select a different estimate.

When all the estimates are done and the game is complete you can view all of the estimates online.

Finally if you want to take this information elsewhere, you can export it HTML for viewing/publishing/display or to a CSV file for importing into another tool.

Note that Planning Poker doesn't work very well under IE7 on Windows XP but the guys are working on it. I flipped over to use Firefox for the screenshots and use FF when I do my sessions using the tool.
6 Months of Sprints - A Visual Record

Monday, May 7, 2007
Agile
1 Comment

I thought I would start off the week by airing my dirty laundry, that laundry being one of the projects I'm Scrum Master and Architect on.
It's been 6 months of month long iterations and the project is currently on hold as we shifted resources around to a fewer "higher" priority ones. I'm looking back at the iterations and the burndown charts that we pulled out (via Scrum for Team System).
It's not pretty but it's real and it's interesting to see the progress (or sometimes lack of it) along the way. Here we go...
Sprint 1

The sprint starts and we're not off to a bad start. In fact, it's one of the better sprints we had, even if it was the first. A little bit of churn the first few days but that's normal. In fact it was a collision between myself and the PM who decided to enter all the tasks again his way. After a few days we got that part straightended out and the rest of the sprint seemed to go pretty well. I was pretty happy so far.
Sprint 2

Another sprint that didn't go too badly. The team (myself and one developer) had some momentum and we were moving along at a nice pace. However technical debt built up already and we ended the sprint with about 40 hours of work left. Still overall I was pretty happy and we seemed to have got our stride. We also picked up a new team member so there was that integration that had to happen, but it worked well for the team.
Sprint 3

Third sprint, 3 months into the project and we were moving along. Sometime around the middle of the sprint we were going like gangbusters and realized we were going to end early. That's the big dip around the 17-20th of November 2006. Once we got back on the Monday (the 20th) we decided to add more work to the sprint, otherwise we were going to be twiddling our thumbs for 2 weeks. It worked out well for this sprint as we finished without too much overhead (about 12 hours but some of that was BA or QA work which didn't directly affect the project).
Sprint 4

Ugh. This is ugly but bonus points for the first person to know why (other than who was on the team). The main cause for the burndown to go flatline here is the Christmas. Yup, with people on holidays and not really wanting to end the sprint in early January right when everyone got back, we decided to push the sprint out a little to make up for the lost time over the Christmas season. In addition to this, the first week of this sprint one of the main developers came down with the flu and was out of commission for almost a whole week. That crippled us. By the 22nd or 23rd of January we decided we had to drop a whack of scope from the sprint (which is the sudden drop at the end you see) and we would have to make it up the next sprint, somehow. Even with that adjustment we were still running about 225 hours over at the end of the sprint. Not a good place to be to start your next iteration.
Sprint 5

Doesn't look good for the team that was doing so well. This sprint started off with a couple of hundred hours of deferred backlog items, then ballooned up with more technical debt and decomposition of new tasks. The team was larger now but we obviously took on more than we could chew. In fact I remember going in saying that but I was shot down by certain PTB that said "it'll work itself out". Don't believe them! If your burndown charts are looking like this the first week in (and you can tell that the first week in) you'll certain to not succeed on an iteration. Hands down. I like to take a CSI approach to iterations, let the facts show what's going on not peoples opinion. If your burndown is burning up, you need to make adjustments and not "ride it out" because unless you have magical coding elves come in late at night (and I'm not talking about geeky coders who like to keep odd hours) then you're not going to make it, and it's pretty obvious.
Sprint 6
This sprint was just a death march. 800 hours of work which included 80 hours for a task we outsourced to a different group (which really turned into 200 hours of work as that person just didn't turn in any kind of idea for how long it would take) and probably 200 hours of technical debt that's been building for 4 months. We actually got a lot done this sprint, about 200 hours worth of work which isn't bad for 3 developers, 1 QA, and 1 BA but it looks bad here.
This is how we ended the project until it went stealth. No, we didn't shut the project down because the progress was horrible. As I said, it slipped down the priority chain and we, as an organization, felt it was better to staff a project with 4-6 developers and bring it home rather than 2-3 developers keeping it on life support.
Hopefully this reality trip was fun for you and might seed a few things in your own iterations. Overall a few things to keep in mind on your own projects following Scrum:
- No matter what tool you use, try to get some kind of burndown out of the progress (even if it's being drawn on a whiteboard). It's invaluable to know early on in a sprint what is going on and where things are headed.
- If you finish a sprint with backlog items, make sure you're killing them off the first thing next sprint. Don't let them linger.
- Likewise on technical debt, consider it like real debt. The longer you don't pay it down, the more interest and less principle you end up paying and it will cost you several times over.
- If you're watching your sprint and by the end of the first week (say on a 2-3 week iteration) you're heading uphill, put some feelers out for why. Don't just admire the problem and hope it will go away. It might be okay to start a sprint not knowing what your tasks are (I don't agree with this but reality sometimes doesn't afford you this) but if you're still adding tasks mid-sprint and you're already not looking like you're going to finish, don't. It doesn't take a genius to figure out that if you can't finish what you're got on your plate you shouldn't be going back to the buffet.
- Be the team. Your team is responsible for the progress of the sprint, not one individual so you succeed as a team and fail as a team. Don't let one individual dictate what is right or wrong in the world. As a team, if the sprint is going out of control, fix it. If a PM says "don't worry" when you can see the iceberg coming, don't sit back and wait for it to hit, steer clear because you know it's coming.
INVEST in your stories with SMART tasks

Wednesday, May 2, 2007
Agile
No Comments

An oldie but a goodie that I thought I would share with the class.
For user stories:
Independent
Stories are easiest to work with if they are independent. That is, we'd like them to not overlap in concept, and we'd like to be able to schedule and implement them in any order.
Negotiable
A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the story may acquire notes, test ideas, and so on, but we don't need these to prioritize or schedule stories.
Valuable
A story needs to be valuable. We don't care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.
Estimable
A good story can be estimated. We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation. Being estimable is partly a function of being negotiated, as it's hard to estimate a story we don't understand. It is also a function of size: bigger stories are harder to estimate. Finally, it's a function of the team: what's easy to estimate will vary depending on the team's experience.
Small
Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what's in the story's scope. Saying, "it would take me more than month" often implicitly adds, "as I don't understand what-all it would entail." Smaller stories tend to get more accurate estimates.
Testable
A good story is testable. Writing a story card carries an implicit promise: "I understand what I want well enough that I could write a test for it." "Testability" has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met. If a customer doesn't know how to test something, this may indicate that the story isn't clear enough, or that it doesn't reflect something valuable to them, or that the customer just needs help in testing.
For tasks:
Specific
A task needs to be specific enough that everyone can understand what's involved in it. This helps keep other tasks from overlapping, and helps people understand whether the tasks add up to the full story.
Measurable
The key measure is, "can we mark it as done?" The team needs to agree on what that means, but it should include "does what it is intended to," "tests are included," and "the code has been refactored."
Achievable
The task owner should expect to be able to achieve a task. Anybody can ask for help whenever they need it; this certainly includes ensuring that task owners are up to the job.
Relevant
Every task should be relevant, contributing to the story at hand. Stories are broken into tasks for the benefit of developers, but a customer should still be able to expect that every task can be explained and justified.
Time-Boxed
A task should be time-boxed: limited to a specific duration. This doesn't need to be a formal estimate in hours or days, but there should be an expectation so people know when they should seek help. If a task is harder than expected, the team needs to know it must split the task, change players, or do something to help the task (and story) get done.
From Bill Wake XP123.com
Priority is a sequence, not a single number!

Friday, April 13, 2007
Agile General Software Development
4 Comments

This morning I opened up an email (and associated spreadsheet) that just made me cringe. Which of course made me blog about it, so here we are. Welcome to my world.
Time and time again I get a list of stories that a team has put together for me to either review, estimate, build, filter, whatever. Time and time again I keep seeing this:
Story Points Priority
As a user I can ... 5 1
As an administrator I can ... 3 1
As an application I can ... 4 1
No. No. No!
Priority is not "make everything 1 so the team will do it". When you're standing in front of a task wall with dozens of tasks relating to various stories, which one do you pick? For me, I take on the tasks that are the highest priority based on what the user wants. If he wants Feature A to be first, then so be it and I grab the tasks related to Feature A.
However I can't do this (read: will not do this) when someone puts *everything* to be Priority 1. It's like asking someone to give more than 100%. You simply cannot do it. Priority is there to organize stories so the most important one gets done first. How you define "most important" is up to you, whether it's technical risk, business value, etc. and what value that gives you.
This is more like what priority should be:
Story Points Priority
As a user I can ... 5 1
As an administrator I can ... 3 2
As an application I can ... 4 3
Another thing I see is priority like this:
Story Points Priority
As a user I can ... 5 High
As an administrator I can ... 3 Medium
As an application I can ... 4 High
Another no-no. I can't tell from all the "High" features what is the "Highest" one and we're basically back to everything being a 1 but now we're calling it "High". Unless you've had a mulitple core upgrade in your brain (or are someone like Hanselman, JP, or Ayende who don't sleep) you do things one at a time then move on. As developers and architects, we need to know what is the most important thing to start with based on what the business need is.
With customers everything is important, but for planning sake it just makes life easier to have a unique list of priorities rather than everything being #1. When all is said and done and I have to choose between 3 different #1s in a list, I'll pick one randomly based on how I feel that day. And that doesn't do your customer any good.
Okay, enough ranting this morning. I still haven't finished my first coffee and I still have a few dozen emails to go through.