Reflecting on 2009

December 31, 2009

It’s the end of the year, and it’s time to look back at this blog, and to start thinking about where I will take this blog in 2010.
I started this blog on in January of 2009 for multiple reasons:
To re-examine my own thoughts and experiences gained over the years. The act of explaining my thinking to others via this blog forces me to consider why I have certain points of view, and possibly alter them based on additional thought and consideration on my part.
To challenge myself to read, discuss, and think about programming and managing software development. The objective being to add to my current knowledge and understanding based on the extra effort required by writing about software development.
To exercise and develop my writing skills; after all, the act of writing forces you to think about what you are writing, how you will approach a given topic, and it really forces you to clarify your thoughts. All worthwhile as far as I’m concerned! In fact, I’m finding that I am able to write with clarity at an increasingly faster rate now than I did a year ago.
To utilize Google Blogger and see what I could do with Google’s tools.

The BIG concern that I had when I started this blog was whether or not I could sustain my pace. I determined the title and objective of the blog, and I settled on a goal of posting once per week. Before officially launching the blog, I had brainstormed a list of 20 topics and pre-wrote about 4 or 5 posts in advance. I then got to work setting up my blog.

So far, meeting my once-per-week quota hasn’t been an issue for me. I find that I write in spurts, and that I can produce several blog posts in fairly short periods of time, typically on a slow weekend. During the week, I am mindful of things that I read or any dialog that comes up that might suggest a topic. I write these down and mentally play with them in the back of my mind. When I have a hour or two of time available, I start writing.

I would like to thank all of you who are reading this blog. I have picked a few public followers, and I know that there are many more quietly reading my posts at their leisure. My questions to you are:

What would YOU like to see in this blog?

Do you enjoy my writing style?

Are my topics worth reading about?

My tendency is to write longer posts than some blogging wisdom states is wise. Other advisors advocate that I should post more than once per week. And of course, for every piece of advice there are counter-points. Some bloggers say that posting on a consistent schedule is what really matters, and once a week is fine. Length is not an issue with some bloggers, either. They advise that I write posts that are of sufficient length to cover the topic at hand, and not to short-change a topic to meet an artificial limit on length.

The frequency and length of my blog posts are based on my own experience. I can’t read everything that is out there, but if I find blogs that I enjoy – ones that are informative and offer a good perspective – I certainly don’t fault someone for writing 900 words instead of 300. I don't like having to read multiple posts spread over a few days or a week to understand the author's full message. I would prefer to read it in one shot.

I consider 2009 my practice year. In 2010, my goal is to increase my readership, and that means providing content that has appeal to YOU, in ways that you want to see that content. So, dear reader, what is your opinion? What I am doing right, and what would you like to see changed?

My Reading List

December 23, 2009

It’s the holiday season, and I’m sure that you’ve had your holiday lists to deal with, whether it be a list of gifts for your children, a “honey do” list (like stringing the Christmas lights on the house), a shopping list, etc. Lists of things haven proven to be popular blog posts for other authors, like “The Top 100 Development Blogs” or “The Top 50 Software Development Book,” so I decided to produce one of my own.

My objective was to do a quick inventory of books in my own library that I’ve accumulated over the years and produce an un-ranked list of business and software development books, focusing my attention on books that I would recommend to anyone that is tasked with managing software development and/or trying to build a successful software business. I started out thinking that this would be a “Top 10” list, but I found myself unable – perhaps unwilling is more accurate – to prioritize THAT much!

My criteria:
  • The book must be a part of my personal library. The book represents something that I’ve purchased with my own hard-earned money.

  • The book relates to business or software development, and I feel that there is real value in reading the book. I look for books that provide solid information, excellent perspectives and insight, with a little inspiration tossed in for good measure.

  • Copies must still be available to purchase.

The List:

v Swim with the Sharks Without Being Eaten Alive: Outsell, Outmanage, Outmotivate, and Outnegotiate Your Competition by Harvey Mackay

v What They Don't Teach You At Harvard Business School: Notes From A Street-Smart Executive by Mark H. McCormack

v In Search of Excellence: Lessons from America's Best-Run Companies by Thomas Peters and Robert Waterman, Jr.

v The Dilbert Principle: A Cubicle's-Eye View of Bosses, Meetings, Management Fads & Other Workplace Afflictions by Scott Adams (Fun, and a great resource for things not to do!)

v The Innovator's Solution: Creating and Sustaining Successful Growth by Clayton M. Christensen and Michael E. Raynor

v Good to Great: Why Some Companies Make the Leap... and Others Don't by Jim Collins

v The Discipline of Market Leaders: Choose Your Customers, Narrow Your Focus, Dominate Your Market by Michael Treacy and Fred Wiersema

v First, Break All the Rules: What the World's Greatest Managers Do Differently by Marcus Buckingham and Curt Coffman

v Managing for Excellence, The Guide to Developing High Performance Contemporary Organizations by David Bradford and Allan Cohen

v Coaching for Improved Work Performance by Ferdinand Fournies

v A Passion for Excellence: The Leadership Difference by Tom Peters and Nancy Austin

v Crossing the Chasm by Geoffry Moore

v Execution: The Discipline of Getting Things Done by Larry Bossidy, Ram Charan, Charles Burck

v The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad by Micheal Cusumano

v Programming Pearls and More Programming Pearls: Confessions of a Code by Jon Bentley

v Rapid Development: Taming Wild Software Schedules by Steve McConnell

v Code Complete: A Practical Handbook of Software Construction by Steve McConnell

v Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire

v Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages People by Michael Cusumano and Richard Selby

v The Art of What Works: How Success Really Happens by William Duggan

v Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp

v Software Requirements by Karl Wiegers

v Getting Results from Software Development Teams by Lawrence Peters

v The Practical Guide to Defect Prevention by Marc McDonald, Robert Musson, and Ross Smith

What I’m reading right now:

Coders at Work: Reflections on the Craft of Programming by Peter Seibel

Agile Principles, Patterns, and Practices in C# by Robert C. Martin and Micah Martin.

Have a Merry Christmas and a Happy New Year!

Never, Ever, Be Too Clever

December 18, 2009

When I was in college (and we aren’t exactly talking about yesterday) my computer instructor – who had years of practical experience under his belt – was adamant on one point: If we passed in code that smacked of job security programming, he would cut our grade in half. His message was clear, that our code needed to be logically and clearly expressed because some day other people would need to update it, and in order to do so they would need to understand what they were looking at.

It was obvious that my instructor had been frustrated by code that was unnecessarily complex during his career. Furthermore, he attributed much of this complexity as both unnecessary and deliberate on the part of the developers who wrote the code, with the conclusion that the developers were making themselves “indispensable” by deliberately convoluting the code.

I’ve seen my share of difficult-to-understand code over the years. In my opinion, some people have the specific intent of playing the job security game. In other cases, people are almost too smart for their own good. They have a lot going on inside of their heads, and while they do a great job of keeping a mountain of variables and conditions circulating around their brains, the resultant expression of logic is almost diabolical. Yes, the code works, but it takes a great deal of time and an extraordinary intellect to unravel the intricacies of their logic.

