A large majority of the projects that I come into contact with start out with some sort of Gantt Chart.  Whether it comes in the form of Microsoft Project or just Excel, this is something that is very common in the software development industry.

A typical project plan looks like this:

There's a list of tasks on the left, which are things like "Create Component X" or "Build Customer Search Screen."  The next column shows the estimated duration of the task.  These are time estimates that somebody (or some group) decided on at some point in defining the project.  The chart shows the critical path of tasks in order to get an estimate of when the project will be completed.  You can see that some tasks can be run in parallel, so sometimes delays on these will not result in delays of the overall project.

What's wrong with this?  Under the right environment, one could argue that this would be very effective.  This "right environment" generally looks something like this:

• You know exactly what you're going to build
• You know exactly how long each task will take
• The project won't change while it's underway

Hrm, this sounds a lot like bridge-building to me.  But software development is different.  We aren't building the same thing over and over again.  If we were, custom software development would be almost non-existent.  We don't know what we're going to build because our customers often don't know what they want!

There's a large component missing from this diagram.  Something that our customers care deeply about.  Do you know what it is?  That's right, it's business value!  Where is the business value depicted in this chart?  Surely it's important.  How else can we make scope changes and reorder the work if things aren't going as planned.  This graph has everything already ordered.  According to Gantt charts the business value only comes at the end of the project.  Our customer doesn't know what "Code Component X" means.  This is a developer task, and has no value statement associated with it.

Instead, what if we were to organize our work in terms of features.  A feature certainly has some notion of value.  You customer can easily tell you whether one feature is more important than another.

One could imagine a conversation like this:

You:  George, we're looking at our current progress and it looks like we're not going to meet our May 18th deadline for your demo with the VC guys."

Customer: What?!  Oh no this is terrible!  They might cut our funding!  We have to demo this stuff!

You:  Well, if we were to remove one of these 3 features, we could finish on time and have a demo ready.  Which one of these can wait a bit?

Customer: Well, it's critical that we are able to cancel a reservation.  And I think that we also really need to be able to see the most recent reservations placed, as that is something that the client will do daily, but searching reservations seems like it will be important, but not critical.  For now they can just find the reservations from the list.

Did you see what happened?  Magic just happened, that's what.  You and your customer just had a conversation about features and value.  You're able to adapt to the project's progress and work on the most critical features first.  The demo with the VC guys will happen and the most valuable features will be there.

How could this have happened in the Gantt chart above?  We might be in the middle of "Code Component X" when the demo comes.  Can we have the same conversation?

Lesson #1:  Task-based plans don't convey business value.  Feature-based plans do.

Okay, so now we have a list of features instead of tasks.  Don't we still need to know what is required to implement each feature?  Well yes, but not necessarily at the start of the project.  Breaking features down into tasks is an ongoing activity throughout the life of the project.

What's next?  Let's say we have 2 tasks on our project plan that look like this:

• Build the New Reservation screen (3 days)
• Build the New Booking screen (3 days)

Bookings and Reservations seemed like similar concepts, so we estimated them the same.  So we go off and build the New Reservation screen and we get hit with some complexity.  It takes us 5 days instead of 3.  What do we do about the New Booking Screen?  Is it likely that this screen will take us 5 days as well?  Or do we suck it in and try and work twice as fast to get this one done in 1 day, so our project plan doesn't go off track?

Once an estimate proves incorrect, any other estimate based on that one is now incorrect.  We can assume with high probability that building the Booking screen will take 5 days just like the similar Reservation screen.  The problem here is that we've estimated these tasks in duration rather than size.

Instead, let's give the Reservation screen an arbitrary number, like 5.  5 What?  I don't know...  5 Bananas.  5 Gummy Bears.  5 Stars.  Whatever it is, a 5 should mean something.  What's a 5?  It's about the size of that Reservation screen.  Oh ok, so this Booking screen must also be a 5.  And this Order Fulfillment screen, that's twice as big, so let's call that a 10.  What we're doing here is estimating in relative complexity, which far more stable a number.

Human beings can discern the size of something much more effectively than the time it will take to build it.  And as things progress on our project, the size generally stays constant.  We won't have to re-estimate these tasks unless the size changes.

Lesson 2:  Estimate in size, not duration.

OK, I can already hear you saying "But how can we tell our customer how long it will take if we don't estimate in duration?"  -- Well we do estimate in duration, but we also convey the confidence in this estimate.

