Tag Archives: adopting agile to reduce risk

The Top 5 Rookie Mistakes in Software – #5

Lack of Focus

(read the intro first if you haven’t already)

Call it hubris, call it ego.  Call it a lack of understanding of the market and user, but a huge rookie mistake is to try to do too much.  How many times have you heard this bit of common-sense wisdom, “It doesn’t have to do a lot, just build it to do a few key things and do those things well.”?  It makes sense right?

It’s unfortunately easy to lose sight of this little rule-of-thumb when the momentum of product roadmap overtakes you.  You browse around a competitor’s website, for example, and discover that they’ve just released a new version that has a new feature X; but you have no plans to build feature X in your tool.  Well, now you need to add feature X to your scope to remain competitive.  Or, maybe your legacy product has feature Y and your existing customers have learned to depend on feature Y to do their business.  How can you ship your new product without feature Y? Add that to the scope.

Add a hundred more components and modules and exports and reports that keep getting added and added through demands from a few sales & marketing people, some customers, your favorite SME’s and a BA.  Your simple, focused product has now ballooned into a Colossus that will take 800 man-years to release.

So, am I talking about Scope Creep?

Not at all.  Scope Creep is one of those old, pre-Agile sayings that poorly organized dev shops used as an excuse not to ship software.

Scope will always change and creep.  It’s normal, healthy and all a part of building an effective product roadmap.  To maximize the competitive opportunity of your software, you need to be open to new market information, business drivers and innovative ideas.  These will always change and add to your product backlog (total scope).  Change, scope creep, uncertainty, etc. is all GOOD, wholesome stuff in the world of software and technology. Our learning path evolves every minute of the day.  Think of it this way: if you don’t know more in 6 months than you do right now, you’re not really doing your job.

I’m talking more about confidence.  Cojones.  The guts to ship early to a market you understand.

The true challenge is having the nerve to ship your software before the entire scope is complete.  As a rookie leader, you likely won’t understand that your software team can ship a quality product with the minimum possible feature set that will bring business value – even modest business value – even if it’s only to a percentage of the total market opportunity you’re shooting for.  You probably won’t think it can be accomplished as a continuous incremental improvement of features over a time period of x-months or years.  You’ll be more inclined to want everything – you’ll want the whole scope, first time, and ship that with a huge boom – you must, as a rookie, obliterate the competition with one crushing blow.  Or, maybe yours isn’t an ego issue. Maybe you’ll want everything because you’re not confident enough in your understanding of the market and users; so best hit them with everything and maybe something will stick.

Either way, Big Rookie Mistake.

Wanting everything is obviously the wrong way to think about it both from a technical and business point of view.  The fact is, it actually takes a great deal more courage to be laser-focused and put your product out to market with a simple, lightweight vision to accomplish a few targeted things to a clear and strategic market.  There is much more of a calculated mastery in that.

