I was asked recently by my boss, the Assistant Vice President of Application Development to review and give feedback on the most important impacts of Agile good and bad.
Good Impacts
- All three projects had production quality software that the users could see after one month. Any other projects of this size would be lucky to have a rough draft of the BRD (Business Requirements Document) done.
- All three of these projects have no real issues with communication between team members. Even though friction between QA, developers, business analysts, and PMs is pretty commonplace on large non-Agile projects we’ve seen none of this on the Agile pilot projects.
- The product owners on all three projects are very happy with the process. They all feel that the feedback every 30 days is much better than our old waterfall methodology.
- The projects have very low defect rates and have had no significant bugs at the end of any Sprints.
- The developers on the projects are more motivated and engaged with their team. The teams are actually having fun with things like one ScrumMaster being rewarded by their team with a rugby jersey embedded with a ‘Scrum Queen.’ Employees are more motivated when they come in to work.
- The use case approach results in much better requirements than our vague BRDs.
- Project managers are able to really have an impact and add value instead of filling in as a project admin role.
- Tasks on a project are broken down to 4-16 hour chunks. This has been a big help in two ways. First, team members can really commit to measurable tasks that are complete within a day or two. Second, teams become get better estimates because their actually forced to break everything into atomic tasks and they practice estimating every 30 days.
- Agile is forcing the organization to examine dysfunctional processes. Delivering every 30 days forces reexamining some decisions that don’t appear to be adding value.
Negative Impacts
- One of the benefits of releasing earlier hasn’t been realized. Product owners are still holding off for all possible features before releasing.
- It’s still hard to handle all the requests for smaller projects and leave staff dedicated on Agile projects.
- For a period of time at least one project was able to avoid following the normal migration process to QA servers.
- The business may not be ready to take on the faster pace of change and decision making that Scrum drives towards.
- The adoption of the entire Websphere stack at the same time as adopting Scrum has meant a painful level of change especially for web developers.
- Scrum is often sub-optomized because people aren’t solely dedicated to a project, or good collocation space can’t be found.
- The pace of change has proved difficult for a few team members requiring some substitutions on projects.
I think it’s a pretty good list, but it worries me a bit that I can’t come up with more negative things, makes me think I just may be drinking a bit too much Kool-Aid.