5 Great Agile Suggestions And One Questionable One

I’ve long been a big fan of agile development and DevOps, but after lots of recent projects and non-trivial pain points, I’m skeptical of anyone who recommends “less documentation” as leading to improvements in processes and quality.

These techniques have been identified as they provide a ‘low hanging fruit’ sort of benefit in that they do not require huge expenditures or investments, but produce noticeable and most importantly, trackable, improvements in processes, speed and quality.
6 Practical Agile Techniques You Can Start Using Today - Developer.com

If you haven’t read the article, SPOILER WARNING. =)

My random, tryptophan-induced thoughts on the six suggestions are:

  1. Deliver More Frequently. Fabulous idea! Get on a cloud cadence. Ship early and often.
  2. Bring Testers and Developers into Requirements Discussions. Absolutely!! Over the years I’ve been most successful with cross-functional teams.
  3. Testable Requirements Documentation. This is the most significant change you can make in your process. Note: It requires “more documentation” than a typical agile implementation or even a waterfall project.
  4. Communicate More, Document Less. This is the one that concerns me. Most “agile” teams that I’ve worked with in the past two decades have taken “document less” to mean “skip documentation entirely and jump straight to code”. That’s a bad plan. Staff turnover, time passing, communication with other teams/companies, etc, all demand documentation. Without it, you’re going to suffer integration pains, communication tax, and regression errors. Ask me how I know.
  5. Use Prototypes. I like prototypes. Unless you don’t plan to throw them away. Almost nobody ever throws away prototypes in my experience. Don’t kid yourself if you’re just “prototyping” Version 0001. Don’t call it a prototype unless you actually plan to throw it away.
  6. Think about Testing Early. Most certainly. It seems to me that good testers are the limiting factor in almost every project. Great testers are hard to find and they’re frequently forgotten at the end of the process without any input or control.

Yes, you can use them immediately. Even in a scrummerfall project. Heh.

Comments (2)

  1. Bernie Schoch says:

    Use Prototypes:  For some, I think they are a good tool to get the project started.  Sometimes there is a hesitation to start the project until it's all sorted out "perfectionist attitude'.  So then thinking of this 'start' as a prototype is a good mental crutch to get it going.  If you have this 'perfectionist attitude' then there is a good chance you will be constructing the prototype as a core foundational element anyways which won't be a throw away.  Anyways, I've found this thought process a good one for myself.

  2. Niclas Lindgren says:

    The thing is, people talk about the value of documents. I have never experienced any value of documents unless they are

    *) Very very high level architecture document, usually just a diagram of all the major components and how they relate.

    *) How to build

    *) How to deploy

    *) API doc (can mostly be generated)

    *) Database diagram (can be generated)

    *) Test spec (can to some extent be made runnable, thus testable)

    Build and deploy can mostly be automated, but still needs a little starter "readme".

    Everything else never gets read, never gets used and costs an huge amount of time to maintain. And most everything else is actually documented in the code. The code is a very valid document, try to get your code to use name and API that makes sense instead of creating a document to describe it.

    So yes, there are very good motivating factors to document less and communicate more. Staff turnover is solved by proper pair programming (communicate more) and team rotation, time passing is solved by automated testing (units tests describe what the code is meant to do, acceptance tests how they integrate). Communication with other teams is done through an API, if they API is too large, the teams are split wrong, teams have to spit according to architecture, else the architecture will soon be dictated by the team split.

    To get 4 to work, you need to work differently, which can be very difficult change to figure out.

    Prototypes are golden, the absolute best way to gather knowledge about what you want to do, if they get reused there is no one else to blame than yourself for reusing it, unless you want to reuse it.

Skip to main content