Customer:  So how long will this take?

You:  I don't know, we still don't have enough information about what to build, so I can't give you a firm number.

Customer:  Well I have to know, how long do you think it will take?

You:  My best guess?  3-6 months.

Customer:  3-6 months?  That's a big difference!

You:  Absolutely.  We are estimating this at the worst possible position in the project.  Let's assume it will take 6 months for now.  After every iteration (2-4 weeks, typically) we will give you a more educated guess.

Granted, not all customers will be willing to do this, but you can spend more time discussing the process than I have here.

This is where Burndown charts become so effective.  A Burndown chart looks something like this:

This chart shows the hours remaining to complete the work during a given iteration.  Let's assume we attempted to complete 67 points (or Gummy Bears, whatever you decided on) of features.  When planning for hour iteration we broke these down into tasks and the team estimated 420 hours worth of work.  At the end of each day, the developers estimated how many hours remained on the tasks they were working on.  This continues every day.  Sometimes we uncover hidden work and this chart goes upward, as you can see in the picture.  Regardless of what we planned to do with our best intentions, we want to see actual performance.  If you were managing this project, would you feel comfortable with the current progress?

Try plotting a slope line on this image to see where we're headed.  Also plot the ideal line if we were to be on track.

We're about 1/3 done with our first iteration, and we can already make solid assumptions of where we're headed.  It's clear that we aren't going to make our target, so it's time to have that conversation with our customer on what to pull.  This graph might also depict that we'll finish way too early, in which case the customer would be invited to select an extra feature to be developed in that iteration (provided the feature would fit in the slack room we had).

This chart shows clearly what is going on in the project, and you can easily expand this chart to encompass the overall project, not just the current iteration.  What if this graph represented the overall project and we were 1/3 done.  What would you do?

• you could cancel the project -- it sucks, but it's better to get out now than to start  a death march project that ultimately won't finish in time and won't help the business.  Better to lose $150k than $500k any day of the week.
• you could cut scope -- maybe changing the icons to cornflower blue wasn't as crucial to the business as we thought.
• you could remove impediments -- what if you found that the developers are all experienced ReSharper users and they could be more productive if they all had licenses?  What if we had trouble getting a hold of the domain experts and we were waiting too long to get answers?  We could make some changes there to streamline the process.  Most business have a ton of fat in the process.  We just need to find it and cut it out.
• you could add more resources -- if the end date is firm, then we might add some new folks to the project.  This is a bit of a dangerous move, as adding too many people to a project tends to make it later, but in a lot of cases, and extra pair of hands will help.  We can ask the team what type of person they need and try to fill that role.

This type of actual progress vs. planned progress reminds me of that great scene in Apollo 13, where Ed Harris' character is asking whether or not a spacecraft could do what they were asking.  A squeemish representative cowardly states, "The LM was not designed for this..."

"I don't care what it was designed to do, I wanna know what it can do!"

The original plan is only useful enough until it doesn't represent reality any more.  What is useful is our empirical data.  Our actual progress.  That allows us to make informed decisions about what to do next.

Lesson 3:  Actual progress is infinitely more important than planned progress.

At the end of a few iterations we'll get a pretty good idea of how many points we can complete in an iteration.  This number is our velocity.

If we have identified 600 points of features to complete until we're "done," and we're completing an average of 60 points per iteration, then it doesn't take a rocket scientist to tell that we'll be done in 10 iterations.  That's a powerful statement.  After a few iterations you can tell your customer, "based on our current velocity and the amount of work we've identified, we'll be done July 27th."  The next iteration this date will get closer and closer to the actual "done" date.

Lesson 4:  Calculate your velocity and use that to plan for the future.

Burdowns (along with other related practices and ideas) are an incredibly effective tool to help you reign in your out of control projects.  Plans, road-maps, and timelines are all effective tools until they're not reality.  Learn from your past performance and project this onto the future.

I've only scratched the surface on how to effectively use burndowns on a project.  Some other important aspects are defining what "done" means and continuously improving the process.  If you're interested in implementing burndowns, I highly recommend you read these books:

• Agile Project Management with Scrum by Ken Schwaber
• Agile Estimating and Planning by Mike Cohn

I had a skype call today with Rob Conery and Scott Bellware (twitter) today to talk mainly about how to improve the “TDD message” of his latest ASP.NET screencasts.

