Agile Project Management

One thing that can be said about the success of Agile practices, in software development, is they have created many discussions on how to manage Agile teams. This has caused some companies to question what roles need to be filled in organizations to ensure project are as successful as they can be. Agile processes are a product of their time, there has been a growing trend in other management disciplines, like Supply Line management and production. Studies of organizations, in recent years, increasingly look to natural systems and self-organizing structures. Now new network technologies can help make some of these new organizations work. There is a growing shift in emphasis away from control and hierarchy, to leadership and self-organization; a realization that the pursuit of control leads to the organization dying quicker.

An example, in another software discipline is configuration management. Modern configuration management is not what it once was. Years ago there was the idea of Change Control where change control boards would meet to determine what changes to the software that are to be made. This often enforced a hierarchical bureaucracy where development was held up by the board depending on the risk that the change posed and the availability of personnel to perform the changes. Rarely now do organizations strictly control their source-code, the best projects build networks of trust and automated test suites to highlight human error. The control over the code is increasingly placed in the hands of engineers who are most familiar with its operations.

Project management, perhaps fairly, has often been omitted from conversations of Agile. Afterall the improved delivery attributed to Agile methods came about despite the traditional Project Management community: projects were technically lead often by emergent leaders. In the end however Agile often needs to be adapted for a corporate environment where management is a fact of life: this needs to happen in a way that the technical practices are not lost. This had lead some agile-practitioners to zealously dismiss the role of the manager. This is to Misconstrue the Message of Agile: it's a movement away from control to leadership. As Cockburn points out:

Without adequate sponsorship, the project will stave for resources. Sponsorship consists of: Money for staff, training and equipment; and Decisions about the direction and the priority

He goes on to say the failure of many Agile projects is not communicating with the Business:

when I look through the stories of failed agile projects, this is a dominant pattern that emerges: the project team dismissed the project manager and did not create an adequate line of visibility to the sponsors, and the support git cut off a short time later...If an agile team wishes to work without a project manager, the team must find another way to get the visibility and support they need.

However the success of Agile down to allowing technical staff to adapt to the solution they are producing.

CCPace have defined role of the Project Manager in Agile using a framework. There work notes the philosophical underpinnings of Agile and iterative working:

As the literature will attest, traditional command-and-control management is largely derived from the principles of Frederick Taylor’s “scientific management.” Taylor’s scientific management approach was based in turn on the seventeenth century science of Newton that saw the world as a vast and magnificently ordered “clockwork universe” governed by the classical laws of nature. Scientific management is recognized as the prime mover in lifting the “working masses” in developed countries to new levels of affluence in the 20th century.

In today’s world, however, we have trouble imposing command-and-control management on teams because “working masses” have been replaced by knowledge workers. In the computer software industry for example, we have situations where skilled software developers are often worth as much or more to their employers than their managers.

They view the Agile team as a Complex Adaptive System that requires guiding rather than controlling. Their framework has six practices:

Guiding Vision

Recognizing vision as a non-material field(non-material field) rather than an elusive destination results in vision continuously guiding and influencing behavior in positive ways. The notion of non-material field is equated to something like gravity in a complex system, it is a present force that is not part of the system that has an impact on the system. The idea is that the vision of the project, asserting the business intentions. They note: Throughout the project, gently guide the team to maintain focus on the vision. Everyday decisions and interactions are opportunities to reinforce the vision and create positive energy. Beware of actions that are not consistent with the vision and your message, this kind of dissonance creates the negative energy that deflates teams and inspires many Dilbert strips. For example, in planning sessions, ask questions to provoke thinking about whether stories and the assigned business value are in line with the vision.

Facilitating Teamwork and Collaboration

Recognizing individual team members as intelligent, skilled professional agents and placing a value on their autonomy is fundamental to all other practices. Teamwork and Collaboration form the basis for rich interactions and cooperation between team members. Beyond this they have noticed that the Project Manager often sets the standard for some of the team and underline the importance of the that the manager should get to know the team members and what makes them tick. The Project Manager facilitates teamwork and collaboration, they particularly note that in organizations new to Agile sometimes is it takes some time to get developers to work as a team. Sharing issues with the group is not a sign of weakness helping facilitating the opening up and creating a sharing environment is key to Agile working. Some of the best teams know each others weaknesses and adapt to them.

Simple Rules

Simple Rules that support complex, overlaying team behavior. Formulating a set of generative practices like the XP practices creates a framework for the team to work with. Such practices do not limit the autonomy or creativity of the team. Often in the case of XP they put systems in place to automatically create the information needed by the business as a byproduct of production.

Open Information

Open information is an organizing force that allows teams to adapt and react to changing conditions in the environment. Tradition managers have often restricted information. In an Agile world information is released: tracking information and access to the customer lead to an open exchange of information. They elaborate with the suggestions of:

• Place team members within close proximity of each other whenever possible.
• Make use of information radiators such as whiteboards, charts, etc to disseminate information
• Rather than have status meetings with the project sponsor(s) in an office or conference room, bring him/her to the project room for public status reports and hands-on demos.
• Use a team wiki to share information.
• Establish daily status meetings to promote the flow and exchange of information.
• Sustain open information exchange between business domain experts and the development team.

Light Touch

Intelligent control of teams requires a delicate mix of imposed and emergent order. Notes that some traditional managers have become control zealots, when what is really required from management to to establish order.

Agile Vigilance

Visionary leadership implies continuously monitoring, learning and adapting to the environment. This practice takes into account the other practices: encouraging the team to grow in the right direction. Constantly seeking feedback and encouraging good practices.

For managers that have been managing Agile teams for the last few years many of these things will not come as a surprise. What is interesting to me that this is set to become the role of the Project Manager: facilitating the move of Agile into more traditional organizations. Perhaps even displacing the role of a Development Manager. It is though a very thoughtful and good start to the practice and evidently is written on real experience of managing agile teams. Some guides can be woolly attempts to combine different literature together and not come to a reasonable outcome.