My time these days is spent helping clients who want to introduce an iterative methodology into their IT departments.Time after time, I have noticed that a few factors serve as good leading indicators to the eventual success of the engagement. These factors in decreasing order of importance are:
- Executive and Senior Management support and commitment
- Team makeup
- Front-line staff commitment
- Degree of change being introduced
1. Executive and Senior Management Support
At the start of an engagement, the most important determinant is the level of executive buy-in. Forming a judgment of their behavior, feelings, and real motives is easier said than done. All too often, the real motives and underlying political issues remain unstated; it is up to the change agent to quickly determine who is for and against the initiative and why. Some managers may be for the initiative but for the wrong reasons — a CIO at a previous client was interested in the change not to improve the division, but to earn brownie points with a key internal customer.Often times, an organization introduces change (Agile methodologies in this example) but does not change the way it evaluates and rewards performance. The cliche, “you get what you measure” is absolutely true. For example, all Agile methods depend to a large degree on teamwork; this can be easily undermined if the senior managers cherry-pick and reward their favorites during the annual evaluation cycle or if management decisions are made not with the ultimate product but with the functional roles in mind.
A leading provider of strategic HR, payroll, and talent management solutions, in Florida, has successfully done away with individual rewards —- teams are rewarded based on their performance.
The goodness of Agile methods is that they quickly spotlight major problems in the way the organization is structured and managed. Executives and senior managers then have the option of either fixing the underlying problem or ignoring the problem — switching off the spotlight — and hoping it will go away. Their actions when faced with such situations speak louder than their words. A strategy that has worked for me involves senior management explicitly stating their commitment to both the overall program and specific projects. During a Project Launch Workshop, I expect the Development Manager and the Product Owner to explicitly state the reasons for going Agile — this proactively answers the concerns that staff has regarding management backing. The Launch Workshop is also the appropriate setting for ensuring that everyone is aware of the change that is expected and for ensuring that senior management understands that the change will be uncomfortable initially.The demonstrated support is not a one-time event. Senior management attendance during iteration demonstrations and occasional presence during the daily stand-up meeting influences perceptions of their commitment and visibility.At the start of an Agile transformation initiative, senior management is usually unaware of the principles behind Agile methodologies. Therefore, it is crucial to conduct a series of “Management Briefings” very early in an engagement to surface the client’s current software development problems, describe how the practices being introduced will address their needs, and to ensure understanding of the values and principles behind Agile development.Making an initial effort to explain the rationale for the principles and practices being introduced, and addressing management’s concerns will avoid significant heartache later. Misconceptions about Agile practices (that they are new, or have only been applied to small projects) should be cleared early by describing the key practices (avoiding the waterfall and applying short 2-4 week iterative and evolutionary development cycles, automated daily builds with test and integration, value and risk-driven iterative planning), which have been known and applied for years on large systems-engineering, multi-team, multi-site projects.Note: For additional examples of the history of iterative development since the 1960s, refer to: “Iterative and Incremental Development: A Brief History” by Dr. Victor Basili and Craig Larman in IEEE Computer (June, 2003) and the “Evidence” chapter in Craig Larman’s “Agile and Iterative Develpment: A Manager’s Guide”.
2. Team Makeup
The team makeup is only slightly less important than senior management support. It is crucial that the project team possesses sufficient technical skills, is led by a capable team leader, and shows strong commitment to achieving a clear set of objectives. Good teams have at least one Journeyman or a minimum of two Practitioners; teams composed solely of Apprentices is destined for failure (see Meilir Page-Jones’ definitions at http://www.waysys.com/ws_content_al_sse.html).Based on my experience, people usually gravitate towards work that suits their temperament and their capacity for change can be gauged by the type of work they do — object oriented developers are more open to change than people working on technologies that have been stable for decades (AS/400, PL1, …). The effort that a coach has to expend when introducing Agile methodologies is significantly greater in the latter case.It is also essential that the team is absolutely clear on where they are going and what the steps to get there are. It behooves the Agile coach to describe the end state, how he expects the team to reach there, and to enumerate the lurking pitfalls.Organizations where task-switching (being allocated to multiple projects at the same time) is common have a harder time dealing with the introduction of Agile methods; team members have insufficient time to focus appropriately on the project and overloaded project managers cannot properly manage both the process and the quality of the team’s deliverables. This is not an issue that the team can control; the policy change has to be made at the executive level. An agile coach can explicitly demonstrate the effect of multitasking on project lead time and ROI. Sometimes, a coach can get lucky and be mentoring multiple teams that are structured differently. A previous client had a policy of assigning available resources to the next project in the queue without regard to where they were located — in one extreme case, we ended up with a 12-person team spread out over 5 different time zones (TX, NY, CA, India, Sydney). Needless to say, this non-collocated team performed significantly poorly than other similarly skilled collocated teams. In this case, upper management quickly understood the impact that the team selection policy had on team productivity; sadly, they never followed through on actually changing the offending policy.Effective teams usually encourage internal debate and continually search for better ways to accomplish their goals. Effective team selection, on-going development, and proper management are critical for ensuring that teams perform at a high level.
3. Front-line Staff Commitment
It is important for an Agile coach to enhance communication with, and the understanding of, client’s front-line staff. Encouraging face-to-face communication, creating opportunities for collaboration, and involving stakeholders throughout the project goes a long way in building team commitment.Instituting daily Scrums and inviting stakeholders, conducting demonstrations at the end of every iteration for showing progress, and making regular presentations to outside groups and management can enrich existing communication channels.Team members often lack initiative and wait to be told what to do. Far too often, in the past, the rewards for advocating change have not been forthcoming; team members consequently stop pushing for improvements and tune out. Management must critically self-examine the role they have played in producing the problem of lack of drive in employees.It is incumbent upon an Agile coach to clearly explain the detailed whys, whats, and hows of impending changes — changes on how people are expected to interact with each other through the project, changes on why frequent feedback is important and what development practices encourage feedback, etc. The impact of these changes has to be discussed with the teams and senior managers on multiple occasions.
4. Degree of Change
Resistance to a change initiative is directly proportional to the disruption caused. Incremental introduction of changes increase the probability of success. Introducing all Agile practices in one fell swoop is not the way to proceed when moving teams from waterfall based development; gradual just-in-time changes often work better.Changes can be made more palatable if the coach and project manager can ensure that any additional work required significantly reduces the amount of effort elsewhere. This is important because team members usually must also support existing applications while participating in the change initiative. Often, the change initiative affects only one part of their job; existing company policies may mandate that they continue to do something else anyway — for example, company policies may mandate that all work must be tracked in detail in Microsoft Project Server for allocating costs to subsidiaries; Agile methodologies usually look askance at tracking work in tools like MS Project, which implicitly encourage the problems associated with pre-defining all work for the project.Overloading teams is not easily sustainable; the coach must help the team identify and eliminate activities that do not add customer value. Some activities, however, must still be performed even if they do not add value. It is appropriate to question if these activities can be handed off to others or deferred.A good coach can recognize when to back off and when to introduce change. Support of senior management for pushing the change through is critical. Management must ensure that implementation time frames are realistic and achievable, resources are defined and available, and project priorities and due dates take the strategy into consideration. Rationalizing the number of projects started/in-progress is important when sufficient resources are not available and multi-tasking is a problem.