One of the points of feedback Rob got on his screencast is that he had stubbed the code he wanted to test before actually writing the test.  While there was no “meat” of the code he wrote, there was still code.  And that code had some sort of design baked in already.

The topic in question was about Products.  Rob had a fictitious requirement that the discount should be displayed next to the price.  So he created something like this as a stub:

public class Product
{
	public float DiscountPercent { get; set; }
	public decimal ListPrice { get; set; } 
	public decimal AdjustedPrice 
	{ 
		get { return 0.0m; }
	}

	public decimal DiscountAmount
	{
		get { return 0.0m; }
	}
}

The intent was to test that a discount was properly applied to the product.  Of course, the test fails initially, and then you can easily go make it pass, but the first activity performed was stubbing out code, and that is design.

Instead, a failing test should show with absolute opactity that there is even a need for those properties.  The fact that you’ve written a test specification that says:

A Product with a discount percent of 10 and a list price of $100 should yield a discount amount of $10.

This becomes executable, and you know immediately that you have to implement those properties. 

“But wait?” I can hear you say, “…didn’t you just come to the same end result?”  Well, yes, here I did.  But what if while writing this code you realized that you really need to calculate this amount when you are calculating an order total, then you might introduce an order object.  Or you might have a completely different need.  The point here is that you shouldn’t just assume that you’ll need those 4 properties, or this 1 method, because you’ll likely be wrong.

This also brings out the point of having good test naming.  The test name should be so descriptive, it’s like a rule for the application.  Any new developer can come onto a project and decipher the meaning & intent of broken tests.  That is a very valuable thing to have.

If you recall the original fictitious requirement, it was “the discount should be displayed next to the price” you can see that it is a UI requirement.  It doesn’t necessarily dictate the model that you must use.

In fact, you might even come to the conclusion to use a data transfer object as a presentation model and then this piece of information could literally come from anywhere.

TDD is about design.  You’ve heard that a million times.  The obvious corollary benefit is the enforced existence of automated tests for every possible specification.  Even if you intend to write the tests immediately afterwards, you may have missed out on some critical aspects of design, such as loose coupling, or eliminating waste.  You’re also tempted to just not write tests at all.

If you skip on the test-first nature of TDD, then you’re really just unit testing, and you’re missing out on the real design benefits of TDD.

I also want to point out that I’m not picking on Rob.  He’s had way too much of that.   I think he’s doing a great job and (if done correctly) he can definitely reach a larger audience than I can, seeing that he works for Microsoft.  I also think it takes guts to submit your work to the world and, in the face of some pretty harsh criticisms, stand up and say… “Hey, why don’t you get on skype and we can talk about how much I suck!” — Keep it up, Rob!

So here’s a challenge:  those of you who think that Rob did a “disservice” to the community, I’d like to see your screencast on the subject.  Obviously there is a gaping void instead of widespread adoption, so we as a community could definitely use the material.

Sorry for the late notice on this one (it sort of snuck up on me!)  I’ll be speaking at the North Houston .NET User Group (yes I said North, it’s new).  The talk is scheduled for Thursday, March 20th @ 6:30PM.  The meeting will be held at Montgomery College in The Woodlands.

I will talk about adopting agile development… the what, why, and how.  Hopefully it will be more of an interactive discussion, as there the audience can usually relate to the pain points that I talk about with traditional waterfall development.

For more details, check out their website.

Quality is important.  I think that deserves repeating.  Quality is important.  Quality of code, quality of process, quality of requirements, quality of communcation, quality of behavior, quality of teams, quality of customers.  I tend to focus on the code side of things, but it is always important to remember that quality matters.

Often times (due to lack of quality in some of the other areas), quality can get pushed aside in the interest of getting things done.  This is a balance that all of us must deal with.  Ensuring good communication can put out fires long before they blow up in your face.  Quality of code can ensure that future maintenance and development goes on without slowing to a crawl in productivity.  Quality in process can guide you automate the tedious repeatable tasks to streamline your work.  Any breakdown in these areas can be catastrophic to a team.

We had a meeting last night at Sogeti, and quality kept coming up as a topic.  I was very proud to see the end result of the meeting:

Looks like a new blog meme is starting…  I was tagged by my good friend Shey who’s wanting to know what we all do. (sorry it took me so long to respond!)

So…  what would you say… you DO here?

Well, I’m a consultant, so my role sometimes changes.  Currently I’m a lead developer for an energy company, involved in a Lotus Notes to .NET Migration.

