The Next Wave: Valuable Products First, Process Second

I'm hearing the word "value" a lot lately. This is partly because the economic downturn has us looking to get the most for our money. But that's not all. More and more managers, business analysts, programmers and testers are talking to me about value. They are concerned that their products provide value for their end users. Many of them express a kind of process or tool fatigue. They are tired of being told that using a particular process or toolset is the key to their success. To them, value is a more important concept.

Here's an example: I presented a keynote on value at the Better Software conference this past June. An audience member approached me afterwards and told me that the value message is "missing from our current conferences, articles and other conversations in the software industry." He had moved from another industry into software, and was puzzled that we weren't as focused on creating value for our customers as other industries. Sure, processes, tools and practices are very important, but they should work to serve us as we create value.

What is value? Value is what's important to our stakeholders. We need to create value externally, for our end users who pay for our software and rely on it to help meet their needs. We also need to create value internally, for the owners of the company, for our team members, and for ourselves. If we create value for our customers, that ensures our success as a company. People will buy our products and services, and recommend them to others. If we create value for ourselves, that ensures our success as an organization. Staff members will develop their skills and be productive, will stick around and contribute. Some companies don't really deliver value to anyone; they burn through their capital for a while and then disappear. Others are successful at delivering value to their customers, but grind up their staff in the process. Their success is temporary because they can't sustain value creation.

While that sounds straightforward, I still run into business leaders who don't seem to understand that they are in the business of creating value. And many teams lose sight of value because they are much more concerned with following a particular process.

From Software Ideas, to Process, to Value

"The New Methodology" by Martin Fowler has a phrase that sticks in my mind: "From nothing, to monumental, to Agile." Fowler was describing an evolution of software processes that move from no process, to a very heavyweight process, to something more lightweight, or agile.

I've noticed a parallel phenomenon with software development projects/products. We often start out with an idea for a software product. And we make a start developing the product. After we experience problems with inconsistency and reliability, we add process. Without formal processes, the team can lose control; duplication of effort, lost productivity, and a whole host of errors can creep in. After we experience the positives of consistent processes, we tend to elevate their importance.

Finally, we realize that process is only part of the picture, and it's more important to create software that our users value than to have a stellar process. We realize that while process is important, it isn't everything - process should help us create value, not be the end result.

Post-Agilism, a Transitional Movement

Six years ago, I met my first post-Agilist. I didn't have a label in my mind at the time and was puzzled. They were deeply experienced with Agile methods, but were suffering from Agile process fatigue. They supported many Agile practices, but didn't identify with the movement anymore. They felt too constricted. The Agile movement seemed too rigid for them because they couldn't try out ideas that were deemed to be "not Agile" as they made attempts to adapt their toolset and process mix as they tried to ship valuable software.

I noticed more and more people who were out of step with an Agile-obsessed development climate. They were creating a fusion of processes and tools on their projects: some Agile, some deemed more "waterfall" and some were just traditions of their particular teams. They were adjusting as conditions were changing, but they faced a backlash from process purists.

While talking to a colleague about "post-Modernism", the term "post-Agilism" flashed across my mind. What I was witnessing seemed to parallel the post-modern movement. The Agile movement, with its rules and rigidity about following process, sounded more like Modernism. Finally, in June 2006 I wrote a blog post: "Post-Agilism: Process Skepticism," coining the term. I had a couple of motives. One was to describe something I was observing and that people weren't talking about. The second was to encourage people who felt restricted by Agilism to use whatever combination of tools and processes helped them get their work done. I wanted to provide something to point to and rally around if people were creating great software, but facing adversity because they weren't following a process to the letter.

At the same time, Jason Gorman wrote an article: "Post-Agilism: Beyond the Shock of the New" independently co-coining the term. Jason knows more about post-Modernism than I do, and you can certainly see a Dada influence in some of his post-Agile work.

One problem with post-Agilism is that it is more of a reactive concept. Ok, so we have Agile influences in our work, and we use other ideas as well, but what is the point? Is this just a reaction to the Agile movement? I felt there was more to it, and a couple of other people helped add clarification.

The first was Kathy Sierra, a thought leader in Java and user experience work. She latched onto the post-Agilism term, hoping that it would lead to a focus on the end user being "king". Instead of just satisfying them, we would nail down their needs and create software that makes them feel smarter and helps them do their jobs better. She calls that part of a concept called: "flow". That's another expression of value. Not only does our software make them happy, it helps them in ways they didn't anticipate.

Something else became apparent. People started contacting me and telling me that they felt left out by the Agile movement. At first it was user experience workers who felt shut out of the Agile movement. They felt that under post-Agilism, there was more tolerance for their roles than within Agile teams. Others came forward and said that the Agile movement was over-simplifying and needlessly diminishing their roles. These people included testers, documentation specialists, project managers and business analysts.
I was also contacted by people who were using iterative/incremental lifecycles, but were staunchly against the Agile movement and tools, saying they were an over-simplification. While they didn't consider themselves to be post-Agilists, they identified with applying a combination of tools and processes to solve problems. After all, there is a lot more to software development than "Agile" and "waterfall."

Another clarification came from Philippe Kruchten, a computer scientist, and programmer. Philippe mentioned "value" as an over-arching concept in post-Agilism, and that helped focus my public work . Value is what makes Post-Agilism is an interesting idea to explore. Post-Agilism as a transitional concept that helps lead people away from a process fixation and toward something greater: value.

Ensure Your Tools and Processes are Helping you Create Value

I don't really care what people do on their teams to create value. If Agile processes work for you and your team, that's great. If non-Agile processes do the trick, go with them. I usually observe teams developing a combination of tools and processes anyway. Instead of feeling bad for not having a by-the-book process implementation, you can use this as a source of pride in your quest to create value.

Here are some tips for shifting your focus from process to value:

• There are no industry standards on how to create value for your stakeholders. You need to figure that out by talking to and visiting your end users. You also need to identify and talk to stakeholders on your own teams.

• Once you figure out what value looks like, hold your processes and tools to account. Make sure that value is the guiding concept over and above your tool and process implementations. Also, realize that there are lots of service roles that are just as important as programming. Get people like testers, business analysts, documentation specialists and user experience analysts to help.

• There is no set formula for success. Be suspicious of anyone trying to sell you a simplistic formula, whether it is a process or tool.

• Your value implementation will not only be unique (you and your team are unique after all) but it will need to change over time. Nothing is static, so be sure your tool and process mix doesn't grow stale. If it does, stakeholders are no longer getting value out of the process.

Finally, don't just try to satisfy your customers, try to blow them away with value. Help them do things they couldn't do without your software. Don't just automate a business process; use the power of technology to provoke their brains to solve problems and to feel more confident in their work. Remember to create value within your team, or you won't be able to sustain value creation for your users. If your process and tool mix is effective but isn't easily categorized, don't worry. If you are creating value, does it matter what your process is called?

Author: Based in Calgary, Alberta, Canada, Jonathan Kohl is the founder and principal software consultant of Kohl Concepts, Inc. A noted software testing thinker and strategist, Jonathan is a natural investigator on software projects. In addition to assisting teams with testing, Jonathan helps companies define and implement their product vision, coaches practitioners as they develop software on teams, and works with leaders helping them define and implement their strategic vision. Jonathan is also a popular author and speaker. His blog on software development and testing issues is one of the most well-read testing blogs in the industry. Jonathan is a regular contributor to Better Software magazine, both as an author and technical editor. Contact Jonathan at http://www.kohl.ca/.

References