Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Introducing outside-in development

A short guide to stakeholder-based application development

By Carl Kessler and John Sweitzer, JavaWorld.com, 09/20/07

"The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns [is] just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars."

--The Standish Group

Have you ever been part of an extremely successful project? If you have, just asking this question probably has you flashing back to those days with a smile on your face. These are the projects on which members of the team really clicked. The team members grew stronger as the project progressed because they overcame challenges that at times had them wondering whether they could finish the project.

If this quintessential project delivered a software product, its success included delivering precisely what your clients wanted. You may have had a set of early customers ready to buy and become sales references the very day your product shipped. Certainly you were a member of an empowered and productive development team!

Outside-in development techniques are intended to help you re-create this success on every software product you work on. If you're like us, you want to hear applause from your clients when your product is complete, and you want to know that your hard work has paid off by positively affecting both the people who use your product and your business.

There may be challenges to overcome

Let's look at the opposite experience.

In this case, you were probably overwhelmed with problems.

Perhaps the consumers of your products complained that the software did not work well or was hard to deal with, or that it didn't integrate with other key applications (even those your team built) or worked too slowly.

Maybe these complaints were valid. In fact, maybe you'd have said the same thing if you were one of those users. So, what was the problem?

Could it be that those folks in IT operations were not providing sufficient compute horsepower for your code to run? If that was your first response, we'll challenge you to do a better job of viewing the operations team as a key stakeholder in your effort. You can help them keep you both out of this mess.

Is it that you just can't put your finger on what to change? Folks have told us, "Over the past 20 years, we've had more task forces than we can remember look at ways to deliver better software, and nothing has significantly changed. We just don't know how to do better."

Consider a different way of thinking about software product development

Outside-in software development is first and foremost a way of thinking about building software. It keeps the focus and energy level of the team on the people who will ultimately engage with and benefit from the product. We call these folks stakeholders.

Outside-in thinking asks you to be explicit about whom the stakeholders are for any of your development projects, and knowing that, to gain a clear understanding of their goals. This clarity reduces the chance of building code that won't be used or misses the point. It adds visibility to prioritization decisions and which stakeholders are affected by them. It also improves the effectiveness of conversations with the stakeholders, to maximize learning for you and the potential clients, partners, and end-users of your products.

You are probably familiar with multiple development processes, methods, and tools. This is not about another development process model. It is about ways to build software that matters to clients. It is about the thinking the team does together; how it solves problems together; how it decides what is important.

Consider some proven techniques as well

Delivering a product that allows clients to achieve their business goals demands a variety of good practices and a way to continuously improve upon them. Our practical approach to outside-in development includes many of these proven techniques.

In practice, outside-in development increases the likelihood that a product's users will be able to benefit from the code. For the development organization, this results in achieving your business goals, gaining higher customer satisfaction, and experiencing less project risk. It means better alignment of design-to-market needs, so the development team can achieve more for its time and effort. It drives toward higher-quality code which will have been built and tested in real usage contexts. It encourages excited and productive developers, because it is more fun to understand why you're building something, and more empowering to have clarity of goals. It very importantly leads to more effective deployments, because of the holistic and complete definition of stakeholders.

It takes a whole team to succeed

The basketball player, Bill Walton, said, "Winning is about having the whole team on the same page." This is as true when building a software product as it is for playing any team sport.

Outside-in thinking has the most positive impact when it is used throughout an organization. Success occurs when technical teams of every specialization, along with managers and executives, all understand and encourage outside-in development. So, whether you are a coder, tester, writer, product planner, team leader, manager, or executive, we expect you'll find material here that you can use.

A whole-team perspective is essential

We define development team very broadly: We include, of course, coders, testers, technical writers, designers, support engineers, and architects, as well as user interface designers, performance stress testers, and all sorts of other specializations. Importantly, we also include marketers, sales executives, business strategists, product managers, business development specialists, product pricers, other finance types, and services folks as well. In our view, successful software product development is more than simply successful coding. Winning products are built by effective, cross-functional teams.

The stronger your complete team is the more fun you'll have and the more successful your product will be.

Realistically, though, some teams are stronger than others, and some teams are not strong at all. If you feel that's the situation in your development shop, don't despair. Instead, use a conversation about outside-in development techniques as a way to generate more whole-team behavior, or to help your colleagues get excited about making some changes that will improve your product. We've seen for ourselves that small successes often lead to enthusiasm for additional changes. In fact, culture change in any organization, large or small, seems to happen best when it is driven from individuals, taking their own opportunities to demonstrate leadership, and driving incremental and positive change through their teams.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.