There are roughly 80 applications, some targeted for SharePoint 2007, some custom ASP.NET, and some Windows Forms.

We decided to use SubSonic for data access.  Most of my readers know that I’m a DDD bigot and prefer persistence ignorant business entities and yada-yada-yada.  But sometimes you just have a simple domain model and there’s no reason to go into the effort of introducing NHibernate on a team that’s unfamiliar with ORM’s in general.  (NHibernate just has too steep of a learning curve).  SubSonic shines with simple domain models, and it allows us to be very productive very quickly.

In retrospect I think I would have favored using Castle ActiveRecord.  We wouldn’t benefit from code-gen unless we made some custom templates for CodeSmith, but the main point would be that we can decouple the database from the application code.  It turned out that some database naming standards were in place that favored very common abbreviations for just about any type of database column.  This resulted in polluting our object model with poor names and I implemented a cheap work-around using partial classes and vanity properties.  But the stink is still present .

We’re also using Team System, which is a less than desirable experience in my opinion.  TFS SCC is okay, but it’s no Subversion.  We do our database development with DB Pro and I’ve found that to be both a blessing and a hinderance.  I’m starting to realize that with all of this tooling that MSFT is selling, a better experience can be had with a bit of patience, process maturity, and some open source software.

Where’s all the good info on DB Pro anyway?  All I’ve found are press release/feature list blogs and links to marketing material.

For testing we’re using MSTest, and if I had it my way I’d rip it all out and replace it with NUnit.  MSTest is more annoying than its worth, and we’re not using any of the build quality features anyway, so we wouldn’t be missing out on anything.  I use TestDriven.NET so I never even see the VS Test Runner.

For the build process we use NAnt, but we haven’t setup continuous integration.  Why?  Frankly because I haven’t had the time.  (I can hear the argument that I don’t have time NOT to already).  I have targets setup to build up the database (both incremental and from scratch), generate code with SubSonicCommander, compile all of the source and run the tests.  Continuous Integration is the next logical step, and I hope I can implement it soon.

In summary, here are the tools, frameworks and libraries that I’m using:

• SubSonic
• NAnt
• WCF
• VSTS 2005 + DB Pro
• TFS Source Control
• Prototype / Scriptaculous (for most ajax and dhtml stuff)
• ASP.NET Ajax / Control Toolkit (for UpdatePanel and the Calendar)
• MSTest (yuck)
• Enterprise Library Logging
• RhinoMocks
• TestDriven.NET
• Console2!

To get this thing spreading like wild-fire, I’m going to tag…

Jason Meredith
Evan Hoff
Bil Simser
Justice Gray (keep it professional Justice!  No weekend details!)
Peter Seale

…get to it guys!  What do YOU do?

Wow.  What an awesome event.

I’ll skip the play-by-play, because that has been covered to death.  Instead I’ll focus on my notes.  There are definitely some “meaty” posts in my mind that are still storming, so expect good things to come.  There are some good points here, but it’s a long post so I’ll be surprised if I get any comments .

Being a Catalyst for Change

I first attended a session on “Fostering Passion” and “Being a catalyst for change” which were grouped together.  A lot of people showed up and J.P. Boodhoo led us off.  He talked about the importance of a good, healthy work attitude, and if you aren’t getting what you need from your current employer then you should really seek out something better. 

• You need to show pain before you can start evangelizing new stuff.  Ask people the question “How is that working for you?”  or “What would you want to improve first…. why?”  This gives you the context and the opening for suggesting new ideas.
• Talk about problems in context with the 4 variables, this helps lead to whether something is “working” or not
• Time
• Scope
• Quality
• Budget
• Hosting brown-bag sessions is a great way to get people excited.  Scott Hanselman pointed out that he found it valuable to create a “shadow government” of peers who you can individually get excited about different topics.  Ask them to give a lunch & learn and spread the word that way.  Somebody called them “Hanselminions”  —  epic.
• JP Boodhoo stressed that we build relationships before we offer to “fix up their processes.”  If you come in wanting to change everything you’ll just alienate your team and ruin your credibility.
• Another thing that we discussed is that newcomer’s to our community are going to be very overwhelmed…  currently there isn’t much direction.  We don’t want to be prescriptive, but a general “go in that direction” will definitely be helpful.

Advanced NHibernate

