Office of the Flywheel

If you’ve worked on or managed development projects, you’ve come across or read about many of the various product development workflow options. Each development methodology has some great points, and I can understand how they came about within the contexts of their creation. It is fair to say, however, that extrapolating solutions to a generic “works for all” program will always need adapting when applied to your organization.

Another issue is that if you become fixed on any one methodology, the rigidity of your process can become quickly become a liability. To avoid this, it is important that team members are willing to adapt to the implementation of your specific process.

Forming the right hybrid approach may initially sound like a risk, and I will admit that this is a possibility. But in reality, the level of risk is nominal assuming two important things:

1. Your organization’s executive staff is capable of establishing and correcting strategic direction as a collective group

2. Your organization has product and project managers capable of forming and managing the right hybrid approach

Generally I like the PACE (Product and Cycle Time Excellence) model at the business / strategic level. Teams and rolls are understood, a meeting cycle is easy to establish, and the options for handling ideas and projects in the pipeline are straight forward.

Once a project is approved for initial planning (phase 1 in the PACE model), I like to create a preliminary set of wireframes or schematics. These are a great way to visually intimate the feature set to both business people and software engineers. I also like to develop a waterfall style project plan to assess the timeline and resource scope – but hang on one minute fans of the agile methodology.

Fans of the extreme programming methodology probably cringe at the notion of creating too much documentation. I understand the fluidity agile methodologies bring to the table, and the agile method SCRUM is my preferred approach once development actually begins. But in my opinion, there is a struggle for power and control. Historically the waterfall model has allowed the business administration to micromanage development. The polar response is XP, which allows the engineers to take the concept and run with it with little “interference” from administration.

In my opinion, the sensible solution is a middle of the road approach. Iterative development does reduce risk, allow for fast course correction, and quick concept to market development time lines. All of these are huge assets. Understanding product requirements, resource needs, scope, and timeblines are essential to making a good business decision and thus necessitate the need for documentation.

The good news for each side is that the brunt of the work falls on the product development team. As they manage the process, they create the required documentation and work as needed with both sides throughout the course of an iteration to ensure that things are going according to plan.

Moving into development then, there is a hand off from the business / strategy team to the development / engineering team. Once that transition takes place, the development team has the authority to plan and make adjustments as needed to meet their deadline. A daily standing meeting is a great way for the development team to stay in sync and ensure that the various development efforts are properly organized.

The length and depth of testing is flexible. Typically I assume that for every 3 weeks of development there will be one week of testing / bug fixing. Some teams like 2 week iterations or “sprints”, but in my opinion this leaves little time to effectively find, document, and fix bugs. Development cycles longer than 4 weeks (3 weeks + 1 week of testing) start to grow too large for a manageable feature suite in my opinion, and create a longer time to market for features.

Once reviewed and launched, it is time to get feedback from the most important group – the users. Developing automated reporting on performance and use has so much value you just have to do it. Web based applications can take advantage of analytics reporting tools such as Google Analytics. Software can collect and send this information with the users consent. You should also think about providing a simple feedback mechanism. Even brick and mortar stores such as Starbucks have been proactive in setting up websites that collect ides from their customers. At the end of the day you are in business to make money, and gathering ideas and feedback from your patrons can build community, loyalty, and great products.