An Exercise in Agile Facilitation
A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves. Lao Tzu, Chinese philosopher (604 BC - 531 BC).
The project manager leads. The project manager directs. The project manager plans. The project manager manages. These are the expectations set upon, and sought out by those that take on the responsibility for delivering software projects to the Business. While unquestionably a critical role in the overall delivery mechanism, a project manager who becomes the central figure in the team can unnecessarily place the team in a position of risk. In fact, the project manager should approach the process with a less intrusive style, facilitating the team towards success from within and figuring out ways to develop systems that will survive any one person, themselves included.
Traditional vs. Agile Primer | Upside-down Leadership
The fundamental principles of Agile and XP methods for delivering software are well suited to the notion of an Invisible Project Manager. In a more traditional model, the Project Manager is responsible for everything, including detailing estimates of the technical work, managing the customer, assigning tasks, tracking, monitoring schedules and directing the movements of the team. All of which is managed closely against The Plan and reported back through the regular channels. Conversely, the Agile approach brings the customer and developers as close together as possible, asks the customer to prioritize the work, the developers to estimate the work, and then facilitates the negotiation between the two sides. And while all the regular aspects of a Project Manager's job description are still met, the manner in which they are done is quite different.
Trust Me | Information transparency from the outset
Building an open and honest environment is a key challenge for any project manager, and needs to be positioned from the start of any project. The earlier the better. Information that is disseminated in a way that improves the lot of the entire team will result in members being less worried that important details are being hidden. Once this tone of transparency is set the trust factor within the team will creep upwards, to the point where team members will implicitly trust the Project Manager. This is optimal, as it allows team members to concern themselves with the tasks at hand, not worrying about what surprises lay in waiting.
In practical terms, this means a high bandwidth dialogue amongst the team and stakeholders facilitated through a whole series of channels - stand-ups, retrospectives, big visible status reports, informal conversations, and an attitude of encouraging others to bring forward issues.
This practice can be compared to Continuous Integration, a key element of Extreme Programming. With Continuous Integration, as soon as a piece of code is written, the developer checks it into the repository where a full suite of tests is run against it, and immediate status reports are given (ie. the build breaks/passes). If the team is able to do this multiple times per day, the risks built into the project when it comes time to release the code are hugely reduced. In essence, paying a little pain each day to remove the oft-maligned integration bear lurking at the end of development.
As a project manager I want to ensure that the same principle is applied to team progress, problems and reports. As often as possible, I want to hear the ‘bad' news about delays, surprises, failures, and achievements, so I have an accurate read on reality. By radiating this throughout the organization, without drowning constituents in information, the risk of a significant surprise facing the team is negligible. More so, virtually all problems are solvable by the team - if its given adequate warning and the space to do so. By trusting the broader team with all the facts, adjustments will naturally occur, and the road will completion will be much smoother.
Big Eyes, Big Ears | Listen, watch, think; then act
Managing a team of people is very much a real-time activity. Plans do not manage people; people manage people. Popping in once and a while to see how the team is doing does not qualify as being involved, and without someone to help liberate the team from hurdles in its path, its prone to getting caught up in things that aren't meeting overall objectives.
Ideally, the project manager will sit with the entire team. With eyes and ears open to