Our Agile Methodology: 6 Month Review

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.