Introducing Outside-in Software Development: A Practical Approach to Building Successful Stakeholder-based Products
- There may be challenges to overcome
- Consider a different way of thinking about software product development
- Consider some proven techniques as well
- It takes a whole team to succeed
- Understand your stakeholders
- Understand organizational context
- Make your products consumable
- Align with your stakeholders goals
- Define success in your stakeholders terms
- Become an outside-in developer
- The leaders role in outside-in development
- Essential point: You can get started now
This chapter is from the book
This chapter is from the book
This chapter is from the book
- “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 Group1
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.2
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.”