The next session I attended was Advanced NHibernate Techniques, facilitated by Jeffrey Palermo.  I found this to be awesome, because usually when I get to talk (or listen) to NHibernate at a user group or code camp, it’s focused on the beginner side of it.  Everyone in the room had been using it for a while, and had some really good suggestions and valid problems with it.

• ActiveRecord vs. Persistant Ignorant?
• I suggested that for dead-simple models, or a team that doesn’t know DDD, that AR was a much easier path with less friction, however you do quickly hit a limit here when you want to start using more Domain Driven Design such as the Aggregate root/aggregate relationship, repository pattern…  or if you need these to be remote… they can’t be used on the client side.  Somebody pointed out that it is very difficult to switch from one to the other, and this makes the initial decision very hard.
• Howard Dierking pointed out that “No Simple CRUD app stays that way”
• Database, Mapping, Code -> which first?
• This was basically a poll question.  Almost everybody here started with code, then database, then mapping.  Very few people used hbm2ddl (like I do) to generate the database.  We all agreed that generating the database needs to be abandoned once you start doing tuning and specific tweaks.  The Eleutian guys (who have names, by the way… Aaron and Jacob) have a pretty hefty process that all starts with a modeling tool.  It kind of scares me, but they seem to have it working so that they don’t have to re-work anything.  To be truly DRY you definitely need another abstraction, however I’m not convinced that UML is it.   What if we had a Boo DSL that represented the mapping, and we could specify advanced DDD concepts there, and have it generate the code, hbm, and Database…?
• Issues?
• Aaron and Jacob have been stressing about Adaptive Queries and Read-only queries, and I need to make an effort to understand their problem.  Originally I dismissed this as a non-issue, but that’s a cop-out.  I want to understand what they are wanting that they aren’t getting with NHibernate.
• We all seemed to agree that it’s painful that if you have a single error in your mapping file, the session factory throws an exception and just about every test in your application will fail.  This SUCKS for pinpointing the error.  I heard Howard mention something about jitting the mapping assemblies (I guess while writing?) — I definitely need to continue this discussion with him.
• Partials mappings would be pretty cool, so you could generate the mappings based on default conventions, then you could override when necessary.

ASP.NET MVC Framework presented by Scott Guthrie

• This flippin’ rocks.  A detailed post to follow.

Domain Driven Design – Facilitated by Dave Laribee and Scott Bellware (with a cameo from yours truly!)

• This was pretty much review for me, but it’s always good to get refreshed.
• Opening your mouth is a good way to get people to ask you another question (provided you didn’t say something completely stupid) — I kept getting asked to explain more topics here, which was flattering.
• At one point I said “If you haven’t read Evans yet, go TODAY and buy his book.  Then read it 8 times.”  — This led people to believe that I had read it a few times.  Nope!  I still have 7 more to go .
• A lot of discussion went around the different between responsibilities of the entities, and the responsibilities of domain services (not to be confused with application services or <gasp> SOA).

User Stories (facilitated by Scott Bellware & Raymond Lewallen)

• The more I dig into this stuff the more I like it
• Epics– 30,000 ft view (almost impossible to estimate) (if you have to, also provide a low confidence value)
• Theme – closer, but not enough to estimate.  Gives more detail.  Many themes per epic
• Story – small enough to provide estimate & acceptance criteria.
• Ray said “I can give you a gantt chart & have it say whatever you want on it.”  — this is funny, but SO true
• Estimation accuracy and Trust are increased as time goes on… providing you aren’t making empty promises early on
• Don’t estimate a user story until you have acceptance criteria
• Acceptance Criteria (AC) can be technical
• AC helps define “done”
• Early stories will add a LOT of new concepts
• new models
• tables, entities, whatever
• some UI req’s
• Estimating epics helps w/ product planning  (“How much can we put in by next year?”)
• Release planning should NOT include epics.  Break them down.
• AC transitions, which leads is implemented in TDD/BDD style
• Test names should describe the behavior, not impl.  I’ve got to follow this rule more often.  A lot of tests I write are explicit in that I know what happened if it failed, but the actual story that I’m working on is missing.  The failing test has no context, and thus no value associated with it.
• BDD classes are named after the state or original behavior.  The setups for this class put the object in that state.
• Method names are named like the AC
• public class When_a_case_is_opened
• public void Its_status_is_changed_to_open

Are Executable Requirements Possible?