And, sure, you will continue to have a product backlog of great, innovative ideas to add to the product over time.  Believe me, there’s time for that.  What the more experienced Business Leader will know is that: getting your more precicely-focused product to market accomplishes four important things:

  1. You now have commercial adoption of your product. (Reduced risk)
  2. You’ve minimized the investment needed to generate revenues. Your product is now out there making money, and you’ve spent a fraction of what your total scope will cost. (Increased ROI)
  3. You are now receiving valuable customer feedback on your product, which will help you further prioritize the next features to add. (Strategic market information)
  4. You and your team have proven that you can build and ship successful software. (Time to celebrate

Prioritize

Ok, so now if you don’t want to fall into this trap, what do you do?  The key is to prioritize the backlog.  You have 100 innovative, killer features you want to put into the product, but you only have room for 10 this realease.  Someone has to take ownership of which 10, and in what priority.  Then prioritize the next 10, and so on.  Maybe the remaining 90 will change after you’ve shipped the first 10. That’s a good thing.  KeepThis is the Key prioritizing the next 10 (or however many you choose). Have a look at this article by Dennis Stevens on Capability Analysis for some good insight on prioritizing features.

Who owns that?  Typically your Product Manager or Product Owner. Maybe you do.  Whoever it is, remember, one of the most important things for a software development team to be armed with is: What To Do Next.  Mike Cohn has some sound ideas on the Product Owner, backlog and other gems to help gain more context with this.

Stay tuned for Rookie Mistake #4.

Chris Ronak

Advertisements

The Top 5 Rookie Mistakes In Software – Intro

Introduction

It’s pretty easy to throw some software together.  Almost anyone can do it.  Simple tools, Drag&Drop screen designers, sample databases, etc. make creating a software app just a few mouse clicks away.

I used to work with a sales guy whose family owned a sheep farm that he helped out with on occasion.  After getting a bit frustrated with how disorganized his family was about managing their sheep, he decided to do something about it.  So after reading a couple blogs, he bought a “For Dummies” book and taught himself VB.  He hooked it up to an Access database and in a few weekends he had built a sheep-tracking system.  Bam, just like that.  Easy.  Even a sales guy with a mere hint of technical aptitude can write software.

As it turns out, lots of non–technical people dive into the software game.   After all, how hard could it be?Small team of developers If you can’t do it yourself, you just hire some developers, tell them what to do, and they make it work.  Easy.

It’s interesting in a way, that there are so few barriers inhibiting inexperienced people from launching a software initiative.   In their mind, it’s just a few screens, buttons & graphics – it just doesn’t look that complicated.  Even if it’s a highly-integrated enterprise system that is connecting multiple disparate systems, performing complex business queries & algorithms and accessed by thousands of concurrent users – it’s still, at the end of the day, just a few screens & buttons.  Because that’s all they see.

The odd thing is, those same individuals wouldn’t dare dive into leading-up the design & construction of a 90-storey high-rise building without experience.   It’s clear why: a high-rise is more visual, physical and the obvious immensity of it is intimidating. They know you can’t just go hire a bunch of cement workers, plumbers & electricians to “Go build me a High-Rise!”  But somehow this happens all the time in software.   Curious, isn’t it?

So, to start a discussion around this pervasive problem, I thought I’d put together my Top 5 Rookie Mistakes that both inexperienced and experienced people make in software.  There are a lot more than 5, but I thought I’d try to stop there.

I have to caveat the perspective a bit.  There are many rookie mistakes made in an organization that don’t have a direct relation to the software/technology areas (marketing, sales, business development, finance, operations, etc.).  I’ll leave discussions around those to the experts.  I also refer a lot to product and market.  Regardless whether the software is to be delivered as an internal or commercial product, these rules are the same.

Learning to DanceAlso, there’s nothing wrong with being a rookie or the new guy.  The rookie is usually the person with the most energy and enthusiasm for an initiative; and is driven by a vision.  He/she isn’t jaded by mistakes & failure and can often become the true source of life for a project.  The intent here is to help to avoid common mistakes and pitfalls of that role; not to criticize the rookie.

So, here goes.  The Top 5 Rookie Mistakes in Software.  I’ll stagger them out over the next few days. This is, after all, an agile effort.

Chris Ronak

When your project fails, it IS your problem

As Technology Professionals, we have an obligation…

It’s pretty common for software projects to fail.  According to the Standish Group’s 2009 CHAOS report, only 32% of software projects succeeded over the past year. Not exactly a banner year to be sure; but even in a good year, it’s rare to hit more than 40% success. Whatever the reasons and wherever the fault may lie, these are disturbing numbers that I think we, as technology professionals, need to take ownership of and do our part to correct. (For a little background reading, have a look at this excellent IEEE paper about software failures).

It’s easy for a member of a software project team – especially developers – to up and bail out of a ‘disaster’ project situation and simply move on to another project.  There are plenty of opportunities out there for skilled technical people, so it doesn’t take much to just throw your hands up in the air and abandon the disaster for a more appealing career move.  It’s equally easy to ride-out the disaster and just show-up for work, and tune out the world around you.

The thinking, of course, is that it’s someone else’s fault, someone else’s problem and someone else’s financial catastrophe to sort out.  After all, you’re just a small player in a big machine.  It was probably a lack of requirements, poor leadership, lack of focus, too many changes, management issues, etc etc. that caused the failure, right? So, why should you take on any responsibility?

The trouble with that type of thinking is, Those People left to pick up the pieces of a software failure are left with a bitterly sour taste about the risk associated with investing in software.  They have to stand in front of investors, customers, regulatory bodies and other stakeholders to explain the multi-million dollar failure.  And you know what?  They are not happy with the 32% success rate in software projects.  It’s both expensive and it looks bad on their career.

And with all these software failures on the books, They may decide that, when faced with the prospect of investing in software products & projects – and technology in general – it is far too risky and their money is better invested elsewhere.  We really need to improve things.

So, without descending into a blame and fault discussion, let’s be honest about the burden of responsibility of software project success and failure.  While it’s true that the causes are rooted in many influences and situations in an organization, my goal in this discussion is to zero in on what we, as technology professionals, HAVE TO DO to avoid and repair the ongoing brutal legacy of software project failures.

failure-success

On the positive side, I truly believe that we’re getting better at building software. This is echoed in historical CHAOS reports from the Standish group, but it’s also something that’s evident in the many improvements and maturity in the world of software development: better tools, improved standards, and the emergence and more widespread adoption of Agile and accompanied development processes that reduce risk.

Part of the challenge is that there really aren’t any established standards in this industry.  Adopting standards is optional.  There are obviously scores of strategies to improve quality and the ability to reliably hit release targets, but it’s typically at the discretion of the development team and mostly overlooked … which is largely why we’re at a 32% success rate.

So, to start with: whether you’re a manager, developer, product owner or business person, here’s a bare-minimum list of what your software development team should be doing to improve your ability to build and ship quality software:

  1. Continuous build on an independent build machine.  Check out Continuous Integration for more.
  2. Improve team communication through daily Stand-ups or Scrums
  3. Integrate QA into your development team and development cycle
  4. Keep your software in a continuous working state. Only the code that’s checked-in should be considered as valid working code.
  5. Ship your software product often – like every week. Even if it’s just to internal stakeholders.
  6. Divide the release cycle into manageable chunks (sprints, iterations)
  7. Remove barriers between the technology teams and the rest of the company or to customers. Invite users/stakeholders to regularly see your working software in progress
  8. Adopt best practices around: peer reviews, QA, exception handling, coding standards.

Each of these simple process improvements vastly reduce risk and increase the chances for success.  These examples are only a scratching of the types of methodology/process upgrading that teams should be adopting, but I believe if ‘most’ teams were to do only those things, the number would dramatically move from less than 40% to well over 50% success.  Still not great – and I’ll address some more deep reaching improvement concepts in upcoming discussions – but if more teams and technology professionals were to adopt a sense of ownership in improving the global perspective of software project reliability, we can avoid a most certain backlash in the availability of technology investment dollars.

Chris Ronak