Joel Semeniuk

A great agile team is a highly disciplined team. Embracing new levels of discipline consistently across teams is tough without guidance and continual feedback. Wouldn't it be great to have an experienced Agile Development Coach entrenched into every single one of your project teams? This coach could consistently make recommendations on how to optimize your team, make sure your team accurately tracks progress and detects conditions that could lead to increased project risk. Wouldn't it be great if this experienced coach could be built right into the software you use to manage your project?

Software development teams face a constant struggle every single day. Not only do teams fight to keep up with the constant pace of change in technology and engineering techniques, but rapidly emerging methods in how we capture requirements and manage projects, sparked by the increased adoption of agile and Lean practices, adds a completely new dimension to change. Successful agile teams are typically very cross functional and self-managed and in this respect each team member needs to interpret and capture value from a customer's perspective as well as be proficient in the intricacies of agile project management and requirements management. In addition, the entire team is accountable for the software they produce as well as the triad of project constraints; time, scope, and budget. Agile methods have ushered in a new level of responsibility and, as a result, rely, more than ever, on individual discipline, team interaction, and metrics-driven oversight and monitoring. Teams that do not keep up with both technical and management best practices, end up working quite chaotically, resulting in considerable waste, resulting in a diminished ability for the team to produce value for their customers. Teams that leverage up-to-date engineering and process best practices greatly minimize waste, allowing them to work more predictably, reliably, and efficiently - which, in the business world, translates directly to dramatically higher return on investment.

Packaging best practices into software is not a new concept. For example, Lean Manufacturing methods stress that engineering and product development ultimately result in the creation of knowledge. The modern manufacturing industry, sparked by intellects, such as Deming and Tachi Ohno, promote that knowledge should be constantly created and captured in the essence of tools and processes to help others immediately benefit from new learning. In the world of Lean Manufacturing, process for the sake of process is not acceptable. Process and tooling that exist to help standardize the use of best practices in order reduce waste, minimize risk, and produce more predictable outcomes is required. More important, Lean promotes the use of standards only until better methods are discovered that further reduce waste, thus standards themselves must be able to evolve and change as knowledge is discovered and captured.

The world of software development has slowly started to follow suit with regards to industry best practice capture and reuse. A great example of this is the set of software design patterns defined and documented by the Gang of Four (GoF) (Erich Gamma, Richard Helm, Ralph Johnson and John M. Vlissides) in their book Design Patterns: Elements of Reusable Object-Oriented Software. These software design patterns provided a reference point on how certain types of business and technology problems can be solved in software. There are dozens of best practices for dozens of different problems. For example, the Observer pattern defines structure of code that is used to implement distributed event handling systems. Therefore, if your team requires a distributed event handling system, you should look to the Observer pattern as it encompasses a best practice on how this problem can be solved, which will save time and reduce risk compared to inventing your own methods that may not be as vetted as these published patterns.

Even though this type of guidance was widely available to software developers around the world, its use has not necessarily been broadly or commonly adopted. In many environments knowledge of how to implement these patterns and when to use them usually resided in a small number of highly specialized people. Not until these patterns started emerging in tooling, such as IBM Rational Rose as well as in re-usable application blocks that developers can directly consume as part of their software design and construction, were these patterns consumed more regularly. As another example, the Model View Controller pattern has been defined and used by software developers for a long time; however, not until Microsoft included an implementation of the MVC framework in ASP.NET did this common design pattern truly get utilized by a much wider group of developers on the Microsoft development platform. The ultimate realization is that best practices are rarely efficiently consumed without both processes and tooling that directly supports them.

Figure 1

There are, of course, many more examples of this. For example, developers who use Microsoft Visual Studio can use a feature called Code Analysis. Visual Studio Code Analysis is a tool that can execute a set of rules that look for code that may not conform to industry best practices. Microsoft provides hundreds of such rules that your team can use to automatically check over your code to help identify where improvements can be made (see Figure 1). For example, one of the rules Microsoft provides out of the box is a code design rule that states that "Enumerations should have zero value," which helps to remind developers that enumerations that contain a zero-valued member should be named "None" to indicate that no values have been set in the enumerations. Visual Studio code analysis manages these rules in a number of categories that help implement best practices - from code design rules, through globalization, interoperability, portability, reliability, security, and usage. Development teams can choose which rules they want to run whenever the code is compiled to give the team constant and continual feedback on the code they are writing. Another such example is the software architecture validation in Visual Studio 2010, where your teams can define acceptable architecture design patterns for your software (or use one from a set of provided architecture design patterns provided by Microsoft) and have a tool automatically detect variations between the target architecture design pattern and the actual implementation of the software (see Figure 2).

Figure 2

How can practices that involve requirements management and agile software practices be embedded into tooling? There are many tools on the market today that allow agile teams to capture requirements and manage projects. Some of these tools help to promote best practices by providing embedded guidance or resources such as wikis to help capture team learning. Some software project management tools embed practices in the basic behavior of the tool itself. For example, if you are running a project using the Scrum methodology, your team will want to divide the project timeline up into fixed duration time iterations called ‘Sprints.' Teams can then take product requirements stored in something called the ‘Product Backlog' and assign them to sprints. Tools that support Scrum allow teams to define product backlog items, sprints, and even allow workflows to be defined to help implement specific processes to help control the flow of development. Based on my 15 years of experience using tools and managing software teams, most of these tools don't go far enough down the road of best practice analysis.

The next generation of project management and team collaboration tooling needs to provide a form of best-practice analysis that functions much like Visual Studio Code Analysis; however, instead of analyzing code, conduct an analysis on a team's practices by examining the data that is naturally captured during a software development project. Tools should not only provide a set of rules that teams can choose to adhere to, but allow teams to grow and evolve these rules over time to truly leverage the power of process improvement, which is to change the process itself. For example, if you are using Scrum as your software development management methodology, you may want your teams to ensure that Sprints should not exceed 20 business days, which is a Scrum best practice.

Best practices should be adaptive over the course of the project's life cycle. This means that at the beginning of a project the set of rules your team may want to conform to may be different than the set of rules that your team will need to conform to at the end of a project. Any best-practice analysis functionality must be adaptive to be able to evolve as teams evolve. By adaptive we mean being able to selectively turn on best practices when we need them to best fit within the life cycle of a project and team. Adaptive best practices should also allow experienced agile teams to create and help define their own sets of best practices to help capture knowledge and learning during a project.

Applying best practices against software processes may not be something teams will want to do every day either. It's been my experience that there are a great many intermediate representations of information throughout a project - from partially completed plans to incomplete specifications. Applying and enforcing best practices every single day of a project may not make a lot of sense because of in-progress states. Tools that implement process best-practice analysis should do so on-demand by the user or at key process transition points, such as at the end of a Sprint if your team is using Scrum or at the transition of state if your teams are following a more continuous flow methodology such as Kanban (see Figure 3).

Figure 3

As engineering and methodologies become increasingly diverse, teams need all the help they can get. There is no substitution for education and continual learning; however, the tools that we use should also help our teams capture knowledge and learning and be used to help deliver more consistently and reliably while reducing waste. Engineering tooling has already embraced this, and it's time for tools that help facilitate process and governance to embrace this as well.