In other cases there is an inexperienced or less than capable programmer involved. And this programmer hasn’t thought the problem through before coding and ends up throwing code at the problem until he or she can get it to work, making one heck of a mess in the process.

As a manager, if I find that we’ve missed a code review that should have prevented problems like this from making it into the production code, I’m upset! Maintainable, understandable code is a BIG deal. Allowing poor (difficult to maintain) code to find its way into the code base will drain your productivity later. I want code reviews to serve as a gate to prevent problems from making their way into the code. As part two, I’ll work with the individuals to improve or change their game, reducing the instances of poor code from being produced in the first place.

I’ve seen other problems with code, problems that have their roots in inappropriate design. One example from my own recent experience occurred when I dove into a complex issue with one of our Windows®-based applications.

The real problem with this code is the fact that messaging is being used and abused. Windows® messages are being peeked, pre-processed, forwarded, and raised – you name it and this code is doing it. Finally, the timing of when the messages are processed is also very important. All of this is being performed in the name of collecting, formatting, validating, and coordinating the (redundant) display of data.

We ran into problems when we needed to extend functionality in a very small way to meet a customer need. As we extended the functionally, we broke things in the process. I ended up working on this issue myself, but every time I fixed one problem, another cropped up someplace else. I refer to this situation as the whack-a-mole problem. As it turns out, two us of independently wrestled with the problem in similar ways and ended up with the same conclusion: Based on the current design, there was little chance that we could get everything running in accordance with the existing design.

I know what you are thinking: re-factor time, right?

Well, we are talking about C++, MFC legacy code here. And this problem is greater than a refactoring effort alone. Refactoring is one thing, completely re-designing and re-implementing is another. In fact, we are in the process of re-architecting and re-writing the business capability that this code supports in .NET, gradually moving key processing to Web Services and browser-based technology. None of this code will be carried forward, and certainly NOT in the way it is designed now.

So I settled for a well-contained, well-commented, two-line hack to get everything running and to make us whole as far as our customers are concerned. It is annoying that this circumstance exists within our code base, but I really can’t justify investing any more time or energy in modifying our legacy code because it will divert resources from our more strategic, stay-in-business efforts.

I cannot state for sure why this code is designed the way it is, since I’m not the one who designed it and I was not a part of the equation when this code was implemented. A design review should have been conducted to prevent this design from ever being implemented. This code resembles instances where I’ve seen technologies and certain approaches used because someone read about something and wanted to try it, which is not a great reason for implementing that something in production code!

This can be tricky territory, but there is a line between staying current and applying what you’ve learned and going out of your way to use technologies or approaches because you want to stuff your resume. As a professional, it is NOT okay to use the company that you work for as your personal software lab.

If you want to explore something, talk to your manager. Work on a side project that is geared at providing your organization with information and a working example of the technology. Or get assigned to a project where utilizing the technology makes sense.

But don’t compromise the maintainability of the code base – a corporate asset – by using designs and implementing things just because you want to learn about them. Be responsible. The use needs to fit the need.

By all means keep learning about technology and the industry. It’s great to know that something exists that might help your specific situation. And if it is an appropriate fit, learn about it and discover the correct way to implement it for the benefit of your project and the code base.

Software should be an organized, clear expression of logic that clearly meets the needs that the software is attempting to address right now. Maintainable software is about using a reasonable structure, one that meets the business need, yet doesn’t try to reach too far into the future. If there is a need for the software design to evolve to meet more complex needs later, evolve it when later arrives, not now.

Designing too far into the future is attempting to anticipate problems that you might not encounter, because the problems themselves might change. After all, requirements are always a moving target, are they not?

Book Review: Talent is Never Enough

December 11, 2009

I find the art of achieving success to be intriguing. Many people attribute success to luck, to being in the right place at the right time. Others argue that you make your own breaks, and being in the right place at the right time without being prepared does you no good at all. What does it take to be prepared? That was the question that leapt into my head when I came across a book titled Talent is Never Enough: Discover the Choices That Will Take You Beyond Your Talent by John C. Maxwell (Copyright ©2007).

I flipped through the book, and it appeared to have a lot of information in it, so I purchased it for my summer reading, even though I had a few other books already selected. However, I read fast, and I need several books to get me through the summer…

The book began by articulating something that I am in full agreement with, and that is to stop working on your weaknesses, and start working on your strengths. As a manager, I’ve always followed this advice that I got from reading another book several years ago: First, Break all the Rules: What the World’s Greatest Managers Do Differently by Marcus Buckingham and Curt Coffman (Copyright © 1999 by The Gallop Organization). Since reading that book, I have always sought to understand the strengths and preferences of those who work for me, so that I could best align the work with the abilities and preferences of my staff, but I digress.

Maxwell raised an interesting point in the introduction to Talent is Never Enough, and that is the observation that people can increase their ability in an area by only 2 points on a scale from 1 to 10. This is an important point because if you happen to be a 4 in a given area, you have the potential of reaching a 6, a little above average. If you are a 7 – where your strength lies – you have the potential of becoming a 9, effectively moving yourself from a 1 in 10,000 talent to a 1 in 100,000 talent.

Find your talent – your strength – and develop that talent to its fullest extent.

However, the main thrust of the book was the talent needs to be accompanied by other things, and that you won’t make it on talent alone. You need to be a “talent-plus” person. Many of the “plus” items were not new to me, but it was the first time that I have seen these articulated in one place, and expanded upon in fantastic detail. What are those “plus” things?

Belief. Believing in yourself, your potential, your mission comes from within, and will remove artificial limits that you may be placing on yourself.

Passion. It energizes and empowers you. It enables people to make the most of whatever talent that they possess.

Focus. It directs your talent. Avoid taking on everything; Attempting everything is like attempting nothing. It will suck the life out of you.

Preparation. It positions your talent. When you don’t prepare, things that you hoped won’t happen do happen.

Practice. It sharpens your talent. You play at the level you practice.

Perseverance. It sustains your talent. It means succeeding because you are determined to, not destined to.

Courage. It what you draw upon when your talent is tested. If you fail to step up and meet a challenge, you will not realize the depth of your talent.

Teachability. It expands your talent because you are willing to discover and grow. It is an desire to listen, learn, and apply.

Character. It protects your talent. Many people with talent make it into the limelight, but the ones who have neglected to develop strong character rarely stay there long.

Relationships. They influence your talent. Some relationships take from us, like critics, gossips, backstabbers, control freaks. Other relationships add to us, like family, creative people, fun people, encouraging people, successful people.

Responsibility. It strengthens your talent. People who handle their responsibilities well get the opportunity to handle additional responsibilities.

Teamwork. It multiplies your talent. Talent may win games, but it is teamwork that wins championships.

Overall, I found Talent is Never Enough to be a very good read, and I recommend it to anyone who wants more insight into why you need more than just talent alone.

The True Definition of Success for Software Projects

December 4, 2009

