OnPoint, LLC

Avoiding work – it’s not just for slackers anymore

Ron Montgomery — Mon, 02 Jan 2012 17:22:59 +0000

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

Ron Montgomery — Wed, 07 Dec 2011 04:04:12 +0000

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?

Ron Montgomery — Sat, 15 Oct 2011 20:42:45 +0000

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.

What is the cost of “no surprises?”

Ron Montgomery — Mon, 13 Jun 2011 11:10:08 +0000

Early in my management career, I reported to a politically savvy executive who insisted on “no surprises” from his direct reports. He wanted to make sure that he would always be able to respond to questions about any of our projects and thus avoid the appearance of being out of touch. Since then, I have met managers who either explicitly or implicitly expected the same. Some would become angry with their direct reports any time they were presented with questions for which they were unprepared.

Beyond exhibiting insecurity, these managers are increasing costs for their employers. Their direct reports waste time on frequent and sometimes detailed emails on day-to-day problems and issues. Meeting time is devoted to bringing the boss up to speed and PowerPoint presentations are developed to ensure the manager is properly briefed.

Managers who want no surprises are focused on control rather than empowerment. They demonstrate that do not trust their direct reports to make decisions themselves. As a result, they inflict a level of organizational paralysis.

In a fast moving organization, managers look for ways to remove obstacles for their teams rather than control their actions. For such an organization, the cost of no surprises is the loss of agility.

The Trouble with Flat

Ron Montgomery — Thu, 21 Apr 2011 01:46:37 +0000

When designing the structure for an agile organization, flatter is better. A flat organization can speed decision-making, limit time wasted on turf battles, and adapt more quickly to changes. There is one problem with flat organizations – they may limit the career aspirations of your best employees.

In the April 2011 edition of Inc. magazine, Jason Fried writes about a recent situation at his software firm, 37signals. One of Fried’s best employees left because she wanted to move into management and 37signals has no managers among its 27 employees. Fried did not want to begin to introduce layers of management, so they parted ways.

To limit attrition of your star employees, start during the hiring process. Make sure the potential new hire understands that there are limited opportunities to move into management. Design your compensation structure to allow your employees to grow their income while remaining on a technical career path. Provide a considerable level of autonomy to your best technical staff. Finally, get comfortable with the idea that, no matter what you do, you will occasionally lose a star employee.

And now a word to our sponsors – about deadlines

Ron Montgomery — Wed, 13 Apr 2011 22:55:30 +0000

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.

When your boss is a micromanager

Ron Montgomery — Thu, 24 Mar 2011 17:32:45 +0000

When interviewing I.T. professionals, I often ask them to describe both the best managers and the worst managers they have worked for. The description of the worst managers invariably fits the profile of a micromanager. The behaviors attributed to these managers including 8 am “bunk checks,” monitoring emails, and demanding pre-approval of the most mundane decisions and communications. Beyond the excessive need for control, these managers tend to use insulting or demeaning language. Some are even described as “screamers.”

If you report to such a manager, your first choice might be to find another job. Failing that, you will need to adapt to life with a difficult boss. A good place to start is to ask him the question, “What information do you need from me in order to do your job?” Use this conversation as a means to negotiate expectations for status reporting and other communications. As your boss thinks through what he needs, he may become a bit more realistic. Once you reach an understanding, make sure to live up to your end of the agreement. If you fail to do so, you will invite an even greater level of scrutiny.

If your manager is also a screamer, you have a more difficult problem. You will need to maintain your composure and demonstrate a higher level of professionalism than your boss. If you receive a flaming email, do not respond in kind. Simply reply with three words, “Please call me.” When your boss calls, try to address the concern directly and avoid being emotional. If your boss is screaming at you in person, point out his level of emotion and offer to resume the discussion later. Then leave the room.

Be very careful about escalating your concerns to your manager’s manager. While you may get some assistance, there is a good chance that he is also aware of the behavior and is unwilling or unable to correct it. Bear in mind that you cannot change your boss’ personality. Instead, you need to adapt your own behavior and actions until you can complete your exit plan.

What we have here is a failure to collaborate

Ron Montgomery — Tue, 22 Mar 2011 14:49:38 +0000

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

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

Ron Montgomery — Mon, 21 Feb 2011 16:00:17 +0000

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?

Ron Montgomery — Mon, 17 Jan 2011 15:38:59 +0000

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.

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”

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.