During a discussion with a coworker about development process, he  suddenly asked, “What do you think was the best benefit we got from Scrum?” I told him, then decided to post my thoughts and ask for yours.

Here, then, are the top three benefits I received from Scrum:

1. I learned that accurate estimates are difficult. My last post went into some detail about this. The truth is that I discovered that most of us are bad at estimating and we all compensate in some way if the estimates are really important. The tracking built into Scrum provides the details to improve, if you use it.
2. I learned the beauty of the Sprint review. No, not mine; everyone else’s! I expected to see interesting demos and get a better understanding what was going on in the rest of the company, but the personal benefits came as a surprise. I discovered that I am genuinely inspired when I see what the rest of the teams have created.  Watching other people demo new features and discuss the obstacles they’ve overcome stimulates my personal creativity.  If you don’t attend other teams’ reviews, why not?  Not only will you be inspired, but you may have some valuable input for them.
3. I learned the value of non-developer input into feature design. This is, in my opinion, the largest benefit we — at least I — received from an Agile team approach. Non-developers bring a whole new perspective to the design process.   Product Managers have a grasp of the “big picture” out in the market, and testers and writers have amazing insight into the details of the user experience. What’s more, testers think in “boundary cases;” if you empower them to speak up during the design, they’ll “break” the software before you even code it and save you a lot of work later on.  I’ll repeat here what I said in my “Cult of Me” diatribe: there is virtually no one from whom you can’t learn something.  I’ll add to that: the less like you the person is, the more valuable will be their input.  You know all that claptrap about strength in diversity?  It’s not claptrap.

So, there you have it: the top three things that were “in it for me.”  What about you?

]]> http://nancymccall.wordpress.com/2009/09/01/whats-in-it-for-me/feed/ 0 nancymmccall http://nancymccall.wordpress.com/2009/08/08/agile-development-why-i-sucked-at-estimating/ http://nancymccall.wordpress.com/2009/08/08/agile-development-why-i-sucked-at-estimating/#comments Sat, 08 Aug 2009 17:50:56 +0000 Nancy McCall http://nancymccall.wordpress.com/?p=17 ]]> I’ve been doing a lot of reading about Agile Estimating and Ideal Time vs Story Points, and what I’ve found seems to be a debate over methodologies and units of estimation.  These are all valuable, but what’s the first thing you learn at your first Sprint Retrospective?

“Our estimates were way off!”

I am not a consultant, but I thought I’d list what I’ve learned about my own personal shortcomings in estimation and open the floor for other bottom-up views of the process.  Here are the top three reasons my estimates sucked:

1. I did not consider the entire task. Maybe I’m the only developer in the world who thinks this way, but the hard part — the interesting part — of any new task is thinking about it and solving the problem.  To this day, if someone asks “How long?” (or “How big?” or “How much effort?” or questions in any of the various “units”), my gut response will be the time and effort I believe it will take for me to think about the problem and arrive at a solution.  The actual implementation is a bit less interesting and frankly, once you have designed the solution, you can hand off the implementation to someone else.   I had no idea that my brain worked this way until we adopted Scrum and I started updating my backlog.  I noticed the correlation that I almost always started coding a few hours short of  the point that I said I’d be finished.  Talk about bad estimates!  I still have to make an effort to do this, but now I take my “gut” estimate and then add estimates for each of the following to it:  writing the tests, coding the solution, testing, peer review, committing the changes (including communicating changes to the team(s)), and documentation.  I admit this process is best suited to Ideal Time estimates, but it’s a big improvement.  I’d love for this full total to become my “gut” estimate.  Maybe in another twenty years….
2. I had no historical data to from which to learn. I honestly knew that I was not very good at estimating, but we did not track estimates all that carefully.  I knew that tasks always seemed to take longer than I expected, but I did not hold onto the data to try to figure out why or by how much.  Before Scrum and my efforts to honestly estimate, I compensated by padding my estimates.  That kept me more on schedule, but did not really improve the accuracy.  The only way to get better at anything is to examine why you’re bad at it. *Forehead Slap*! How obvious is this point, really?  Perhaps we (or I) just did not value the estimation process enough to track and improve it.  Perhaps I just accepted this as one of my shortcomings.  I have long since forgotten why I did not track my estimates-to-actual ratio and try to better it, but really, it’s an easy, no-brainer step toward improvement.
3. I did a lot of blind estimating. Or maybe I think I’m smarter than I really am.  Whatever the case, after a couple of Sprints my estimates, which had been improving, began to get worse.  It did not take long for me to spot the problem. For a long time, I always had bits of the product that were “mine.”   No one else touched that code and I was always intimately acquainted with what was there.  Then I moved to a different product and picked up code that had been written by other people and had been around for a while.  What’s more, we adopted Scrum and suddenly the Team owned the particular area of the product — any team member might change “my” code.  This was a big adjustment, and I found out that if I had not been in a particular function in the last six weeks or so, I needed to visit it and maybe step through it once in the debugger before I made my estimate.  Not everyone on the team approaches problems the same way I do, and that’s great. (How would I learn from someone just like me?)  If the code has been reworked, I add some time to my estimate to account for the learning curve and consultation with the developer who changed it.

Are my estimates always spot-on now?  Nope.  Are they much more accurate than they were a couple of years ago?  Absolutely. And what feels better at your job than delivering what you promised?

What about you?  What personal roadblocks to accurate estimation have you overcome?  I confess my interest is somewhat selfish — I’m hoping for a couple of  “me, too!” moments that will improve my technique a bit more.

A quote came through on my #agile Twitter search yesterday that I found interesting: “You boss should do your job better than you.”

I have found this attitude everywhere in the Software industry, and I take issue with it on a number of levels:

1. Managing people requires different set of skills than developing software, or whatever the job is of the group being managed. The great conductors are all good musicians in their own rights, but they do not play every instrument in the orchestra better than the section leads.  It does not follow that the best technician in your organization is the best candidate for management, and always choosing to promote the best technician is the downfall of many an organization.
2. Proficiency in any area is worthy of respect, regardless of whether is it your area. The question is never “How smart are you?” but “How are you smart?”  To dismiss the talents and skills of our peers and managers simply because they don’t write code is a huge mistake.  Hear this: there is virtually nobody out there from whom you cannot learn. In fact, the least technical person you can find will often have the best insights into user experience.
3. It is not all about you. Seriously.  Someone’s got to package the stuff and sell the stuff and test the stuff and keep people motivated. Someone’s got to support the stuff out in the field.  In a commercial enterprise, all of those people matter.  Agile empowers developers, but tyranny of the technical is not going to produce anything better than any other system did.

Thoughts?

I know that there are new tea bags with expansive interiors that allow the leaves to bloom.  I know that there are tea pyramids made of silk. (Yes, really.)  I am, however, a loose-leaf devotee.  Water boiled in a kettle on the stove, a ceramic pot, and tea leaves are the ingredients to a happy morning.  Or afternoon, come to that.  I don’t know why it’s better than tea brewed in a cup with one of those fancy new bags, but it is.  Is it the ritual? Is it pure snobbery? Your thoughts are welcome, of course.

Today I heap accolades upon Mount Everest Breakfast Blend from Special Teas, Inc.: a sturdy brew that loves a splash of milk. She is my frequent breakfast companion.

*Sigh*

Just one more cup, and I’ll be ready to report for duty!