My six year old son greeted me being back home this morning with this tidbit.
Be Great or Quit Now
I spent the day today with my fellow Gestalt Scrum Masters meeting about what we want to accomplish as a team within the company. It was a productive meeting overall. There were quite a few good discussions that have led to some meaningful action items. I’m looking forward to the weeks ahead.
When discussing our vision for the Scrum Master team within Gestalt I went on a (slight) rant. I couldn’t help it. I read Seth Godin’s book, The Dip, while on the plane last night and one idea hasn’t left me: Be great, don’t settle for anything less. Don’t waste your professional life in pursuit of anything less than greatness. You can be mediocre anywhere, anytime. Quit when you’re headed for a dead-end. Quit when you’re headed for a cliff. Only pursue those opportunities that provide the opportunity for greatness.
Greatness at Gestalt is no small feat. We’re providing software and consulting services to the Department of Defense. The DOD can no longer afford the status quo of paying big bucks to big companies that take many years to deliver mounds of paper and little of value. The DOD’s “competition” these days doesn’t thrive on big budgets, big monolithic organizations or deadlines in the far off future. The DOD’s “competition” thrives on constraints, is massively distributed and constantly seeking payoffs sooner rather than later. Greatness at Gestalt is delivering the right technology solutions quickly and in an open, non-proprietary manner so that the DOD can succeed in an ever changing environment.
Scrum Master’s play a big role in helping Gestalt as a whole reach greatness. It’s not because we are more important or talented than anyone else within the company. The role we play within Gestalt is one of leadership on a variety of levels; serving as change agents that touch many different areas within the company. We are only a piece to the puzzle called greatness, but if we don’t do our jobs well then there are many others that suffer as a result and the puzzle is incomplete. Not being great as Scrum Masters at Gestalt is not an option. As Seth Godin says on page 57 of The Dip: If you’re not going to get to #1, you might as well quit now.
Why I Blog
A friend and I were instant messaging the other day and he asked me why I started this blog. I never got a chance to reply to him directly so I figured I jot some thoughts down here. I know there are still a lot of people that think blogging is a waste of time. They could be right. I suppose it all depends on how you look at it. Some have blogs simply as diaries and others as journalists. Some have blogs to teach and others to learn. Some just want to publish their thoughts on a variety of subjects and that is likely the camp I fall into. I blog because there are some things I want to capture in writing and share with others. Do with it as you will. Hopefully, my posts will have some value from time to time.
If you ask around Gestalt’s Joplin, MO office who is the one nagging the developers the most to blog, it’s me. Guilty as charged. I encourage the developers I work with to blog for two big reasons:
- Learning to write about what you know as a developer helps make you a better developer.
- The positive exposure you can get from blogging is good for your career and Gestalt as a whole.
Pretty simple reasons. The fact that I evangelize blogging throughout Gestalt’s Joplin office is another reason why I blog. It’s pretty hard to encourage others to do something you aren’t willing to do.
One of my favorite stories I love to share with people lately that shows one of the unexpected benefits of blogging goes like this: James Lorenzen, a senior developer in the Joplin office is helping an intern with a Maven question. James says, “Open up your browser and go to ‘chadthedeveloper.blogspot.com‘” Before he finishes, I start to laugh. “Chad The Developer” is Chad Sturtz’s blog. Chad happens to sit about 20 feet across the room from the intern. It’s funny on a variety of levels, not the least of which is the name of Chad’s blog. (I know, look who’s talking!)
A couple of other great examples of what blogging has done for some of the developers at Gestalt.
Jeff Black writes a post titled, “Source Control Tips for NetBeans Projects” and the NetBeans Community Docs Manager leaves a comment on Jeff’s blog asking him to add this entry to the NetBeans wiki. Chad Gallemore, one of the first Joplin office developers to start publicly blogging, has had people directed to his post covering how to create a JBI Binding Component deployment plug-in for NetBeans as one of the best resources on the subject.
What does any of this have to do with why I blog? It’s huge. Being able to point to the posts written by some of the many smart people I work with at Gestalt is one of the things I most enjoy about blogging. While I get my kicks out of writing here, I really do get most excited reading and linking to other Gestalt bloggers’ posts. I hope those at Gestalt that read this post decide to start up their own blog. I know you’re out there and I’d like nothing other than to see your posts show up in the “One Nice Big Gestalt Blogs RSS Feed” in my feed reader. Who knows, I might even link to you. 😉
P.S. Where else would I be able to share the rarely disappointing “EC Quotes“? I think that’s the #1 reason to blog. Who cares what I think, EC is always more entertaining!
The Cathedral and bzr
Horrible title, but I couldn’t resist. Apparently, I need to get in a time machine and catch up on the latest and greatest in version control systems (VCS). Bazaar (bzr for short) is a distributed version control system along the lines of BitKeeper, git, and a number of others. I’d be lying if I told you I completely understand the advantages of a distributed version control system over a centralized one like Subversion. But, the cool guys from Joyent seemed pretty hyped up about Bazaar as their VCS of choice in one of their podcasts I listened to a couple of weeks ago. Oh, and that little Linux distro uses it too. What’s the name again? Ubuntu. That’s it! Ubuntu uses Bazaar to manage the complexity of such a large code base.
I started to read a bit more about decentralized VCS; knowing that Linus Torvalds is a HUGE proponent of it I figured I’d see what he had to say. I found this crazy long email reply Linus gives about a month ago to Adam Treat of the KDE dev team, who asked Linus some questions about moving from Subversion to git. It makes my brain hurt trying to think about version control in the way Linus does. I’m not even going to try to summarize his thoughts here because I’m still processing them. I hope to come back and elaborate some more if I get the time to check out Bazaar and further investigate if distributed VCS is something that makes sense for a company like Gestalt to consider using.
P.S. Knowing version control systems, the important functions they serve and how to properly use them in configuration management is key to being an ideal QCer on an agile team in my (rarely) humble opinion.
Quote from EC: “Here’s two words that go together: breath mint.”
My six year old son’s comment to his two year old sister right after dinner tonight.
Story Points are Lame?
Ah yes, my second favorite topic when it comes to all things agile — story points. My favorite agile topic? Agile project management tools. But that topic is easy to sum up in one sentence: All the agile project management tools I’ve ever used or evaluated tend to suck in their own unique ways. Maybe one day I’ll elaborate on that enlightening thought, but right now I want to focus on story points.
Story points are one way agile software development teams can estimate the size of user stories. For example, the product detail page for an ecommerce app is estimated to be 8 story points, while the report showing overall ecommerce sales vs. in-store sales is estimated to be 16 story points. We’re not equating story points to how long it will take. Take an experienced, cross-functional agile ecommerce software development team. They say the product detail page is an 8, but the newly formed team consisting mostly of COBOL and FORTRAN software developers estimates the product details page is a 128. Who is right? They both are.
This leads me to an email posted by “macdonald1976” yesterday to the Scrum Development Yahoo! Group with the subject line of “Why points are lame…”
First of all, anything you can make up your own definition for is lame and suspect to say the least. My CTO doesn’t care to hear that my dev team has 150 story points left. He wants to know how many hours they have left. Hours are not subject to opinion. There are 60 minutes in a hour and 24 hours in a day. My CTO can relate to this. My CTO cannot relate to some story point with weights assigned arbitrarily assigned. Sure, some of you will argue that it is not arbitrary and you are entitled to your opinion just like you are entitled to your opinion as to what constitutes a point. This opinion on a unit of measure and the unscientific approach to defining it, no matter how scientific you contend it is, is the reason it has no value in defining remaining effort. Points = opinion and like the old saying goes, ‘opinions are like butt holes, everyone has one’.
Oh no he didn’t. Sending an email like this to the Scrum Development list is like crashing a Star Wars party wearing a Spock costume and talking smack about Yoda in Klingon. I’m happy old macdonald1976 wrote this email because it reflects the opinion of many who don’t quite grasp the concept behind story points. Even better though, it caused Andreas Axelsson to give this spot on response (with my comments in between paragraphs):
Points are intended to give a relative measure of size for stories, not a valid estimate of duration. Mike Cohn (author of Agile Estimating and Planning) says: “Estimate Size; Derive Duration”. The rationale is that it’s much more likely that a team can agree on the relative amount of work for a story compare to another, than on how many hours it’ll take to implement it.
Straightforward definition that gets right to the point.
Compare with two people running a track; The first person will insist it’s a ten minute track, the other a five minute one. Who’s right? They are much more likely to agree that it’s a one mile track (or whatever one can run in five minutes, I honestly have no clue), and that a two mile track is twice as long. Any two people running the track are likely to get a different time, but it’s still the same size.
The most popular explanation for story points that I know of. It’s popular for a reason. It makes sense.
So, estimate in points, validate how many points you can complete in an iteration, using an average over a number of iterations, or historical numbers if you’ve got them, and use that to derive the total project duration. I.e. our velocity of the last three iterations was 27, then the remaining 189 points could be finished in 7 iterations. You do need to add a range though. Or to quote “It’s better to be roughly right, than precisely wrong”. If you’ve got an experienced team on a known domain, you may want to adjust the estimate -10/+5%, if it’s a fresh team learning a new domain the figure might be -50/+25%. (Values from Mike’s book) Using the first figure that gives us a velocity of between 24-28 meaning our 189 points could be done in between 7 and 8 iterations. The inexperienced newbie team would get an initial estimate of between 6 and 14 iterations. (It’s probably not likely that an inexperienced team would average the same initial velocity as the experienced team but let’s ignore that for this exercise, the issue here is the range) There’s really no way to know very early in a project. Experience will tighten the range as the project moves along. So your estimate may narrow from “1st quarter” to “February” to “Last week of February”, all the time giving the Product Owner an accurate estimate just not a precise one.
Practical and concise advice on how story points should be used within a project.
Something you shouldn’t do, however, is to try to transform the hours of your completed iterations back onto the remaining stories. Estimates are pretty much bound to follow the normal distribution and thus you’ll end up with “easy” fives and “hard” fives. Imagine the disappointment if you end up spending 76 hours on an “easy” five from your first iteration and then apply it to every five point story in the backlog. It just won’t work and you’re back at trying to estimate duration directly.
Man, Andreas is hitting a key issue here. Equating story points back to actual hours is particularly tempting for teams to do. Do not do it!
Also, there’s no promise that ten points for one team can be related to ten points for another. It’s just a number, that makes sense to that particular team, and the CEO should not care about its meaning in relation to duration or any other unit. It’s a unit-less relative measure of size for a given team. Period.
So, you give your boss the date range, derived above, not the points themselves. The points are to be used by the PO to prioritize stories along with estimated ROI and any other factors that may contribute.
And the final rebuttal to macdonald1976’s original statement that story points are just opinions puts the executive’s focus where it should be: on the value being delivered. The CXO doesn’t care about points, nor should she care about hours. The CXO should care about what value is being delivered and when the rest of the value is likely to be completed by. We fall back on bean counting hours when we take our eyes off what matters most in the project. We can still do budgets with story points. We can still estimate when our project will likely be completed. We can still know how our teams are performing. We can still determine if the project is on track to deliver the goods. The bonus is that we don’t get caught up in spreadsheet hell, calculating every hour down to the penny. Instead, we can focus on making sure our businesses are delighting customers.
I absolutely recommend Mike’s book if you’re interested in a more in-depth explanation of the above thoughts.
Cheers,
Andreas Axelsson
Cheers is right Andreas. Cheers indeed. A full round of applause goes out to you for that excellent reply! It made my day.
Quote from EC: “Of course you can’t understand her. She’s a baby. You don’t talk baby.”
My six year old son’s reply to me this morning after I told his two year old sister that I didn’t understand what she was saying.
One Nice Big Gestalt Blogs RSS Feed
This evening I thought I’d try an experiment. I wanted an easier way to subscribe to all the blog feeds of my fellow co-workers at Gestalt. I think I found a decent way to do that. I tagged all the feeds I know of today using del.icio.us (cool service, still hate the name) with “gestalt-llc-blogs” and then created a simple Yahoo! Pipes application based on the del.icio.us RSS feed. This means that as more people at Gestalt start blogs (and they will), they’ll have a way to easily add their RSS feed to one nice big RSS feed of all the Gestalt blogs. At least I think that should work. We’ll see if my 30 minutes worth of inspiration makes sense in the morning.
Oh yeah, the one nice big Gestalt blogs RSS feed can be found here.
Google Finds Search
It always seemed odd to me that Google Reader never had search functionality. I mean, what is the one feature you’d expect a Google app to have built-in from the start? Apparently not search. I’m a little slow, haven’t been in Google Reader much lately and completely missed the new search bar at the top of the Google Reader app. Very cool. Now I can actually find nuggets of pure gold in old posts that I tag and star in Reader.
Quote from EC: “Because of science progress.”
My six year old son’s response a couple days ago to my question of, “How do you know aliens aren’t real?”