In April, Jeff Patton (with some help from David Hussman) did a presentation for our Agile Denver group called "No One Wants Your Stupid Process." If you aren't familiar with Jeff's work, check his website at www.agileproductdesign.com, or just start Googling.

One thing Jeff talked about was how some teams use their software development process as a defense: "It's not my problem, the hole's in their side of the boat". We often hear this attitude from a test team when developers introduce lots of bugs, from a programming team who feel the testers didn't do enough work, from a development team whose business managers make poor decisions about which features to release, or from business managers who feel their development team failed to deliver. The truth is, though, that we're all in the same boat, and if someone knocks a hole in it, we'd better all start bailing water.

The importance of fully understanding the business side of our company was drilled in to me a few years back. I, and other members of my team, had conversations with Tom and Mary Poppendieck (http://www.poppendieck.com/) in which they told us success stories of software teams who reaped huge benefits from sitting with their business people and learning the whole business. At the time, our team was doing a good job delivering high-quality software at frequent intervals. But we sometimes misunderstood what our business folks needed, and we spent a lot of time fixing human errors in our system. 

We divided up the different areas of the business and its process, and each of us volunteered to study and document an area. We budgeted time for several iterations to sit with business people as they did their jobs. We learned about critical areas that had escaped our attention when we were focusing only on the automated application. For example, I learned our accountant had to reconcile cash balances in five different accounts every day, and cash moved from one account to another outside of the automated system. We understood much better what reports she needed to help research imbalances.

We all sink if the software fails—not only our "customers." We software developers (and I include testers and everyone else who contributes to software in 'developer') need to share the business experts' product understanding. We need to know why we're building the software, not just what to build. 

Some tools to build this shared understanding are the personas and story mapping techniques that Jeff teaches. These help us identify patterns, risks, dependencies and business goals. When our team is about to start a new theme or feature, we have short brainstorming meetings in which we help our product owner and other stakeholders slice, dice and prioritize stories and think of creative ways to implement them. 

By developing in small increments and releasing frequently, we can learn more about our audience. We use a lot of big visible charts to show our progress and keep focused on the purpose behind the software. We communicate and collaborate within the team and with the rest of the business. Our management ensures that we work in an atmosphere of personal safety, where we can build trust and feel confident to experiment. 

Take a look around at who's in your boat. What are the goals of your product? To make more money? Save time? Cut costs? Start learning about your business and find ways you and your software team can help your business succeed.