The Challenge in Defining True Success
Let’s examine the question of the classic definition of on time, on budget, of high quality, with the expected features as a traditional measure of success. Is it possible for a project to meet this traditional measure of success and still be regarded as a failure? I’ll answer that question with a question: What if the project ultimately fails to provide the anticipated business value?

Conversely, what if a project fails on the traditional criteria, yet delivers greater business value than anticipated? It happens; in fact, CIO Magazine reported on this very phenomenon in an article called Applied Insight - Tracks in the Snow, by R. Ryan Nelson.

In the article, Nelson cites an example of a financial services company that developed a new system to improve collections performance that was six months late and cost twice the original estimate – failing in the classic sense. However, once in production, the system provided a 50% increase in the number of concurrent collection strategy tests in production. On that basis, the project was judged to be a great success!

Relate this back to the results from Scott Ambler’s 2008 survey that I discussed in my previous post, The Elusive Definition of Success with Software Projects, where 70% of the respondents believed that providing the best ROI is more important than delivering under budget. This scenario supports the opinion of the respondents perfectly.

There are other realities in the business world, and one is that business priorities shift over time. Can you state with certainty, conviction, and honesty that today’s priorities will remain firm during the entire course of a year? Unfortunately, there are a number of software projects that have this implicit expectation because they have delivery dates set one year or greater into the future!

Achieving Software Project Success
The situation above, where a project was six months late and cost over twice the original estimate – yet was still regarded as successful – points to the first important point in achieving success: Understand your expected return.

Understanding the benefit that you expect to get out of the software provides you with a valuable insight about both the worth of the software as well as defining exit criteria. One thing is certain, and that is that software projects are not as predictable as everyone would like them to be (I won’t go into the reasons here). If project timelines continually move into the future, you need to start asking yourself if the additional investment is worth the payoff.

The 2006 Chaos Report from The Standish Group found there was an 18.8% improvement over a 12-year period for software projects in meeting the on time, on budget, and expected features criteria. This places only 35% of all software projects as succeeding according to this classic measure, but it is still worth examining what drove this improvement to understand what it takes for projects to be successful.

When asked for the reason that project success rates improved, Standish Chairman Jim Johnson replied, “The primary reason is the projects have gotten a lot smaller.” And this means both smaller teams and a smaller number of features.

Smaller teams are more productive than larger teams. This model is supported by studies by Quantitative Software Management (QSM), a company that maintains a comprehensive database of software development project metrics, with its data coming from its own projects and a repository that is part of its SLIM estimation product.

Here’s a pop quiz for you, based on QSM data: There are two software teams that must deliver a project with a size that is estimated to be about 40,000 lines of code. One team, Team Large, has 29 resources compared to Team Small, with 3 resources. How much faster do you think Team Large will be?

According to the QSM data, the difference would be a mere 12 calendar days! The other significant difference would be the fact that Team Large would consume 151 more person-months more Team Small. This begs the question: Why did Team Large experience such poor productivity?

There are a number of reasons why large teams suffer productivity drops. Teams start out as a collection of individuals, and they must spend some time getting to know each other’s strengths, weaknesses, preferences, and idiosyncrasies. Some mixes of people work better than others, and no matter what it takes time for people to work effectively as a team, and this will take much longer with a larger team.

Small teams can also coordinate their work far more easily and quicker than larger teams. Larger teams have greater overhead, including more lines of communication. And when there are more people involved with more lines of communication, the greater the opportunity for miscommunication to occur.

The result of coordination and communication issues can be just what another aspect of the QSM data reveals: that the larger teams produce over 6 times as many defects as smaller ones. As you can imagine, this introduces a significant burden on productivity, since defects must be logged, reviewed, fixed, tested. Overall throughput – getting things squarely into the “done” column – is significantly impacted.

A smaller number of features are easier to contend with. A large feature count is more difficult for project teams to wrap their heads around. My own personal experience is that all too often, projects with large feature counts devote less time to each feature than smaller projects.

If less time per feature is spent to the point where the time is inadequate to thoroughly define each and every feature, ambiguities creep in, and they will remain quite undetected until later in the software development process. But they will surface and cause problems – moving a seemingly well-defined project into the challenged category, particularly if those ambiguities create expensive re-work.

The other problem with a large feature count is that a greater amount of planning, design and testing is required to ensure that all of the features work in harmony. The greater the feature count, the greater the challenge of maintaining internal consistency; features cannot conflict with one another or otherwise interfere with related processing. Quite simply, a large feature count increases the likelihood of defects occurring.

Focusing on a small set of features is also important because business priorities shift over time. Projects with long time frames are likely to have features that are deemed as important now, but won’t be as important when the software is delivered. And let’s not forget that there is uncertainty about the anticipated benefits in the first place; the realized benefit could be less or greater than what was anticipated at the outset. A smaller feature set will have a faster delivery schedule and enable the business to assess the reality of the benefit(s) much earlier.

There is also the problem where stakeholders of a software project have a high-level goal that they want to achieve, but that goal gets lost when the definition of the features is delegated to others in the organization. While it is certainly appropriate to involve those who work in the trenches, as they will be the ultimate users of the software, there is a tendency to add a variety of “must have” features to the list during the process, some of which will not necessarily be related to the high-level goals of the project. A stakeholder review of the features can catch this situation before expensive software design and development begins.

Notice that I did not advocate using any one software development process over another, but instead sought to focus on the key ingredients to achieve higher productivity and greater success:
  • Understand your expected return and weigh this against the investment that you are making over time.
  • Focus attention on the smallest set of features that deliver the greatest business value.
  • Use the smallest team possible to achieve maximum productivity.
I personally believe that these are core principles that can help any software project be regarded as a true success, along with being a positive experience for all those involved! These principes can be summarized as striving to meet the following, generic goal:

Software needs to provide the greatest possible business value through the implementation of the least number of features possible, using the smallest size team possible, and be delivered in the shortest time frame that ensures quality.

Scott Ambler’s December 2008 Software Development Project Success Survey

Standish Group Report: There’s Less Development Chaos Today by David Rubinstien, March 1, 2007

Standish Group: Project Success Rates Improved Over 10 Years

CIO Magazine - Applied Insight - Tracks in the Snow By R. Ryan Nelson

ComputerWorld - Development Study: Haste Makes Waste By Linda Hayes, September 23, 2005

The Elusive Definition of Success with Software Projects

November 27, 2009

What is the state of software projects today? Are software projects more successful today than they have been in years past? Think about any software project that you know of that is just getting started. How confident are you that the project will be considered a success?

One problem with software projects is determining the definition of success. Consider the following, classic definition of a successful software project.

Delivery of software:
  • On Time
  • On Budget
  • Of High Quality
  • Containing the Expected Features
Does this meet your own definition of success? More importantly, just how is the software industry doing in terms of projects being completed and meeting this classic measure?

A 2006 Chaos Report from The Standish Group indicates that software projects are improving over time, as demonstrated by a similar study that they conducted in 1994. Let’s take a look at the numbers and how they contrast over the twelve-year span.

