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…

Ever gone to a site that you found via google that seems to have the EXACT answer to the problem you are looking for?  Then you click on the link and you are shown a page that basically says "You must be a member to access this article."

I can't stand sites like this.  In addition, they are in clear violation of Google's TOS, and they should get dropped from indexing unless the open up the content. 

Why are they in violation of Google's TOS, you ask?  Well basically they are sniffing for googlebot (or any other web crawler) and serving up real content to them.  The data gets indexed, the site's PageRank goes up and the site starts showing high up in the google search results.  But when you or I access the page, we get a different page, telling us that we should pay them money to see the content.

So if you want to give these sites a big middle finger, go download the user agent switcher Firefox extension.  Then add the googlebot useragent to the list.  You can get a huge list of commun useragents here.

Now, find a site that blocks articles to non-members, such as this one:



Change your user agent like so....



And refresh.  Voilà! you're in!

There's a conspiracy going on here.  We all ignored the first signs of it, but now it's too apparent to ignore.   Microsoft is engaging in some devious master plan that will affect most of us.

We all read with shock and awe, Scott Hanselman's post where he announced he was becoming a blue badge.  People wondered what this would do to his blog content, or his contribution to DasBlog.  This was the first sign.  And we did NOTHING.

Today, I saw the 2nd sign, and I'm going to expose this Microsoft conspiracy for what it is.  Phil Haack just announced that he is joining the ranks as a Microsoft employee.  That's right, you heard me. 

Microsoft has hired the technical and charismatic leaders of the two most popular open source blogging platforms for .NET.  This is all a part of a master plan to squash the multi-billion dollar market so that Microsoft alone can swim in the sea of money that is to be made from .NET open source blogging.  Don't kid yourself, there is buku (TM) money to be made in this area.

Sure, both Phil and Scott claim to stay committed to SubText and DasBlog, respectively.  But we all know better.  Soon they will be hard at work, developing the most incredible blogging platform ever devised.  I even have a name for this stealth-assassin project.  It will likely be called Microsoft Collaborative Team Works For Online Weblogs Framework Foundation System 2008.  I can just hear Microsoft Marketing salivating at that title.

All kidding aside, I think that Microsoft is going to be changing it's image, especially in the ASP.NET arena.  They've snatched up some key individuals in the community and they will definitely be making waves.  You can quote me on that.

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!