Wednesday, May 2, 2012

Software Development and Strategy Derived from Software Development

I found that Keith McFarland's "Should You Build Strategy Like You Build Software" to be a house of mirrors, particularly because of my experience working in a software development company. Although my previous writing on the subject focused more on the environmental sources of company success (and ultimately, exogenous sources of failure), I think that this article and its recommendations give some good insight into whether or not a "software development strategy" is really appropriate, for, well, a software company.

The company that I worked for was essentially structured like most videogaming companies: you have an executive leadership and under that executive leadership you have marketing, art, programming, and testing functions.  The one comment that will make is that when people think of "videogaming companies" such as Electronic Arts, they often don't realize that giants such as EA are both producers and publishers, meaning that they take on both of the roles and responsibilities in the supply chain. They often also don't realize that there are subsidiary studios that produce different types of games (which is exactly what the company that I worked for was--it was a subsidiary of Sega and then 2K Sports).

Now, the reason why software development strategy worked so well with the company I was at was because we didn't have to set the tone or table for our games much--that was up to the publisher to work with our marketing team to figure out how to sell the game. Therefore, we didn't have much pressure to address the business aspect of the company. We could focus on making games. All of the things that McFarland mentions--"debugging," user/developer relationships, and fast cycle times-- are all applicable concepts to our production process. But from a business strategy standpoint, are they practical?

McFarland's "Future of Strategy Making" chart illustrates his recommendations for business strategy development based on 5 factors: starting small, getting things in peoples' hands quickly, getting people to work together, integrating the best ideas available, and debugging as you go. I will comment on the fit of all of these.

Starting Small: McFarland's assumption is that "big design" should be thrown out and that "strategy scrums" should replace formal planning processes. This is partially viable. Although scrums are a vital part of the communication process between executive managers, programmers, and the other departments, it is fairly true that each game's strategy and value added should be defined so that the working units have some idea of what kind of user experience to provide. This is typically a little more involved than scrums and requires detailed knowledge into the consumer's behavior, as well as detailed information about how the competitive environment will react.

Getting something into peoples' hands quickly: Rigorous build development (i.e. creating new software versions) was the heart of our feedback process in Quality Assurance. McFarland would have been correct in saying that developing "strategy assumptions" is important, because things are always changing with the current product, and that lower level group leaders in the departments would need to react to each change.

Get people to work together: McFarland suggests that the groups responsible for strategy should be broad and include members from all parts of the organization. While I generally agree with this in principle (and this is reflected in the next section), I would advise that people are best left to their own expertise. Only executive management should be checking in with every department and adjusting the course of the company's product, because questions like "what should we put in our game" tend to raise more questions from other departments performing the work.

Integrate the best ideas available: While I don't think that EVERY single group should be included on the same level in the strategy process, I find that the ability to provide input is very, very valuable. Being in QA, I observed that the testers entered 2 types of entries in their bug data: the actual problem itself (and whether or not they were able to replicate the problem repeatedly), and any suggestions for improvement (if the problem were gameplay related). Some suggestions actually made it into the final game, believe it or not. McFarland's "strategy source code" that he suggests is the physical product itself, so when everyone in the organization has access to the "source code," suggestions can be made.

Debug as you go: The crux of my work was supporting the people doing the testing services. When bugs were identified, they worked as a team to figure out whether or not the bugs were removed in each successive iteration of a game. This was a very stringent process--"yes men" were not tolerated, and if a bug was still unfixed, the testers reported it. Likewise, in the executive leadership, the CEO, VPs, and CFO/CIO had differing ideas about how to structure each game and how to present the offering to the public via their publisher. One brief example is that of joining with 2K Games--doing so would mean a net loss of employees as many functions would be integrated between the company and their new publisher. Every option was on the table, and people didn't hold back on what they thought of the potential merger. The process of continually asking whether or not it was the right thing to do was critical to gaining consensus among the executive leadership.

So is McFarland's software development strategy applicable for a software company? Yes and no. While I believe that function and expertise should be segmented from access to input (people should do their jobs, but feel 100% comfortable offering suggestions to management), I believe that the general theme of running a "software development" strategy along with the actual software development function works, at least for small companies. With larger MNCs hobbled by different levels of governing structures, maintaining the same level of agility that we had (the company was no more than a couple hundred people) would be very difficult.

So my challenge to you on this last Strategy Development blog is this: how can you turn traditional planning processes into "agile" software development processes, and what kinds of hybridized strategy models arise out of this cross-pollination?

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.