Introducing Agile in a waterfall environment
The decision to try Agile often results from the organic growth of PM's or other delivery resources with Agile experience within the ICT department. These people either agitate for change or introduce some of the tools and techniques that are hallmarks of iterative delivery (story boards, product backlogs. stand-ups and retrospectives) that subsequently highlight benefits the approach delivers. Another common way is the PMO or ICT Manager believe a particular type of project is specifically suited to Agile delivery.
The most important objective of any project should then be to get going early and as cheaply as initiation and planning governance in the domain allows. As the initiative proceeds, gain experience, learn, adjust and progress further. Lean's and 6-Sigma DMAIC or Demming, which pre-date modern iterative Agile / XP / RAD approaches, expresses this as the importance of delivering results "as fast as possible, but as slow as necessary".
The first issue is the level of theoretical knowledge and practical experience the project team has that will be guided by the scrum master. Agile requires people to change their work habits and communication styles, and the depth of prior experience will determine the likelihood of resistance to change. Be very careful to prevent the perception in the team that the change is occurring because what they did previously was poor.
Very importantly, the depth of the change the delivery team are making is much greater than that of a project manager who largely escapes any productivity overhead other than producing different types of reports (burn-down charts replacing EVM).
Effectively explain the benefits of your approach over the existing accepted practices. Generally, the closer you get to the coalface, the concern for business benefits is reduced. People are more likely to care exclusively about how change impacts themselves. Be empathetic, if you were informed that the way you communicated, shared information, worked with others and documented was to change, particularly if you saw no issue with the success of your current approach, you would rightly question why.
Avoid placing the development team under pressure to show evidence of their work to the customer by scheduling the architecture component as a work package or deliverable not constrained by the sprint and release approach. Attempt to delay co-locating the customer until the team is ready to start on the functional, user facing work building on the now high quality robust framework, and then set about your Agile iterations.
Similarly, even if current practices have not yielded results, many stakeholders outside the team may be more comfortable with the devil they know, that being long range though fickle, forecasting of outcomes. Others may not want to devote time to considering new approaches especially if their knowledge of the current approach is superficial. Understandably, some senior executives may be afraid to make a decision if they think they may suffer damage by association if the experiment is a costly failure.
It may be wise to avoid implementing Agile for a project with extremely tight delivery timelines as there will be a productivity overhead in realising this change during adoption. Contentious as it may be, the attributes of a good developer are not tightly coupled to excellence in interpersonal or communications skills and therefore are not natural choices for customer interfaces. Avoid this risk by retaining your BA's within the team, don't fall into the trap of believing they are an opportunity for the users' message to become garbled or lost.
Remember, just as their are risks associated with big bang system implementations, the rule also exists for organisational and behavioural change.
Very importantly, the depth of the change the delivery team are making is much greater than that of a project manager who largely escapes any productivity overhead other than producing different types of reports (burn-down charts replacing EVM).
Effectively explain the benefits of your approach over the existing accepted practices. Generally, the closer you get to the coalface, the concern for business benefits is reduced. People are more likely to care exclusively about how change impacts themselves. Be empathetic, if you were informed that the way you communicated, shared information, worked with others and documented was to change, particularly if you saw no issue with the success of your current approach, you would rightly question why.
Avoid placing the development team under pressure to show evidence of their work to the customer by scheduling the architecture component as a work package or deliverable not constrained by the sprint and release approach. Attempt to delay co-locating the customer until the team is ready to start on the functional, user facing work building on the now high quality robust framework, and then set about your Agile iterations.
Similarly, even if current practices have not yielded results, many stakeholders outside the team may be more comfortable with the devil they know, that being long range though fickle, forecasting of outcomes. Others may not want to devote time to considering new approaches especially if their knowledge of the current approach is superficial. Understandably, some senior executives may be afraid to make a decision if they think they may suffer damage by association if the experiment is a costly failure.
It may be wise to avoid implementing Agile for a project with extremely tight delivery timelines as there will be a productivity overhead in realising this change during adoption. Contentious as it may be, the attributes of a good developer are not tightly coupled to excellence in interpersonal or communications skills and therefore are not natural choices for customer interfaces. Avoid this risk by retaining your BA's within the team, don't fall into the trap of believing they are an opportunity for the users' message to become garbled or lost.
Remember, just as their are risks associated with big bang system implementations, the rule also exists for organisational and behavioural change.
