Avoiding work – it’s not just for slackers anymore
One of the 12 principles of agile is, “Simplicity – the art of maximizing the amount of work not done – is essential.” Those of us with Type-A personalities may feel uneasy with this principle because it seems to promote a slacker mentality.
As it turns out, simplicity requires a good deal of discipline. To achieve it, the product owner must scrupulously review the backlog to ensure that functionality with lower business value is de-prioritized. Simplicity may require the project manager resist a PMO-driven requirement for excessive documentation or develop a business case for implementing automated test tools. Simplicity will require that the developer clean up sloppy code and the tester avoid redundant test cases.
To become truly productive, we borderline workaholics need to put down the to-do list and get in touch with our inner slacker.
Becoming debt free
The world of agile includes some memorable phrases, and one of my favorites is “technical debt.” This phrase describes the mess that we create when we allow expediency to take priority over good software development and quality practices. When we lack technical discipline, the debt accumulates just like credit card debt accumulates when we lack fiscal discipline. The “interest” on the debt includes production problems, poor system performance, time-consuming maintenance, and demoralized teams.
The solution, of course, is to acquire the discipline required to pay off the debt. Getting out of technical debt requires that you identify the sources of the debt, convert it to stories on the backlog, then prioritize and execute the work. You will need to sacrifice development of new functionality, and this will lead to some uncomfortable discussions with the product owners. Paying off debt is a painful, but necessary. Let’s get rid of it before it become completely unmanageable.
Is it Agile Decision-making? Or Inadequate Planning?
Even in a well run organization, it may be necessary to cancel a project in response to new information. A new competitor may have already introduced a game-changing product. Market pricing may have changed, making a new product economically infeasible. It may be necessary to reduce capital outlays to keep the business afloat. Cancelling a project under these conditions may be a great example of agile decision making. But it could also be a sign of inadequate planning.
Whenever a decision is made to cancel a project, it is worth taking some time to reflect on the project and ask a few questions:
- What were the flaws in the original planning premises?
- Do these flaws indicate shortcomings with access to market intelligence?
- Was the project clearly tied to a strategic objective?
- If the project was tied to a strategic objective, should that objective be evaluated?
- How was the decision made to launch the project?
- Would there have been a different outcome with a different project team?
Cancelling a project is a very painful decision and it is human nature to want to move on quickly. An agile leader must ensure that the organization first learns from the pain, and then moves on.
And now a word to our sponsors – about deadlines
Reflecting upon three decades of leading and managing projects, I’m trying to recall a project sponsor ever asking, “How long will it take?” It may just be the passage of time or the result of being of “of a certain age” but I can’t recall hearing those words. The initial conversation with a project sponsor almost always involves a pre-determined deadline. That deadline may be driven by a legitimate business need or it may be driven by a desire to challenge the team, but it is rarely driven by project planning.
At the outset of a project, sponsors rarely demonstrate flexibility regarding deadlines. By the end of the project, after the initial deadline is missed by a considerable margin, it becomes apparent that the deadline really was flexible after all. If a deadline is not achievable, it is better to know it at the beginning rather than to set the conditions for a project failure.
So here is a word to our sponsors. The project manager may be intimated by your rank and lack the courage to challenge your deadlines. If he fails to challenge you, don’t assume that the project can be completed by the desired date. Hold off on setting deadlines until the project team has completed at least some level of planning. If the desired date is really non-negotiable, then you will need to show flexibility on the scope of Day 1 deliverables or the budget or both. Give the project manager and the team every opportunity to succeed.
What we have here is a failure to collaborate
The authors of the “Manifesto for Agile Software Development” (www.agilemanifesto.org) note that they value:
- “Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan”
While these values are easy to understand and appreciate, they are very difficult to implement because they require extensive collaboration. The leaders of most established companies built their careers in cultures that value control, predictability, and a healthy dose of “CYA.” While they may desire innovation and appreciate the sound of the word “collaboration,” they unwittingly erect barriers to collaboration. Some of those barriers are apparent but others are move are more subtle. Here are a few examples:
- People with roles that have the sole purpose of “gatekeeping”
- Organization structures with too many line managers
- Excessive inter-departmental rivalry
- Information security guidelines that limit the ability to share documents with external customers
- Office floor plans that limit the ability of team members to work together on an ad hoc basis
- The communication plan should focus on providing the developers with face-to-face access to business subject matter experts rather than controlling the communication flow
- Newly-identified deliverables should be viewed as opportunities to increase business value rather than a subject of extensive contract negotiation
- Deliverable dates should be the result of commitment from the team rather than being driven by the project manager
- Progress should be measured in relation to deliverables rather than tasks
- The project manager should focus on removing obstacles for the team rather than “holding their feet to the fire”
Agility requires collaboration, and collaboration requires a supportive climate. An agile leader must cultivate such a climate by eliminating barriers to collaboration.
Lessons Learned Meetings and the Confessional
The lessons learned meeting at the end of a project is a perfect opportunity for incremental improvement. But that opportunity is lost because of the dynamics of the meeting. Team members who are conflict-averse will hesitate to say anything that will offend. By contrast, the hyper-critical team members will go out of their way to ensure everyone is offended. Here is a suggestion for improving your next lessons learned meeting.
Many years ago, my parish priest introduced a sermon by saying, “Ladies, when in the confessional, please limit your confession to your own sins and do not confess those of your husband.” I have often applied this to the lessons learned meeting by asking all participants to come prepared to report three things that they would like to do differently on the next project. This will reduce the feeling of conflict and will provide some great ideas for improvement. Confession is, indeed, good for the soul.
Control – How much do you really need?
Project managers who make the transition to agility must change mindsets as well as practices. One of the more difficult for some is to change from a mindset of control to one of facilitation. Here are some examples of project management activities that require this change in mindset.
Ridding oneself of a control mindset requires considerably more personal discipline than changing processes and practices. Without such discipline, a project manager’s transition to agility will be incomplete.
On time and on budget, but did the business benefit?
The project finished on time and on budget, therefore it was a success. From a project management perspective, it would appear that this is a true statement. As project managers, we are obsessed with reaching milestones. We monitor our project burn rates with greater scrutiny than our personal bank accounts. To a project manager, schedule slippage and cost overruns are signs of poor planning or sloppy management. On the other hand, it may be a sign that the project manager is thinking like a business owner.
When faced with a decision to delay a project implementation until quality concerns can be addressed, a business owner would consider the longer term impacts. A year from now, what would be the impact of a delay? What would be the impact of a flawed implementation? The proper business decision might be a brief delay.
Some projects, particularly new product launches, are inherently risky. Success criteria may not be clearly understood and the initial project approach might require a few corrections. From a project manager’s point of view, it would be preferable to undertake a thorough project planning process until all planning premises are clear and the budget estimates are solid. From a business owner’s point of view, the business benefit of being first to market might outweigh the risk of cost overruns.
The discipline of sticking to deadlines and budgets is critical to effective project management and, in most cases, the business benefits from such discipline. However, when there is a conflict between project management discipline and business benefit, the project manager must think like a business owner and promote the best interest of the business.
Trust – a prerequisite for agility
Organizational agility requires a high degree of trust. Decisions must be made quickly, which requires authority to be delegated to the level at which the relevant knowledge exists. Communication must flow freely among workgroups, without a great deal of filtering. Team members must trust that, when a particular deliverable is produced, it has been adequately tested and reviewed.
In the absence of trust, organizations substitute extensive requirements documents, excessively detailed test plans, and exhaustive procedure guides. These ancillary documents may be viewed as more important than the final products. While some documentation is necessary to facilitate communication and ensure auditability, much of it serves no purpose other than to defend against potential criticism. However, excessive documentation is not the problem. It is merely one symptom of a low-trust organization. Other symptoms include hyper-critical managers, unnecessary escalation of decisions, and internecine battles among departments.
A low-trust organization cannot be improved by team-building workshops, motivational posters, or personality profiles. The lack of trust is a direct result of the behavior of the leaders of the organization, and only the leaders can change that. Until they do so, the organization will never achieve agility.
Don’t let a good issue go bad
Issue management is the lifeblood of project management. With effective issue management, project managers can employ their listening and negotiating skills to help the team avoid obstacles and prevent long-term problems. Ideally, issues should be resolved at the team level and escalation should be employed only when other measures prove unsuccessful.
All too frequently, project team members undermine effective issue resolution processes, and they do so with the assistance of senior management. Here’s how it works. John is assigned by Ann, his VP, to work on a project team. John observes a potential problem with the project and raises his concern to Ann. Ann is surprised about this problem, and expresses her disappointment to Tom’s boss, Frank. Frank calls Tom into his office and demands an explanation as to why he has allowed this problem to linger. Tom now needs to work with three people to resolve an issue that could have been handled quickly had it been dealt with directly. Tom also must stifle his urge to choke John.
Once the issue is resolved, Tom should use this as a “teachable moment” for his boss, Frank. He should counsel Frank that when issues are escalated in the future, he should ask the “escalator” what steps have been taken to resolve the issue at the team level with the project manager. Unless there is evidence that the issue cannot be solved with the project manager, Frank should send the escalator packing.
Why do executives allow improper issue escalation? Perhaps they do not receive enough short-term gratification by doing their own jobs. They enjoy going home at the end of the day feeling that they accomplished something by fixing another mess. Of course, they ignore the fact that they have just set the stage for future messes.
