Saturday, December 20, 2008

Seven Tips to Running an Agile/Scrum Project within a Waterfall Organization

If you are working in a waterfall organization and would like to manage your next project using Agile/Scrum, I have compiled seven tips for you to help with that. This is based on my experience implementing Agile/Scrum on a federally funded, large multi-agency Government project for last two and a half years.


Some organizations are probably better off operating as "waterfall" organization. However, these waterfall organizations still can benefit from running some projects using Agile/Scrum without needing to force the whole organization to suddenly change. These projects can run internally as Agile while they interface with the waterfall organization through waterfall artifacts.

Here are the seven tips:

1. Continue to use the traditional artifacts to interface with the waterfall organization. Probably your waterfall organization is accustomed to seeing certain project documents, i.e., weekly status report, project plan using MS project, traditional requirements document using use cases or some other format, architecture document, issues/risk list etc. You can map the Agile artifacts to these documents and share them with the rest of the organization.
This will help eliminate any objection to using Agile/Scrum on your project.

2. Choose sprint length appropriately. You do not want to go too fast and find yourself waiting for the waterfall organization to respond to your project needs. Stop and go would interrupt your project flow. On the other hand, you do not want to go too slow either. Most probably your waterfall organization is already slow enough and if you go at the same pace, you probably will unnecessarily burn $s. A sprint length of 3/4 weeks is probably a better choice.


3. Get external resource commitments prior to start of a sprint. Your project most likely depends on people (i.e., for HW&SW procurement, system administration, domain expertise etc.) who are not full-time on your project and operate in waterfall fashion to do their work. I call them “waterfall elements” of your project. You need to understand the lead time required (in your organization) to have these people available for your project when you need them.


4. Use a proxy to represent waterfall work streams to your daily Scrum and Scrum Planning. You probably have work items that will be performed by people who work in a waterfall manner. This is even more critical when you need to have certain pieces of software developed by a waterfall team. You would need a proxy who preferably is part of the waterfall team and can represent the work being done to the core project team during daily Scrum and Scrum planning meetings.

5. Create a sense of urgency and excitement within the project team and among the stakeholders. Most likely you may not have a client who proactively shows enthusiasm about project. It is especially true in Government and non-profit organizations. Lack of presence of clients in front of the project team can be demoralizing. Try and find a creative way to invite your clients/users/stakeholders to the sprint review meetings. This will create much needed urgency in your project team and will eventually create genuine excitement among the stakeholders.


6. Choose the right Scrum Master who understands your organizational politics. Most likely your organization has many ceremonies (documented and undocumented) as well as a network of influence. Scrum Master should be well versed with these long held practices and acquainted with the network of influence. Because he is going to need to leverage the political landscape to help remove impediments quickly as well as shield the team from external noises arising from the organizational politics.

7. Use retrospective to gauge the degree of self-organization of your project team. Most likely your project team does not have prior experience as a team to work in a self-organizing environment. Early in the project, you have to focus on encouraging behaviors that promote self-organization. As a Scrum master, you also have to protect the team from the rest of the organization getting in their way to becoming self-organizing team. Self-organization is the key to the success of any agile project.

If you are already running a project using Agile/Scrum in a waterfall organization, I would love to hear from you and compare notes.