According to The Standish Group, 19% of the projects reported on in 2006 were outright failures, which is certainly an improvement over the 31.1% failure rate reported in 1994. A look at the rest of the figures reveals a different problem, where projects move from failure to “challenged.” A challenged software project is defined as failing to meet the classic definition of success in one or more ways, such as incurring a budget or schedule overrun, or having features trimmed from the final delivery, but the project itself is not deemed to be a failure.

The 2006 Chaos Report states that 35% of the software projects succeeded in meeting the on time, on budget, and expected features criteria during 2006, relative to only 16.2% in 1994. (While not explicitly stated, the assumption is that the quality objectives were met as well.) If we remove the 19% of outright project failures for 2006, we arrive at a significant, 46% figure for software projects that were in the challenged category during 2006.

Although these figures paint a dismal picture of the software industry, they only represent a piece of the puzzle. In fact, there is – and should be – a modified view of success. This was illustrated in a 2008 survey conducted by Scott Ambler, who had an overall goal to explore how Information Technology (IT) professionals define project success.

There were 279 respondents to Scott’s survey, and their definition of success in comparison to the classic definition is as follows:
  • On Time: 58% believe that delivering when the system is ready to be shipped is more important than delivering on schedule.

  • On Budget: 70% believe that providing the best ROI is more important than delivering under budget.

  • Of High Quality: 82% believe that delivering high quality is more important than delivering on time and on budget.

  • Delivered with the Expected Features: 83% believe that meeting actual needs of stakeholders is more important than building the system to specification.
After reading the survey and noting the responses to the classic measure of success, I reflected on past experiences and conversations that I’ve had with others about the nature of software success. In general, the measure of success to a great degree is a function of organizational culture. I’ve talked to some frustrated project managers and developers who have told me that in their company, teams that deliver on time are recognized as successful over other teams who deliver as little as a week late.

The real rub is that teams that delivered on time is still regarded as successful in spite of the fact that their software required substantial defect-fixing months after delivery, while the teams that were only marginally late delivered with higher quality, and did not need to allocate substantial time and effort to support a product of poor quality – and were able to move on to more productive ventures.

I decided perform a modest cross-check of the results of my own by posting a question on LinkedIn in the Software Development category. I cited the survey and asked: “What should the definition of success be? Are we being more successful today than yesterday because we are changing the definition of success?”

Needless to say, I received a range of responses. There were answers that qualified success as meeting the business objectives of the project, while other answers were in the “it depends” category. Overall, while there was agreement with the classic definition in principle, there was a lot of deferring back to what the stakeholders of the project defined as successful.

This leaves us in a situation where not only are software projects challenged, but the very definition of success is also being challenged. It is certainly in the best interest of everyone to have a candid conversation about the definition of success before taking on a project. Above all, acknowledge that there will be challenges, such as people changing their minds about the requirements, or details surfacing that change everyone's understanding of the original requirements.

And don't expect to have it all. The classic success criteria is about predictability, and software projects are rarely predictable. I wrote about this in my Can Software Projects be Predictable? post.

Scott Ambler’s December 2008 Software Development Project Success Survey

Standish Group Report: There’s Less Development Chaos Today by David Rubinstien, March 1, 2007

Software Magazine: Project Success Rates Improved Over 10 Years

What Football brings to Software Development

November 20, 2009

This past Sunday, I watched the New England Patriots lose a big game to the Indianapolis Colts 35-34, and everyone is pointing to the coaching decision by head coach Bill Belichick as the cause of the loss.

Towards the end of the game, a critical situation arose that required a key coaching decision, one that meant winning or losing the game. The Patriots were facing a fourth down with two yards to go on their own 28-yard line, with 2:08 left in the game.

Normally, this is a punting situation, no questions asked. But Belichick opted to go for the first down. He clearly didn’t want to give the ball back to Payton Manning and the Colts, and I don’t blame him.

Almost everyone is calling this the worst coaching call he could have made. Of course, if the play had worked, everyone would be tripping over themselves in admiration of Bill Belichik’s guts, noting the confidence that he has in Tom Brady and the offense, how the Patriots must have ice in their veins, and so on.

From my Monday-morning quarterback vantage point, I firmly believe that if the Patriots had punted the football, Payton Manning and the Colts would have driven down field to win the game. In the end, the Patriots lost a highly competitive game, but what the heck does this have to do with software development?

Just like software development, football players execute better than the coaches. I readily acknowledge that there are plenty of ex-players who were darn good players in their day that are now coaching, but there is a difference between knowing the game and playing the game.

While age is a factor on the football field, time and experience with the latest tools becomes a factor in programming. Once someone progresses beyond a junior level, someone who is programming full time should be better able to perform the act of programming better and faster than a manager. A manager's job should involve a variety of other duties that will negate their ability to be as proficient as others who exclusively focus on programming, particularly as time marches on and new tools and technologies are introduced.

This doesn’t excuse a software manager from understanding the software game. To be effective, I am a firm believer that a manager must understand what he or she is managing. True, you may not be able to execute as well as those that you are managing, but that is OK. You do need to understand and manage what goes into producing results in order to be effective.

For example, football coaches watch and measure what goes into making the individuals and the teams better and coach the players on those aspects of the game. They want hand-offs without fumbles, they want everyone coordinating their efforts by blocking when and where they are supposed to be, running pass routes designed to provide the quarterback with options, etc.

The bottom line is that while good coaches absolutely want a higher score, they don’t fixate on the score itself. They sure as hell can’t ask players to work “overtime” in a game in order to bring up the score. The players need to execute well, and they need to review what they did right and what they did wrong, make adjustments, examining their execution from both as a team and an individual basis.

The key is to understand what it takes to be successful, and taking time to make the observations that allow you to see the problem areas in which you need to improve. This means that as a manager, you have to have your eyes on the field, observing your direct reports and the team interactions from the perspective of an informed individual, someone who knows how software should be developed as well as how to manage people and teams.

As an example – and in keeping with my football theme – is to consider what the real cause of the Patriots loss to the Colts. They have a red zone problem. The Patriots settled for two field goals in that game after driving most of the way down the field. Had they scored a touchdown instead of a field goal one of those times, they would not have faced the game-winning, pressure situation that everyone is now crucifying Bill Belichick for. They could have punted the ball away, because giving giving the Colts back the ball at that wouldn't have mattered. The Colts would have needed two scores, not one, to take the game away.

Examining the game films will reveal why the Patriots are failing to score touchdowns in the red zone – which could be a number of causes. The key is not to focus on the score and the one call that led to their losing the game. Sure, maybe punting would have worked. But scoring a touchdown instead of kicking a field goal just once – and earlier in the game – would have guaranteed victory by that now-fateful 2:08 point in the game.

In the software business, look for results, but focus on those things that go into achieving results if you want to be successful.

Task-Switching is for Computers, not Humans

November 13, 2009

