Doing agile software development in enterprise environments presents challenges beyond those found in smaller firms. Big companies like to document, review and approve. Those concepts aren’t inherently anti-agile but they sure can slow things down. Resistance is unlikely to win you any points or make you any friends.
Transitioning from a waterfall approach or from no-process-at-all to an agile approach like Scrum is difficult under any circumstances. In an enterprise situation, it’s even tougher. If your environment demands development artifacts and requires procedures that aren’t the norm for agile teams, here are a few tips to help you overcome the resistance.
- Accept the situation. Get used to idea that the team will need to provide additional development artifacts. Some decidedly non-agile procedures will also demand attention. You may be able to change what’s being required over time, but not at the outset.
- Include documentation in the acceptance criteria for any story that needs it. This will ensure that the documentation requirement is visible and gets delivered.
- Include review cycles and management approvals in the Definition of Done. To enhance velocity, this is likely to require that a new story is started before the current one is done (i.e. fully reviewed and approved) — not ideal, but workable.
- Make the required documentation as simple as possible. Avoid elaborate specification templates and pages of boilerplate text. The simpler the document, the faster it can be reviewed and approved.
- If fancy, elaborate documents are demanded, hire a technical writer. Keep the developers and testers focused on the build.
- Those lengthy documents will require an executive summary. Face it, very few people will find the time to read a 20-page document. Let’s not even consider 50- to 100-page documents. You’ll need to guide the reviewers through the key parts of the documentation so they know which sections to read.
- You may be forced into architecture modeling and design reviews before implementation begins. Try to use an established software framework to minimize design time.
Finally, and most importantly, deliver on your commitments. Build trust and respect. The more successful the development team is, the more leeway it will get on future projects.
photo credit: k.landerholm via photopin cc
Thanks for those helpful tips.
Personally, I break each story into tasks. Tasks inside a story can be design, coding, installing and configuring tasks as well as documentation and other types of tasks. On my projects, to help us achieve the “done done” for each story, we defined a standard breakdown structure for a story. Using this approach, when a story is marked as finished, it is really done.
That’s a great point, Dave. Each story becomes a mini project. Some will have a documentation component and others won’t. The tasks can be customized to the story. Thanks for sharing!
Comments are closed.