Two Steps = Better Project Forecasts

June 28, 2011

In my prior post, I noted that there appears to be a 30 percent rule involving software projects: You’re going to spend 30 percent of your time figuring out what you’ve gotten yourself into. This places implications on the planning and estimation process that in my experience are best solved by Agile planning and estimation.

There is a tremendous amount of time and effort expended up front with traditional project planning, and one area in particular that is problematic is the tasking out of all of the work and guesstimating a duration associated with each and every task. There are two flaws with this:
  1. Software projects are the most unpredictable in the early stages of a project. A team needs to perform actual work to get their arms around the project.
  2. As I pointed out in Optimism Isn’t Just for Developers, people generally underestimate task-completion times.

Leverage Evidence in Software Estimation

June 24, 2011

Agile development and business users/sponsors are at two opposite ends of a spectrum in one respect. Developers want the business to be entirely flexible on scope or dates in reaction to death-march projects (and these are extremely painful) and the seemingly continual expectation that developers spend their days, nights, and weekends writing software – with no life whatsoever – to “satisfy the business.” The business side, naturally, wants what it wants, for a set price and delivered by a specific date.

Business people don’t care to invest their time in understanding why software projects are complex and uncertain, either. At least not in any great detail. What is one approach that you can take?

When Incremental Funding Works

June 21, 2011

Incremental funding – funding one iteration at a time – is an attractive concept. It goes hand-in-hand with Agile development's “getting right to work” philosophy where complete, detailed planning is not done up front, but spread through a project. However, I don’t believe that most projects can be tackled using a blind “fund as you go” approach. Projections have to be built into the equation, otherwise the business won’t buy into it.

Those who hold the purse strings like to understand how much money they are going to be asked to dole out and what the potential return of that investment is. The uncertainties of business means that they’re effectively placing a bet, and they sure as heck want to understand if they’re making a small bet or a big bet.

Go MAD with Agile!

June 17, 2011

Scrum, Extreme Programming, and Kanban are Agile’s Big Three, but which is better?

All have been demonstrated to work, yet all can fail.

The reality is that all of the challenges of today aren’t going to be solved by any one approach. There is no single, silver bullet that is going to work for everyone, everywhere, in every situation.

Failures will occur, despite the fact that the foundation of Agile is strong, built upon the knowledge and experience of others: Joint Application Development, Complexity Theory, Lean production, and many years of hard experience in the field of software development, to name a few. The approaches of Scrum, Extreme Programming, and Kanban reflect tremendous insight and each provide a solid framework to work from.

Early adoptions of Agile have proven to be successful, but there have been Agile project failures. There are too many variables in play – existing skill sets and knowledge, the amount of time and budget available for training, management support, the willingness of the workers to accept working in new ways, etc. – that influence success.

Book Review: Inspired How To Create Products Customers Love

June 14, 2011

Inspired: How To Create Products Customers LoveI’ve recently transitioned from being a Development Manager to a Product Manager, a move that is not a surprise to many since I’ve been dividing my time between both roles for a while now. This has prompted me to seek out books on product management, and Inspired: How to Create Products Customers Love by Marty Cagan provided me with a lot of terrific insight.

Early on, Marty Cagan defines the product management role nicely: “The product manager is responsible for defining—in detail—the product to be built, and validating that product with real customers and users.”

He also discusses the need to have a good relationship with engineering – otherwise you are “… in for some very long and frustrating days.” (True enough!) Marty points out one key to making the relationship work is that the product management/engineering relationship is a peer relationship; “As product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for building the product right.”

It is clear the Marty Cagan has plenty of real-world experience, and he does talk about something that I’ve seen become an unfortunate reality: “Few words are more dreaded by product managers than being told by engineering: ‘No more new features! We need to stop and rewrite! Our code base is a mess, it can’t keep up with the number of users, it’s a house of cards, we can no longer maintain it or keep it running!’”

The Benefits of Limits

June 10, 2011

I can see it coming. As I walk by the open area with white-board paint on the walls and desks designed for pairing, I see everyone concentrating intently at their desks, some with headphones on. People are working hard, yet there is something wrong.

The sprint ends with far less than expected velocity.

A common way that teams get into trouble is that they try to put too much work in flight at any one time and the task board morphs into “swim lanes” where people are working feverishly, but independently. The result is a race to see if the “team” will accomplish its work by the end of the sprint. This can lead to a BIG disappointment, with a lot started, but little to nothing completed.

Yet Another Agile Elevator Pitch

June 7, 2011

Let’s say that you are talking with a couple of people whose organization hasn’t adopted Agile development yet, but wants to understand why they should. They want to understand what is behind the hype. They want a good elevator pitch.

What would you use as an elevator pitch for Agile development?

We all know the history of Agile development and how it seeks to overcome some common problems with software development, but an elevator pitch needs to be something more than just quoting the Agile Manifesto and telling people that they’ve what they’re doing all along is completely wrong. Why should people change their development approach? What will they gain as a result?

Source Code: Asset or Liability?

June 3, 2011

For those who feel that source code is a liability, my immediate reaction is this: Are you nuts?

Then again, I’m an optimist. With me, the glass is always half-full. I’ll bet that those who view source code as a liability are the half-empty crowd. Or experienced developers who have shoe-horned just one more feature into code that seemed to be actively fighting back.

Actually, I agree with the reasoning behind the assertion that code is a liability. However, classifying all code as a liability – psychologically speaking – isn’t exactly rewarding. It also isn’t accurate and frankly, telling programmers and the business folks that all the time, effort and money invested in creating software nets out to owning a liability paints software development in a very bad light.