Computers are much better at multi-tasking than humans are. Why? Because a computer is designed to multitask. When a computer switches from performing one task to another, it saves the entire state of the task being switched out, enabling the computer to literally pick up where it left of when it returns to that task.

Humans aren’t wired that way.

Consider an activity that requires keeping a lot of details in your head along with applying some creative thought; where mental focus and concentration is essential, like programming. Programmers keep a lot in their heads during the act of programming, like how the code will be organized, what data structures are being used, the naming and use of variables, all of which is centered on the act of translating business requirements into detailed instructions for the computer to follow.

What happens when a programmer is pulled of one programming project to work on another project or problem? Valuable productivity is lost. In his book Quality Software Management: Systems Thinking, Gerald Weinberg proposed a rule of thumb to calculate the waste caused by project switching:

The graphic illustrates how switching between only two projects is very costly: You lose 20% of your time! By the time you get to three or four simultaneous projects, you’re losing significant productivity to task-switching.

This is also supported by recent studies written about in a Wall Street Journal article New Studies Show Pitfalls Of Doing Too Much at Once. One study in the Journal of Experimental Psychology points out that people who multitask are less efficient than those who focus on one project at a time, because the brain has to overcome "inhibitions" it imposed on itself to stop doing the first task in order to take on another tasks.

Not only that, but attempting to manage two mental tasks at once reduces the brainpower available for either task, according to a study published in the journal NeuroImage. This was proven by a relatively simple experiment where subjects listened to sentences while comparing two rotating objects. It was found that the ability to process visual input dropped 29% if the subject was trying to listen at the same time.

How does this translate to my day-to-day software management universe? As a software manager, I have my own personal rule that I manage by: If a project is important enough to start, it is important enough to finish. When someone is allocated to a project, they are expected to see that project through to the end; and I resist pulling anyone off of a project at all costs.

Equally important, I regard interrupting programming time as something that I only do as a last resort, when there is a critical issue. Like when another team is dead in the water and someone else has the skills and knowledge available to help un-stick that team, or when a customer is down and I know that one or more individuals can help. As a rule, I do everything I can to make these situations exceptions that occur very infrequently.

I'll wager that virtually everyone agrees that task-switching of programmers is very counter-productive, but all too often the day-to-day practices of management translate into interruptions and disruptions of productivity! We're all human, and it's easy to think, "What is one day out of a schedule slated to last a few months?"

Let's take a look at an example provided by James Shore and Shane Warden in their book The Art of Agile Development. They note that a programming task estimated at 8 hours could take 2-3 calendar days if a programmer gets interrupted.

While the impact of interruptions on an entire project don't seem significant when they occur, keep in mind that projects rarely have one BIG event that someone can point to as THE cause of a target date being missed. The reality is that software projects get into trouble a little at a time, and schedule misses are almost always due to the cumulative effect of lots of little things going wrong over time, like tasks taking longer than estimated. And if you are interrupting programmers, you are disrupting projects!

Programmers meed concentration time – and blocks of it – to be productive. Leave task-switching to computers.

Six Ingredients for a Successful Team

November 6, 2009

What Makes a Team Successful? I’ve watched different sports teams succeed and fail over the years, and regardless of whether you are talking about high school sports or professional sports, the same key ingredients are present in the teams that are successful. The same holds true in the workplace.
  1. A clear goal with a specific focus. Even teams that should be great will fail if they attempt to take on too much. By keeping the focus narrow, and with clear objectives, teams can achieve success. If you truly have a lot of ground to cover, then cover it in small steps, using specific, measurable intermediate goals. Too many software projects in particular fail because they attempt to cover too much ground all in one shot.

  2. Talent. Without talented players, you can only go so far. Talented people have a gift, the capability to perform, with the potential to reach greater heights than others. On the flip side, there are talented people out there who don’t reach their true potential because they don’t work to develop their potential. They remain on par and competitive with others, but rob themselves because they don’t apply themselves.

  3. Dedication. This is displayed by those who are enthusiastic and willing to apply themselves to their chosen sport or profession. They study and learn. This can make the difference between being darn good and being a superstar. Even an average Joe can compete with others that possess greater talent if those with the talent aren’t working to improve their game. Larry Bird was known for dribbling a basketball over every square inch of a court prior to a game. Why? Because he wanted to find the flat spots where the ball didn’t bounce back as quickly; he filed this away and used this knowledge to his advantage to make a steal. His dedication provided him an edge. In the working world, my take is that dedication is displayed by those who have the “I’m responsible for …” attitude versus those who have the “I work at… ” attitude.

  4. Practice. Talent and dedication do nothing if you don’t practice what you have learned. As a software developer in years past, I did something that I advocate to this day: Put together your own, small applications to learn things outside of whatever tasks you have going on with your current day-to-day job. This will likely be done on your own time, on your own dime, but it will give you practice and experience that broadens your knowledge and abilities. Focus on understanding developing and honing skills without cutting corners. This means using good approaches to development, not hacks. Practice alone doesn’t make perfect. Perfect practice makes perfect.

  5. Coaching. Any team that is successful has a good coach behind it. Coaches motivate, recruit, and set the tone and direction. They get people to understand what they need to do and why they need to do it. They recognize and reward people for a job well done. They call the plays and expect the best from themselves and those on the field. They make the hard choices of benching people or removing them from the team when necessary. It’s about blending the individual talents into a cohesive, unified team, helping everyone to realize their full potential in the context of working collectively as a team. Coaches watch the hand-offs, transitions, communications and interactions between teammates.

  6. Playing as a team. The most successful teams are greater than the sum of the parts. Great teams communicate openly and honestly, they understand each others’ strengths and weaknesses, and they push each other to become better. The team score matters the most, but everyone is expected to contribute. Great teams don’t have weak links, and they don’t tolerate laziness. They want talent, but will take someone who is dedicated, hard-working and willing to practice over someone with talent but no drive or lacking in the desire to be a part of the team. The real need for successful teams is to get everyone flowing in the same direction, dividing the effort – with everyone pitching in – to reach a common goal. Personal goals are second to the team’s goal because great teams understand that they can achieve more than a collection of individuals who are out for themselves.

Succeeding with QA Automation

October 30, 2009

As I mentioned in my last post, a change in the date and venue for our annual user conference was a curve ball in terms of a presentation that I was slated to be a co-presenter for: QA Automation. Instead of co-presenting, I was the sole presenter, tasked with creating and delivering the presentation! I’ll cover the highlights of my presentation, with one caveat. I structured this to talk about some general observations about QA Automation and then conducted an open discussion. I wanted to test my observations and learn from others.

I opened with the following questions:
  • What should be automated?

  • Can manual testing be eliminated by implementing automated testing?

  • Can QA Automation improve productivity?
What should be automated?
The following diagram depicts the areas and focus of testing that can and should be automated.

Can manual testing be eliminated?
We are an Agile/Scrum development shop, and our experience has proven that automating within a sprint is not advantageous. From an efficiency and effectiveness standpoint, features need to be complete before they are automated. Manual testing can and should focus on validating the new features and developing good test plans that can be automated later.

