Skip to content 
Heraclitus: “Upon those who step into the same rivers, different and again different waters flow”
With the trends towards mobility, software as a service and cloud based computing, there is a need to accelerate the development cycle, with a key focus on the front end where the core feature set is defined. It is possible to borrow some of the best practices from agile software development and apply them to the management/team interface. This yields an approach where the management team (or a subset) works collaboratively with the development team to define the product in real time and in a real hurry. This can result in the definition of a large product in four to six weeks and draws out the best thinking from the organization. “Fast and good” is possible.
What Is an Agile Management Kanban Map?
This best practice lifts the essential elements of the sprint based development methodology and applies it to the front end of product development, often called the concept or definition phase. Although representatives of the management team (customer representatives in agile parlance) don’t work full time in the development bullpen, access is widely available. The sprint process is initiated by taking a one page concept definition proposed by product marketing and shaped by a representative of the management team (typically the VP of Marketing or CMO). This is brought into a working session with the core team (four to six including quality and user experience) and the management team (three to five C level managers that oversee the business unit).
The outcome of the work session is a refined and extended product concept description. The set of requirements are broken into three groups – “Candidates”, “In Process”, and “Defined”. The “Candidates” are those requirements that are yet to be discussed, “In Process” are those requirements which have been presented but have not been finished (or lacking full agreement). The team goes off and works on the open requirements and iterates the definition with the customer representative. In no more than two weeks from the first session, the team gets back together and reviews the “Candidate” and “In Process” requirements, with the goal of converting all of those into “Defined” in one or two more sessions. This process typically repeats one more time and then the project is at a point where it can move into development.
What Are the Benefits of this Technique?
Creating compelling product definitions is one of the most difficult tasks any enterprise can tackle and this methodology can help out both speed and quality. It increases definition speed because the tight loop of iteration between development and management reduces the memory loss of widely spaced (and more superficial) reviews. Furthermore, by driving it towards two to four, two week cycles, it sets time bounded expectations from the team. The quality of the definition is better because we have the collective intelligence of the organization, not just a few bright minds making the tradeoffs. Also, the management team will tend to bring more cross functional requirements into play thereby ensuring that ‘total product’ gets defined, not just the core feature set.
Which Business Problems Do We Solve?
The most important benefit of this method is that it helps organizations develop really difficult platform programs quickly. It also has the side effect of creating a common vision for the product, which really helps downstream when further tradeoffs need to be made.
What Are some Considerations?
There are many considerations that should be examined before implementing this in a given organization. Obviously, this is not a substitute for getting the voice of the customer. Collecting requirements directly from the customer (and channel partners) is as necessary here as it is in any development system. Secondarily, this is resource intensive so that most organizations would be stressed too much to have all programs in development follow this method. In this case, the executive team may need to flag programs that have attributes well suited to this method (large scope, platforms involving subsystems, new to the world or new to the company programs).
Case Study
A largest company is planning a new employee rating and evaluation system to be rolled out next Fall. The design team, consisting of an IT program lead, HR manager, and a project manager has conducted three requirement collecting workshops across the country. In addition they have created an As-is and To-be process design, and a set of recommendations to management. But after the third management review and six months of work, they seem no closer than when they started. The head of one of the businesses suggested the agile management approach because they saw how effective it was in helping their division in product development.
This head of a business unit agreed to be part of the team, not a judge, and agreed to work closely with the design team. In a matter of six weeks, by the end of the third meeting, there was complete agreement on the holistic vision of the project. At that point a Statement of Work was drafted and was used to find the software vendor and integration partners. The definition phase of the project was concluded and the formal development phase was kicked off. The IT program lead described this as one of the fastest recoveries of any project he has worked on and indicated that given the top management participation, the requirements are likely to stick.
The table above is derived from the Kanban manufacturing process (Just in Time) where the work in process is indicated in columns for each step. There are three columns in the table that shows the status of the requirements at a given snapshot in time. This is the snapshot of the project after the first definition session (and is reflected in the chart on the right at the first data point). The first column describes requirements that are known, but undefined. The second column lists those requirements that have been discussed, but not finished. The last column represents the requirements which the team agrees are done or fully defined.
The chart on above shows the progression, or burn down, of the undefined requirements over time. The vertical axis is the number of undefined requirements, and the horizontal line is the session number. The ideal chart would start with the total number of requirements undefined (all of them) on the left, and then slope down to zero by the third session. This gives the team members a sense of progress and helps them focus on completing quality definitions as soon as possible.