Regardless of the industry, it is essential that Senior IT executives achieve speed to market with quality, functional, easy to use applications.  To add pressure to this objective, IT organizations must keep pace as the e-commerce world continuously accelerates, or be left to miss the market as competitors passes them up.  To this end, IT executives are championing the use of Agile techniques and tools in their organizations.  Unfortunately, if Agile is not properly implemented, IT teams are left with a new “cowboy code” environment that adds issues and problems and fails to achieve the business objectives.

Background

Although Agile has existed for many years, few structured processes have been established. This is especially true around those functions that occur before and after Agile Sprints.

In essence, a fallacy exists where individuals often claim that the establishment of any processes will undermine Agile creativity and productivity.  In reality, this attitude is very short sighted and tends to promote “Cowboy Code”, leading to inconsistencies in the look and feel of applications and hamper productivity.   However, on the other side of the coin, poorly established or excessive processes can have an equally detrimental effect on Creativity and Productivity (by reintroducing bureaucratic, non-productive work that the Adoption of Agile achieved).   As such, it is critical to strike the right balance of process control and the ability to be nimble and iterative in development practices.

The Right Balance of Processes and Standards

“Finding the Right Formula” between Processes and Creativity is the art for building a successful Agile environment.  The “one size fits all” does not work.  The correct balance of Processes and Standards to establish varies widely between organizations depending upon maturity of the organization, business in which the organization is engaged and the product(s) being delivered.  As an example, the Agile Processes and Standards for a Nuclear Applications Development group will be significantly different than those used by a non-profit Applications Development group focused on foreign mission work.  However, in both cases, a degree of Processes, Standards and Metrics is critical to building quality code quickly.

Although there are many different inputs to identifying the correct balance of Processes and Standards, the following are some excellent sources of indicators:

• Retrospect Sessions (or Lessons Learned):  Especially, re-occurrence of “Opportunities for Improvement” across multiple Sprints and multiple teams.
• Agile Story and Epic “Issues” or “Blockers”:  Especially is the essence of those issues and blockers is consistent across the Epics and Stories.
• Analysis of the activities performed within an Agile Sprint and those outside an Agile Sprint: Most organizations new to Agile will have significant functions outside the Agile Sprint.  As organizations mature, Sprints can become more activity robust.
• Company Business Drivers:  As an example, for a Nuclear Utility, quality is essential to safety.  As such, Quality Assurance processes, gateways and metrics may be critical to achieving that Business Driver.
• Quality Assurance Defects:  Especially trends in similar defects or from release to release.

Since the processes in an Organization are a living entity, removal of certain Process guidelines may be appropriate at certain times.  As an example, if the Quality Assurance function is initially external for an Organization new to Agile and, associated with the maturing of the Agile teams, it is deemed appropriate to include Quality Assurance in the Sprint work, then Process guidelines at that time may be restrictive and bureaucratic to the Agile team.  Having pre-established criteria for the removal of a Process is a healthy activity and will mitigate bureaucracy.

Metrics

All documented processes should have clear, actionable metrics to indicate the health of the process and when remedial action is necessary to address process problems.  In addition, it is recommended to have “rolling” 12 month (or longer) performance graphs with pre set “yellow” and “red” thresholds and pre-planned actions tied to crossing those “yellow” and “red” boundaries.  As with any management approach, if performance metrics and associated monitoring does not exist for the processes that exist, process issues and poor compliance to those processes will ensue.

Metrics should also be based on the processes documented, and not via a “one set fits all” mentality.  As noted in previous areas, the metrics for a Nuclear Utility’s Processes will vary greatly to those of a non-profit organization.

Finally, those metrics in a “yellow” status can be an excellent source for maintenance Sprints.

Getting Started with Processes Mapping and Metrics – Rating your Agile Processes and Metrics

A good place to start associated with Agile Process mapping and metrics is to perform an assessment of the current environment.  To this end, the following items are offered as potential activities:

• Are there significant, recurring issues and problems preventing the implementation of functionality?
• Are the “Releases” associated with Agile timely and improving or slow to market?  If so, what is the time breakdown?
• Are processes that do exist clearly documented, easy to find and easy to understand/use?
• Does the predominance of members on the Agile teams feel that the Processes and Metrics are effective or bureaucratic?
• Are metrics tied to Business Drivers, do they cross “functional boundary”, and are they “actionable”?
• Are there formal Process reviews and formal “continuous” process improvement activities?

Conclusion

Regardless of the industry or size of the group working in an Agile environment, some degree of processes with metrics is essential.  The key is to find the right balance that provides structure without destroying the Agile team creativity and flexibility.

Follow