Friday, November 18, 2011

Agile or not, this stuff works!

I don't have formal agile training, but being on a variety of development projects I've seen what works. Here is my short list for development project success:
  • Find a team manager who is technical, a detail-oriented planner, and can work at 10000 feet and ground level
  • Select a project coordinator who also has a high level understanding of the project and ensures that team coherence is kept and communicates progress across business lines
  • Nominate a tech lead who has a strong point of view, is not technically biased, who periodically reviews what the team is checking in to ensure a certain level of code quality, cohesiveness and consistency
  • Create a business requirements document, which details program functionality to a level of minutiae that can be coded to with certainty
  • Come up with project milestones based on the business requirements before any design is done and go through the document as a team to ensure understanding
  • Break down the milestones into high level tasks, divide and assign to developers to flush out work required and swag estimation times; review with the entire team
  • Pad time in the initial estimated total project time for incidental things like code refactoring, benchmarking and profiling, proof of concepts that may result in dead ends
  • Review developer tasks at the beginning of each sprint (3 weeks works nicely) and have the developers explain what the tasks are in the sprint planning kick-off meeting
  • Use an agile project tracking tool at each stand-up meeting to go around the room, ensure developers are logging time and updating time left for tasks
  • Have 3 stand-ups a week and "parking lot" issues to the end of the meeting that not relevant to the review of the tasks in the sprint
  • Require standardized design documents (provide a template) and design meetings for code or functionality that is not trivial
  • Require peer code reviews before check-ins are committed
  • Use a bug tracker and integrate the tracking numbers in commit messages when code is checked in
  • Ensure QA list exact steps to re-enact a bug when they are written up
  • Provide details in the bug tracker, that may help QA retest fixed bugs
  • Invite QA to attend stand-up meetings to discuss testing and bugs, if there is a showstopper immediately delegate the who, what when for resolution
  • Automate a unit test build, a full regression test, which when failed requires the immediate attention of the dev team so as not to compound issues
  • Enforce the use of the planning, tracking, and build tools
  • Present the entire team when there is an innovation to be considered ask that developers float ideas to team leads to limit unnecessary debate
  • Decide as a team before changing core functionality, 3rd party libraries or technologies, coding or workflow conventions
  • Document and enforce coding standards, IDE tool usage, programming languages, and code formatting style - using shared templates and code coverage tools as much as possible
  • Document development processes, systems, and common practices in a wiki
  • Store design documents, charts, and business requirements in a document repository

2 comments:

  1. To me, this seems like an overwhelming amount of process - I can't imagine getting anything done successfully with so much overhead :)

    The "document" and "enforce" aspects of this list run very contrary to agile practices and perhaps all this stuff is needed for success if you're not running an agile shop?

    Where I work, we have very little of the above. We use BaseCamp for evolving ideas at a high level and tracking business objectives. We use Unfuddle for tickets that represent actionable tasks (user stories, with additional child tickets as needed if a user story is more than a few days' work). We have a fully automated suite of tests, from unit tests up to end-to-end scenario tests (via Selenium - it's all web stuff). We have a "showcase" server that the business team can review, with automated builds run as often as business want. We can take any showcase build to production in about ten minutes, whenever the business team want.

    Developers are free to use whatever tools they want. We use a wiki (in Unfuddle) to document architecture and processes as needed so that anyone on the team has just enough reference material to be able to understand the moving parts in the system and how to initiate builds etc.

    We pair program as necessary, when covering hard problems or learning / teaching new parts of the system or new technologies. We're all remote - we all work from home.

    We do Scrum-style stand-ups 3-5 times a week (any obstacles identified generally lead to pairing sessions) and a team guidance meeting every Monday to set / communicate any priority changes. We don't keep strict sprints - we go to production as often as the business team want, which ranges from weekly to monthly depending on what's being worked on.

    So, in summary, definitely some good points in your list (bug tracker, automated tests) but I'd caution against the level of process and documentation. It sounds like you have a fairly traditional IT department with a separate QA function? Consider integrating QA and dev so it's no longer looked on as two teams - QA should be involved with user stories upfront and should be assisting in the development and testing process continuously. They shouldn't need to be "invited" to attend meetings - they should already be part of the same team.

    ReplyDelete
  2. So that's explains why I feel like my style is cramped sometimes!!

    Seriously Sean, thanks for your critical review of the not-so-agile processes that exist in my current dev team. You are right, this is all likely needed when things aren't very agile and that explains why they are having us attend an agile training in January. I obviously have no idea what is or isn't agile!

    I'm looking forward to learning more about the process as well as checking out the tools you mention, which work well for you and your team. Your comments are refreshing and have given me much food for thought.

    When I wrote this post, I had just transferred from another team, which had absolutely no process and was the polar opposite. This made all the processes in my current team seem really great. Although that wasn't exactly how I saw it before I switched groups. It felt way too controlled, for sure.

    ReplyDelete