Can QA Automation improve productivity?
There are a few objectives that QA Automation can achieve.

Reducing the “QA bottleneck” that is invariably present at the end of software projects, and also where the squeeze to make deadlines frequently occurs.

My other observation is that automated tests take less effort to run than manual tests, and as a result they are likely to be run often. This alone can increase your confidence in the software.

When I look at QA automation, my philosophy matches my opinion of manual QA, and is that you don’t want to be in the business of “testing your way to quality.” If you feel that you have a large number of defects that are occurring in the system test phase, look for other areas to improve in your software development process. Perhaps you need to improve your requirements definition, or improve on design and code reviews – preventing defects from finding their way into the code in the first place.

QA and Development Role in QA Automation
We have experimented with using traditional QA and Software Developers paired together. This has proven successful, and I think that pairing leverages strengths that both professions bring to the table. The first area that I explored was the subject of unit tests. There are those who state that the developer is the best qualified resource to write unit tests, because the developer knows the code. I don't share this opinion!

Yes, the developer knows the code, and therein is the danger. Most developers that I know aren’t good at testing. One of the reasons for this is that if you know the code, you are likely to be thinking in terms of the “happy path,” – how the code should function – and not in terms of the fringe cases that a good QA tester will consider. Pairing can produce better tests.

I asked about experiences that those in attendance had with Test-Driven Development (TDD), where you start with unit tests that fail and then write code to make the test pass, but no one in the audience had any real-world experience to share.

My take is that TDD is useful, particularly since the book The Art of Agile Development noted that this forces developers to think in terms of interfaces first and implementation details second, providing a design that is more comprehensible. I would advocate the QA could help strengthen the tests here as well, for the same reasons noted above.

Conversely, we’ve found that Development can help QA. They can help QA with things like code organization and source control. Developers naturally have a lot of experience with the design and development of common functions, and can bring practices like design and code reviews to the QA Automation table.

A group discussion yielded some more perspective on this, the main takeaway being the realization that it was possible to get into QA Automation without considering code design and management. And just like any software, you could end up with spaghetti-code that is difficult or impossible to maintain, neutralizing any gains from your investment in QA Automation.

The bottom line for me: QA Automation is an investment, and you need to consider the cost of the tools, training and mentoring, script (or code) organization and management. Target those areas where there will be a need and a return for the automation dollar. Ultimately, you need to answer the following questions related to QA in order to determine if your software is truly “done”:
  • How much of the product is being tested through regularly-executed, automated testing?

  • Does manual testing adequately cover the remaining bases, or are there gaps?

  • Is your failure rate is known and defensible?

Change and Our Annual User Conference

October 23, 2009

At the end of August, I attended a user conference as a vendor. This was nothing unusual, since we are always the featured vendor at an annual conference in the fall that was essentially built around our company and product.

This year, however, we made some changes. Change was due, and it wasn’t a question of what, but more of a question of when. For more than one reason, our conference attendance has been declining, and low attendance doesn’t make you feel great as a vendor. There is simply less energy and excitement to get your blood flowing.

For us, conference attendance has been dwindling for GOOD reasons. We develop enterprise-level software for the insurance industry, and we have made tremendous strides in improving the quality of our releases in the last several years. We also do a much better job of addressing critical issues and adding enhancements on behalf of our customer base.

Needless to say, one unfortunate reason that we had higher attendance in years past was because our customer base wanted to beat us up! They felt that they needed to corner us and collectively press us to address our quality issues and their needs. As we’ve improved our delivery and paid more attention to servicing our customers, they have had less to complain about, which in turn reduces the urgency that customers feel about attending a conference.

Over the years we’ve also increased our on-site customer visits and leveraged the Web, conducting Webinars, posting information to a new Community Site that we developed, and generally have been more open and communicative. Our customers understand what we’re working on, what the priorities are, and what our challenges are because we communicate better. They also appreciate our challenges and the work that we do as a result. And again, this gives them less reason to attend a conference.

They also understand and appreciate that we have a certain capacity to continually add new capabilities to our product line. We’re not a large organization, and these days we are sized appropriately in terms of the revenue that we generate. This does place constraints on us, but our customers agree with our overall vision and direction; the big question now is: How fast can we deliver on our vision?

In general, our customers enjoy the time and dialog with us at the annual conference. But it has become very tough for us to fill up an entire conference with compelling new content on an annual basis. At the beginning of the year when we began planning for the conference, we understood that the economy was down, and we expected that our conference attendance to be down as a result both of these factors.

Fortunately, we had another option! We used to be an independent operation, but now that we are a part of a larger company, and it was advantageous all the way around to combine into one conference that represented a larger suite of sister products under one one corporate umbrella.

Of course, this change had some impacts on us. The date for the combined conference was ahead of our usual conference date, so many of us scrambled to prepare presentations and demonstrations. Not that we didn’t scramble in years past – after all, does anyone ever have as much time to prepare as they would like? I found myself scrambling in August, the month when I take a week off to enjoy the short summer that we get in Maine.

My role at these conferences is always as a speaker on one or more topics, and I typically am involved in putting together rolling PowerPoint presentations for our booth. I’ve also done my share of booth-duty in years past, demonstrating products and answering questions.

This year, the change in location and the moving up of the date changed our original planning. I was slated to co-present on QA Automation. As a development manager, I have been involved with QA Automation efforts at our office this past year, in part because I allocated a developer to assist in this effort.

Changing of the timing and location of the conference left me in to my own devices – I was suddenly the only presenter! Fortunately, I have given my share of presentations over the years, so this did not produce any anxiety. I did need to spend some time thinking about just what the heck I was going to present, however…

Next post, I’ll cover my thoughts about QA Automation, using material that I pulled together to present at the conference.

Are You Committing Your (Business) Tanks?

October 16, 2009

This post is off-topic from my usual software development-oriented posts, but given the state of the economy and that scaling back is the order of the day, I thought I would branch out and discuss tactics for managing/leading through tough times.

“I’m committing my tanks!”

This quote is from the World War II movie The Battle of the Bulge, about the siege of Bastogne. As American field commander General Grey makes this statement, I noticed that he did so in an animated, excited, and delighted manner. Why would a general, who is committing to a battle where people in his command will die, be delighted?

Before going on, let me acknowledge that this film was NOT critically acclaimed by movie war buffs. I do happen to enjoy war movies myself, and watched this for the first time in years because I picked up the movie on the cheap. I’ll confess that I did enjoy watching the movie more as a kid than I did as an adult, but I digress.

General Grey wasn’t delighted about committing his tanks because he was being a blood-thirsty jerk. It was because the time for analysis and speculation was done.

For the record, I do not have any military experience, but based on the military history that I have read, generals – like business leaders – do not always have complete information. They have to rely on the information that they have at hand, the opinions of their subordinates, and their own experience and judgment.

And most importantly, they need to make a timely call. To delay and wait for full information can cost them a battle. Indecision – and the time wasted as a result – can cost armies the value of surprise and position along with providing the enemy time to strengthen its reserves and better position itself while they are scouting you for weaknesses.

