Agile and Software Maintenance
Within corporate IT organizations, there often exists a division between software maintenance and software development. It is not unusual for 80% of the software budget to be allocated to maintenance of legacy software applications. This large investment is viewed as a cost of doing business and it is assumed that little can be done to improve it. Meanwhile, the smaller budget item, software development, is the focus of process project management improvements such as Agile.
As corporate IT budgets become tighter than “lug nuts on a 1957 Chevy,” it is worth considering an Agile project management approach to software maintenance. Following are some of the potential benefits:
- The product owner periodically prioritizes the list of fixes and enhancements, thus ensuring greater business value from the investment in maintenance
- The software applications are upgraded via scheduled releases rather than one-off fixes, thus eliminating daily surprises as business users log in to the application
- Testing and software development run in parallel, increasing the quality of the software release
- The software releases are managed as projects, thus increasing management visibility and accountability
Software maintenance has long been regarded as a necessary evil. Perhaps it’s time to start to regard it as a source of business value.
Scaling Agile? Aim for the Sweet Spot
If you are responsible for scaling the use of Agile in your organization, consider focusing your initial efforts on those projects that are within the “sweet spot,” as depicted below.
After successfully completing a group of Agile projects, you will have the political capital and organizational capacity required to continue your scale-up efforts beyond the “sweet spot.”
The Power of a Good Example
After an argument with a defiant teenager, an exasperated father was heard to say, “He’s not completely worthless – he can always serve as a bad example.” Just for the record, I was not the defiant teenager in question. While this father was able to find some good in a bad example, there is much greater power in a good example, particularly in an agile culture which runs on interpersonal relations rather than formal authority. A project manager who arrives at meetings on time and looks after the best interests of his team members will have greater success in meeting project objectives. A developer who consistently meets commitments and deals well with customers will have her choice of new project assignments. A product owner who publicly praises the accomplishments of the team will receive better response to requested changes.
All these people can wield considerable power in their organizations. Why? The reason is simple. Knowledge workers have a great deal of latitude in their daily work and they will use this latitude to support those who treat them respectfully and get even with tyrants, micro-managers, and political animals.
Giving Orders – The Thrill is Gone
In the book The Effective Executive, Peter Drucker quotes President Truman who said: “Poor Ike; when he was a general, he gave an order and it was carried out. Now he is going to sit in that big office and he’ll give an order and not a damn thing will happen.” If a United States president is unable to assume his orders will be followed, an executive in a modern, agile organization should not be surprised if his orders are met with the sound of crickets chirping.
In an agile organization, power comes from expertise rather than organizational rank. The subject matter expert with 20 years experience in the industry will act as product owner, prioritizing new features and determining when the product is ready to ship. The veteran software engineer will share best practices with colleagues, thereby enforcing programming standards. The senior project manager will mentor other project managers as they transition to agile methods. The entire organization will mature and improve without the need for a single order from senior management.
What Makes Project Management So Difficult?
Projects, particularly IT projects, have a notoriously high failure rate even in organizations with mature project management processes. Why is project management so difficult? In my experience, there are four reasons:
-
1) The project objectives are often given to the project manager rather than negotiated
-
2) The project manager is entirely dependent on the performance of team members to achieve the project objectives, but has little control over who is assigned to the project
-
3) The project team members are not directly accountable to the project manager
-
4) The project team members have other jobs that conflict with their project duties
In spite of this, some project managers are successful because they have mastered the use of power and influence within their organization. This will be the topic of future posts.
The Necessity of “Hustle”
A nimble, agile organization works at a different tempo than a more traditional organization. When projects move sequentially through the traditional stages of requirements, design, development and implementation, work is punctuated by rest periods as the team awaits the inevitable reviews and approvals. Eventually, the pace does becomes frantic when implementation is right around the corner.
For an agile organization, implementation is always right around the corner. These implementations are smaller, and thus less frantic, but the pace is still rapid. Business requirements change frequently and must be translated quickly. Flaws and roadblocks are identified every day, not just at the end of the project.
An agile team must be prepared to move quickly, and the leader must be prepared to set the pace. The team must develop an appreciation for the value of hustle, and those who wish to retire on the job will find agility to be quite uncomfortable.
Don’t Rush Implementation of an Agile Management System
As you begin to scale the use of Agile in your organization, it may be tempting to select and implement an Agile management system. After all, the reasoning goes, won’t the software reinforce Agile thinking and processes? There is a flaw in that reasoning. Agile culture promotes team-based decisions and eschews the centralized, command-and-control approach implicit in this reasoning.
Rather than implement an Agile system early, hold on to the flipcharts and sticky notes until 2-3 teams really understand Agile concepts and perceive the need for software to document stories, track progress, and integrate plans. Then, these teams should participate in the effort to identify and select the Agile management system. This approach will help ensure the system is a good match for the team. It will also help limit the inevitable complaints about the system down the road.
Cultivating an Agile Culture
Agility builds on competence, ingenuity, and team work rather than workflows, tools and techniques. An organization with an Agile culture will focus on providing business value, foster collaboration between business and IT, and encourage personal accountability. In so doing, it will also highlight deficiencies of certain team members and leaders. Team members who lack initiative, interpersonal skills, or proficiency will become highly visible. Project managers with a command and control mindset will find it difficult to allow team members to figure out problems on their own.
To cultivate a high performance Agile culture, it will be necessary to provide special attention to those team members and project managers who are having difficulty adapting. That attention may mean additional coaching, but if the coaching is not successful, it will be necessary to remove people from teams. Not everyone can adapt, and it is unfair to the individual or the team to continue in a role for which they are not suited.
Go or No-Go – Making the Decision
As the project deadline approaches, it’s time to make a painful decision. Do we implement or do we wait? If the test results are clear and the deliverables are in place, the decision is easier. However, if the test results are ambiguous the decision becomes a difficult judgment call for the project manager and the sponsors. The decision-makers may be tempted to implement on schedule, thereby “saving face” and avoiding uncomfortable conversations with senior management and customers. When confronted with this situation, it is helpful to challenge the decision makers to imagine themselves at a meeting a year later. At that meeting, few will remember that the implementation had been delayed by a few weeks. On the other hand, if the implementation is exceedingly rough, the damage will be fresh in everyone’s memory a year later. Very often, “no-go” would be the wise decision.
PMO Obstacles to Agile
The Program Management Office (PMO) function in most organizations was designed with two goals in mind: gain control over projects and improve project management processes. As organizations scale up Agile, these two goals begin to conflict because the controls can inhibit the improved (Agile) project management process. The controls were designed to support the waterfall method and need to be adapted to facilitate Agile. Following are three common PMO controls that will require adaptation.
- PMO status reporting should be modified to focus on deliverables rather than activities
- Phase gate reviews should be limited to the project definition or charter
- Analysis and design documentations should be eliminated because they are normally not developed in Agile
These changes sound simple but they can be a difficult sales job unless the PMO manager is already an Agile proponent.