• Jeremy Miller started off by stating the value of Fit vs. FitNesse and a lot of people showed pain with FitNesse. 
• Fit/FitNesse works great when dealing with state-based testing
• Behavior based testing is where it breaks down and becomes really cumbersome
• He invited Joe Ocampo (from Los Techies) to talk about NBehave
• NBehave solves their problem of providing change tracking and traceability into their organization because they have a strict environment that requires it.
• They have a fluent language that looks like theUserStory.AsA(“Premier Member”).IWantTo(“get a discount on future purchases”).SoThat(“I can save money”)
• I joked that they could also have another fluent interface that looked like SystemShall.(“Have a textbox”).ThatShallContain(“the user’s name”) 
• This helps solve the issue where refactoring is difficult.  Since the strings above are keys for delegate hashes, you’ll get an exception if someone changes the text of a story.  This will spark a much needed conversation with the developers.

I’m still trying to bask in the awesomeness that came from this event.  All you naysayers out there are just upset that you missed out .

Get ready folks.  History is in the making.  The Earth will shatter.  People will be enlightened.  The sky will rain candy...

Ok, I'll stop now.

As you can see I'm really excited about the ALT.NET Conference going on this weekend.  I'm especially looking forward to (finally) meeting:

• JP Boodhoo
• James Kovacs
• Roy Osherove
• Martin Fowler (seriously!)
• ScottGu
• Justice Gray (I hope you're as good-looking in person as you are on your blog, Mr. Gray)

Sadly, I won't be able to meet Ayende Rahien as he won't be able to make it.  I'm really bummed about that.  Also, there are a ton of folks I've met before that I'm eager to catch up with.  And, of course, I'm really interested in meeting NEW people!  It's amazing the amount of excitement and vigor around this community.

I'll be driving in tomorrow night and should arrive around 8pm, so if you want to meet up for dinner/drinks (or if there is something official going on at that time) then drop me a line at ben {at} scheirman {dot} com.

I'm bringing my wife, however she's not so interested in the ALT.NET stuff.  She's more interested in hanging out, having fun, and (probably) shopping.  Maybe I can get her to attend 1 session, who knows.  Maybe we can get her to stop teaching Spanish and start programming.

See you in Austin!

Your manager comes to you and says “Hey, Joe.  Let’s talk.  I need to get a new system developed to keep track of our help desk calls.  It needs to have a slick user-interface that is easy to navigate, it needs to be fast, and also we need integration with SAP.”  You ponder what the system architecture might be like.  He continues.  “So how long do you think this will take?”

Of course, your first instinct is to tell your manager that you’ll get back to him later with a rough estimate, but he is in a hurry and persistent.  You cave in and tell him, “I think it would take 6 weeks.”

“Hrm, 6 weeks?  I really need it in 5 weeks, no later.”

Your manager is already negotiating your rough estimate.  Be afraid.  You start to figure out how you can accomplish all of this in 5 weeks and you are realizing that you really needed eight weeks, not six.  Let me put this story on pause while I tell you another story…

Bob is the new night manager at FatBurger.  One night a man walks in and requests a double Fat-burger with cheese, a large order of Fat Fries, and a chocolate shake.  He pulls out the change in his pocket and Bob finds out that he only has $1.20.  The entire meal costs $7.50.

What would you do in this situation?  Turn away your only customer in the 11:00pm hour?  Offer something that he can afford?  Give it to him for $1.20 this time only?

Bob, being a proud night manager, wants to satisfy his customer.  He cannot give away the food cheaply because then the guy will return again, expecting another discount.  So Bob decides to get creative.  He goes around back and finds a dead squirrel on the pavement.  He scrapes it up with a shovel and brings it inside, grills it up and gives it to the man.

In this story, Bob sacrified quality to give the gentleman what he wanted for only $1.20.

Stop me if this scenario sounds familiar.

Back at your desk, you are realizing that you are about to deliver to your manager a squirrel-burger.  He wants X features, but you can’t deliver them on time.  The first thing you are going to throw out are automated tests.  Then you’ll stop refactoring.  Pretty soon you are just heads-down coding like you did in high school and you are making a huge mess.

Two things are likely to happen.  The system will buckle under its own weight because the code reaks of dead squirrels.  The other thing that is likely to happen is that your system becomes useful, and now management has another request.

“Hey Joe.  The new system rocks!  I just got off the phone with marketing and they want to start selling this to our larger clients.”

Now you’re in a pickle.  You have a spaghetti-mess of a system and now you need to extend it and polish it for redistribution. 

This sad state of affairs is all too common.  Your manager might want a double Fat burger with cheese in 5–weeks, but what he’s getting is a squirrel burger.  Don’t deliver squirrel burgers.  Be careful with off-the-cuff estimates that end up turning into negotiations.  Joe should have negotiated features instead of quality to meet his 5–week deadline.  Estimates should include time for automated tests and refactoring because it is part of your daily coding activity and it helps maintain quality.

I first heard the term “squirrel burgers” and the above story from Mark Pushinsky.

Agile Houston tonight was a pretty good turn out. There were over 30 people, so it was a good number to get people talking.  If you came, I’d love to hear your feedback in the comments!

I was able to talk to a number of agile folks from Houston and it’s really cool to see this type of enthusiasm at a local level.

You can download the slides here.

(Matt recorded the whole thing, so if I can get the audio bits I’ll post those as well).

I’m speaking on Adopting Agile at the Agile Houston meeting tonight.  The meeting will be held at PROS Revenue Management downtown on Main street.  Check out the agile houston website for more details.

Hope to see you there!

Day 2 of the class went right into it and had a lot of good, hands-on excercises.  Here are some notes from the day:

Team

• Includes everyone required to deliver the “slice of the pie”  (the functionality for the sprint)
• Extended teams are teams that you have to interface with to deliver your software.  Peripheral teams may be doing waterfall and include vendor and/or teams external to the company.
• The core team should all be co-located, and shouldn’t be interrupted during a sprint
• All teams go through the forming, storming, norming, and performing phase… even teams built with experienced scrum members.  Team dynamics are always different.  Mark (the trainer) wanted to stress that there is an additional phase here called “Adjourning.”  This implies that you have to let go of your previous team if it’s not bringing value.  Don’t do things a certain way just because “that’s how we did it last time.”
• Good Scrum Coaches address problems by holding up a mirror rather than a stick.  Get the team talking and let them come to a solution.  Good coaches know how to set things up to get them talking and then shutup.
• Recommended books:  Project Retrospectives by Norman Kerth, and Agile Retrospectives by Esther Derby, Diana Larsen, and Ken Schwaber.
• Role of Managers often comes into question in Scrum.  Are they pigs or chickens?
• Most of the time chickens
• sometimes the product owner / customer, but depends on the project
• Managers still have forsight of team impediments, so they can be very valuable.
• Managers help the ScrumMaster remove impediments to the team
• Scrum scales via Scrum of Scrums
• 1–2 Members from each team are part of Scrum of Scrums.  Important to get the right people in the room (need problem solvers and cross-functional SMEs)
• goal is to re-sync team efforts, share impediments (find common ones)
• helpful to have someone of VP level present so that common impediments can be taken care of quickly
• “Distributed teams are hard.  Period.  Scrum doesn’t make them any easier.”
• Distributed Teams
• NEVER as productive as co-located teams.
• 90% of communication is non-verbal so stand-ups over the phone are hard
• Effective distributed teams START co-located, then distribute.
• Spend the investment to bring people together or “accept it and have bad teams.”
• The best distributed Scrum teams share a product backlog and task list (via tools or Spreadsheet) so that they still feel part of the same team.
• User stories
• Stories are not contracts.
• Rather they are a placeholder for future conversation
• Stories are not Requirements!  Requirements are meant for defined system behavior for contractual purposes and not business-user friendly.  User strories are meant so that business users understand them.
• INVEST in good user stories that are
• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable
• Stories can be large at first (called Epics) then are broken down into (Themes), then finally into stories. Epics or themes never make it into the sprint, so break them down as soon as you can.
• Purpose of stories:  (3 C’s)
• Card
• Conversation
• Confirmation
• Estimating
• Use story points (or gummi bears… whatever) rather than hours.  Hours decay.  You don’t want to have to re-estimate because your initial estimates were wrong.  If you estimate that you can accomplish 24 story points and you only get 18, then you can only count on getting 18 the next sprint.  If you estimate a task at 4 hours and it takes 8, then what about the other 4 hours tasks on the board?
• Planning accuracy
• 20% of the efforts gives you 80% of the benefit
• Planning beyond that yields little return
• “Plans are useless. Planning is everything.” – Eisenhower.

The course was AWESOME and I strongly encourage others to take the course if you are interested in agile/scrum.

Afterwards we took Mark Pushinsky and Kert Peterson out to dinner and shared some stories and laughs.  I hope to see these guys again in the future.

(oh yeah, and Jimmy and I worked on something super secretive during our free time on this trip… more on that later on)

So my buddy Jimmy and I are in Austin right now taking a Certified ScrumMaster course by Mark Pushinksy. 

I’m ecstatic to be earning this certification, and while I won’t be getting a “Get out of my way, I’m a ScrumMaster” T-Shirt, I am getting incredibly valuable, practical Scrum training from two experts.

Excellent Quotes from today:

Mark (trainer):  So what do you see in the Waterfall model that you don’t see in the agile model?
Guy: You mean “Waterfail” ??

 

Mark (acting as a troubled PM who hasn’t seen any results in 7 months):  Well, I need ALL of those features.  They are all important.
Jeff Palermo:  What if I told you that your budget was reduced to 1/10th of what it is now.  What would be  most important then?
Mark:  Umm, well all that is important.  I need it ALL.
Jeff Palermo:  Ok, so if I could give you something in 30 days, what would you like to see first?
Mark:  You can give me something in 30 days?!?!?!

This dialog was very valuable to me.

Mark:  You can’t heal, what you can’t feel.  (not going to sell agile if they aren’t already feeling pain with current process)

 

Here are some notable points:

• If you tell a customer that it’s going to take 12–18 months to deliver his software, what kind of features do you think he’s going to ask for?  He’s going to think “Well if I’m not going to get it for over a year, I better get the everything and the kitchen sink!”  Contrast this with telling the customer that you can deliver in 30 days, what is most important?
• Scrum demands transparency on the project.  Why would some people resist this?  Lack of trust, Fear of failure (or appearing as a failure).
• Shu, Ha, Ri (martial arts terms — Learning the Rules, Applying the Rules, Adapting and Combining the Rules)
• Waterfall separation of analyst, architects, developers, testers breeds lack of trust.  In the extremem these groups become “enemies” — Ever heard “ Oh if we ever got good requirements we could deliver”  — or “the developers are delivering tons of bugs to us!  What are they doing?!?!”
• Agile/Iterative teams self-organize and fill needed roles to meet the sprint goal – this fosters trust between team members
• The class had some trinkets and creativity toys which I thought was a nice touch to break the monotony of sitting in the same place for a long time
• There were many hands on activities, many requiring us to stand up.  These were awesome!
• Think of scrum as a snowman.  The head is the daily activity (24 hrs), the middle section is the sprint (2–4 weeks) and the base is the release plan (3–6 months)
• Don’t make squirrel burgers (don’t deliver software that is low quality.  Low quality means sloppy code, no unit tests, any corner-cutting.)

Role of Scrum Master

• Remove barriers
• Increase transparency
• Help Customer/Product Owner realize ROI by prioritizing product backlog
• Educating those involved about scrum rules
• (Silent) leader / facilitator
• Improving engineering practices to meeting shippable goal at end of sprint
• empower team to make decisions and get stuff done (self organize)
• look for “coachable moments”

More to come tomorrow…

I am going to be speaking on Adopting Agile to our local Agile Houston user group.  Our last presenter, Robert Martin was excellent, and the speaker following me (who I shall not yet name for fear of jinxing it) is going to be stellar as well.  Maybe if I sandwich myself between great people I can be great by proxy.  We’ll see.

Anyway we’re not yet sure of the venue (might not be at UH this time), so keep an eye out on the agile houston website for details.  The date will either be September 24^th or 25^th, but I thought I would announce it now to give ample notice to those of you who are in Houston but don’t subscribe to the Agile Houston calendar.

My talk will cover some of the foundational principles that are deemed “agile” and why they are valuable.  We’ll also talk about the best way to go about introducing agile at a solo level, a team level, and a company level.  I’d like it to go off as a sort of dialog to get everyone sharing experiences and opinions.

Come check it out next week!

I’ll be at the Oklahoma City Code Camp on July 27^th, 2007.

They’ve got a great speaker line-up and I’m truly excited to meet some people that I have only read or talked to over email.

On the speaker list:

• Jean-Paul Boodhoo
• David Laribee
• Jeremy Miller
• Scott Bellware
• and more!

I don’t know where I’m staying yet, but I think there will be a group discount somewhere.  If you’re going to attend, drop me a line and let me know what your agenda is.  See you there!