A lack of commitment looses battles. If you are going to attack, attack to win. This is why General Grey was delighted. He recognized that he had all the information that he was going to obtain within an acceptable time frame to engage the enemy. Furthermore, he was done deciding what action needed to be taken. He had committed himself and his army in a decisive direction – now he could focus on making that direction a success.

From a military perspective, battle is chaotic, typically lacking the clarity that would make most of us feel both comfortable and assured. The business world is no different. You need look over the landscape, collect what information that you can, and then provide the troops with focus and commitment. And I’m not the only one who thinks this way.

In his book: Andy Grove The Life and Times of an American Business Icon, Richard Tedlow quotes Andy Grove about the tendency for people to hedge their bets when faced with uncertainty. Andy Grove doesn’t pull any punches: “Hedging is expensive and dilutes commitment.” Grove states that you need “exquisite focus.” The observation being that without commitment, “you will always be looking for a way out rather than a way to win.”

What is your business doing in this uncertain economy?

Now is the time to be investing and positioning for the future. Downturns in the economy cause people to react cautiously, cutting expenses and reducing investments to improve today’s bottom line. This can cause long-term loss of market share and strategic position, creating an obstacle that is more difficult to overcome later. Here’s a quick, 5-point list on ways to take advantage of a down economy to strengthen your business.

Keep the R&D Dollars Flowing
Don’t sacrifice tomorrow for today! Assess the return on investment on everything that you are doing, and keep your business focused and committed on those activities that drive your economic engine and competitive edge. Cutting “investments” to save a few dollars today is really nothing more than hedging your bets – and slitting your own throat.

Don’t Skimp on Sales and Marketing
Because companies are looking to save on every expense possible, you can grab business from your competition by offering a lower price. Doors that have been previously shut because companies “already had a solution from another vendor” may open if you can provide goods or services at a lower cost. Keep your sales force active and knock on those doors!

Likewise, advertising budgets get slashed by many companies in bad economic times. You can use your competition’s cuts to your advantage – by keeping your business visible while they are not.

Now is the Time to Hire
Layoffs have created a large pool of great candidates. This is something that will not continue indefinitely for more than one reason. First, the economy WILL turn around, and jobs will be created. Secondly, and in the United States in particular, the baby boom generation is getting older and looking towards retirement. There are simply less good people that will be a part of the labor pool in the years to come.

According to research by McKinsey, "finding talented people (is) likely to be the single most important managerial preoccupation for the rest of the decade.” The problem is that "too many firms still dismiss talent management as a short-term, tactical problem rather than an integral part of a long-term business strategy."

Provide Great Customer Service
Give customers a reason to stay with you – and recommend you to their friends and acquaintances. Treat your customers like gold, and provide them with exceptional service. This will pay dividends in today’s connected world; consider all of the Facebook and Twitter word-of-mouth that can spread in the form of guerrilla marketing if customers have a great experience with you – including recommending you if their friends have negative experiences elsewhere.

Look for Acquisitions
Now is a great time to shop for acquisitions that can strengthen your business. Acquisitions always present risk, but there are great opportunities at bargain prices today relative to a few years ago, and this represents opportunity. The right acquisition could substantially improve your competitive dynamic.

Some related links if you are interested in more:

Starting Up in a Down Economy

Taking Advantage of a Down Economy With Investment Hiring

5 Strategies For Business Prosperity in a Down Economy

M&A: A Smart Strategy in a Down Economy

Can Software Projects be Predictable?

October 9, 2009

I’ll answer with a qualified “yes.” But should you really desire something else?

Predictability can be achieved, but not without cost. And the larger the project, the higher the price. (And the price is not linear, as noted later in this post.)

Large-scale projects have more requirements – and thus more product features. More features mean more components, more interfaces between the components, more behavior expected of the software, more testing, and more sleepless nights than smaller projects. After all, getting a large number of features correct, and operating correctly with one another, is a challenge in and of itself.

When talking about software project predictability, the most common definition of success is really about predictability, the delivery of projects:
  • On Time
  • On Budget
  • Of High Quality
  • With the Expected Features
Am I talking about a waterfall project? Let's say that I am.

Given all of these constraints (including the choice of a waterfall methodology), predictability becomes a function of:
  • Clear, unambiguous, well-understood requirements that will not change during the course of the project.
  • Estimation and work performed by experienced, competent professionals who can and will work together as a team.
  • Project scheduling performed by experienced, competent project managers.
Note that I’ve made the target that the project team needs to hit crystal clear right out of the gate. In addition, the software requirements need to be clear; they must be expressed clearly to the satisfaction of the project team.
This alone requires a skilled job performed by those responsible for crafting the requirements, plus an investment in time to ensure that the project team understands the requirements.

I’ve also added the rule that the requirement cannot change during the course of the project. Getting the requirements right, ensuring that they are understood by the team, and managing change is a big part of meeting the predictability/success criteria. This requires an up-front investment of time that before a project actually begins; and the more requirements to be addressed by a project, the greater the investment in time required.

It shouldn’t be too difficult to see that I’ve also stacked the deck with experienced, competent people – the “secret sauce” to any successful project. Good, experienced, competent professionals will not take undue risks, and they can be counted on to work a project to completion, hitting their dates with quality. I’ve also stipulated that they can and will work together as a team, something that is easier said than done.

What else drives unpredictability?

One of the problems with predictability in software projects is that they are the most unpredictable in the early stages of a project. This phenomenon is reported by Steve McConnell in his book Software Estimation: Demystifying the Black Art. It is known as The Cone of Uncertainty.

The cone is largest the earlier in the project life cycle you are. The cone narrows from uncertainty to certainty as different stages are reached. Steve McConnell points out that a significant narrowing of the cone occurs during the first 20-30% of the total calendar time for a project.

What happens when someone asks you to take extra time to work on your estimate, so that it contains less uncertainty? Nothing that makes the estimates any better than the already are. Improving the estimates requires working out the variability that drives the uncertainty, and this means performing the actual work of the project.

What else contributes to software project uncertainty?

In a word: People.

Let’s face it; everyone has their strengths, weaknesses, preferences, and idiosyncrasies. Some mixes of people work better than others, and no matter what it takes time for people to understand each other and balance out each other’s strengths and weaknesses so that they can work effectively as a team.

In the real world, you will likely have a mix of seasoned and less experienced personnel on a project. It simply isn’t economical or feasible to staff each and every project with people highly experienced in the position required for a project. People need to learn and grow, and they will need new experiences to help them grow.

Giving people new experiences and challenges is a great investment; your organization gains bench strength and providing new opportunities and challenges keeps people happy and motivated. This will sacrifice some predictability, a risk that can be mitigated through mentoring and additional oversight.

If you attempting to predict one project's completion based upon another project, keep in mind that studies have proven that software projects are not linear in nature. Referring back to Software Estimation: Demystifying the Black Art, Steve McConnell points out that if a 10,000 lines of code system required 13.5 staff months, a 100,000 lines of code system should require 135 staff months, but in reality it requires 170 staff months.

The amount of people involved with large-scale projects introduces extra overhead, part of that being extra lines of communication. And when there are more people and more lines of communication, the greater the opportunity for miscommunication to occur.

Is predictability all that you care about? Consider this: Time will likely change your perspective, especially in today’s fast-paced business climate. What you think is a priority today many not be one tomorrow.

Instead of being predictable – like predicting what you need software to do one year from now – another option is to be fast and adaptable. Be prepared to embrace changing conditions and circumstances by building smaller software projects that focus on the high-value, high-return features first, deferring on the rest.

Smaller projects enable a faster return on investment; the quicker that the software is in use, the sooner that a return is provided. Decisions to continue to enhance the software to provide even greater return can then be made. In a worst-case scenario, a smaller project enables you to fail fast, and with less expense incurred.

Improving Results Through Better Collaboration

October 2, 2009

This is the final post covering how one of our software teams made some modest changes and went from struggling to high-performing, all within a short period of time.

Understanding the requirements was the first important improvement. The next two improvements related to estimating and collaboration – beyond the improvement already achieved between the product owner and the team.

One clear reason that this team struggled with meeting its dates was because they were underestimating. A good understanding of the features (backlog) and streamlining some of the tasks helped, but they needed to make a couple of other adjustments.

The first was that there was no team estimation process. For example, individual developers would go off and determine estimates for the items that they planned on – or thought that they would be – developing. They also were estimating work in fairly significant (for Scrum) chunks of time. I asked that the team use tasks that were no greater than 2 days in size, and that they collaborate and discuss their estimates.

I’m a big fan of team estimation, and the experience with this team supports this concept. Once the developers began discussing their tasks collectively and exploring how they were going to approach each user story, they gained a much greater understanding of what was truly required. The combination of smaller task sizes and greater collaboration increased their confidence that they could meet their objectives.

As the team saw the benefits in collaboration as part of their planning and estimation process, they were receptive to moving towards greater team collaboration across the board. While the team was using Scrum development, it really looked like a mini-waterfall project where Quality Assurance would develop test plans and would wait for Development to be complete before any testing would begin.

Over a period of a few weeks or so, the team moved towards collaborating across the board. For example, each time a developer finished even the smallest piece of functionality, he reviewed it immediately with QA. And if the team encountered one of those inevitable “we didn’t consider this” scenarios, the team huddled together to discuss what that meant to the user story, to their acceptance criteria, and their commitments.

Did you catch the subtle change? The team took ownership. It wasn’t QA’s acceptance criteria, it was the team’s acceptance criteria. The team also started collaborating this way on their own; they had seen the benefits of collaboration and embraced it.

The Result
This team moved from merely performing individual tasks to being an engaged, motivated, collaborative team. They started to own all aspects of their work – as a team. As they moved from being a collection of individuals to a true team, you could almost feel the spirit and the flow. The output of the team visibly increased, overtime ceased, and everyone looked much happier about their work. Being successful will do that.

Looking back, I got a little lucky. One of the factors in this team’s rapid success was the willingness of the team to try new things. They were competent professionals, but they were unable to implement the key concepts of Scrum development – despite the fact that they intellectually grasped what “it” was.

Sometimes people get set in their ways or lack the ability to see how to apply concepts in their day-to-day work. Changing methodologies can necessitate changes in expectations, and these new expectations must be clearly communicated. Other times, people are simply skeptical.

In our case, it was a combination of factors that included some skeptics, but they put aside their skepticism and tried something new. And they ended up loving it. It was a pleasure to be a small part of this, and definitely one of those "Yes!" moments to see them succeed.

Improving Results Through Understanding the Requirements

September 28, 2009

As I mentioned in Those Satisfying Moments, I took up the charge of being a coach for one of our Agile/Scrum teams that was struggling. This team went from being challenged and working overtime to kicking butt, no overtime required! This post covers some simple changes that allowed this to happen.

My first day spent with the team involved a backlog review. The goal was to review the product backlog and re-evaluate the story points that had already been estimated once before by the team. (Story points are relative units of size for those who are not used to the agile vernacular.) Once this was complete we could use the team’s prior velocity determine what the release date could and should be – versus what some of us had in our heads as a release date.

As I sat with the team to review the backlog, Problem #1 immediately surfaced. The Product Owner pulled up a spreadsheet on the large screen that contained the backlog in priority order, with story points assigned. I hadn’t seen this spreadsheet prior to the meeting, but I was the only one in the room who hadn’t.

The team needed to review the items on the spreadsheet, validate or change their story points based on a (presumably) better understanding of what needed to be built because they had been building portions of the system already, and then determine their target end date. It seemed simple enough, until I started looking at the spreadsheet in detail.

I was having a difficult time comprehending what I was looking at. I listened while the team began to discuss the backlog, but part of my brain was occupied with the backlog itself. The team didn’t seem that engaged in the review, either. It only took me a brief amount of time to figure this situation out.

The backlog was a mix of user stories, which are supposed to be simple way of capturing what users want out of the software, and some very specific tasks. And some of those tasks were thoughts about how a one large user story could be handled. Stop right there!

(In fairness, we had experienced a change in Product Owners, so this spreadsheet was a mix of what a prior Product Owner had provided and the new Product Owner what the new Product Owner was still getting up to speed on.)

I made my observation to the team and suggested that we begin with just user stories, leveraging the information contained in the spreadsheet, but clarifying what the users wanted and needed in a way that was understandable to everyone. I got up on the white board and we began crafting user stories with the Product Owner, in front of the entire team.

Some stories were carried over from the spreadsheet. As I mentioned, other stories were tasks, not stories. From my standpoint, I wanted the team to feel committed, to have a sense of ownership. And in order for that to happen, the team needed to understand what we wanted them to accomplish.

As we crafted the user stories, a greater sense of the needs of the customer emerged, in my mind and in the minds of everyone on the team. Two important developments subsequently occurred.

The first involved a user story around reporting needs. Once we took a closer look, there was no real definition provided. Product Owner, that one is yours.

The next one involved working backwards and exploring what some of those tasks in the spreadsheet were designed to achieve. As we discussed the business process and condensed the tasks into a couple of user stories, one developer spoke up and said, “It seems like we’re making the user go through a lot of manual steps.”

This prompted something in the back of another developer’s mind and he said, “How about combining some of these steps and automatically generating the end statement, by-passing the manual, intermediate steps?”

Cha-ching! Now we have a better solution! If we had estimated, built, and tested the solution as presented, we would have missed a significant opportunity for collaboration and a meeting of the minds between the business representatives and the developers to produce an optimal solution. We entered that “ah-ha” zone:

Overall, this planning session helped to tighten up and clarify the requirements, improved the collaboration between the Product Owner and the rest of the team, and provided the customer with a better solution than what had been previously considered.

Everyone involved now had a greater insight on what needed to be achieved, and because of their participation they now had a greater stake in the solution. This alone paid motivation dividends, but there was more.

The conclusion in a couple of days…