More Process Stuff

Events happening in the community are now at Drupal community events on www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!
Posted by chrisstrahl on May 26, 2011 at 3:59pm
Last updated by chrisstrahl on Sat, 2011-05-28 00:01

This page should ultimately end up combined with the one posted by Ariane, but I wanted to toss up what I've been working out on the airplane. We'll go over it today and see what we want to keep / toss.

Project Management - Using Agile

This wiki page requires some background in what Agile development means. For an overview on what Agile is, and some of the important terms, please read:
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Scrum_(development)

While we’re not explicitly proposing any of the models there, what will will be proposing closely follows The Agile Manifesto.

The essential bits of any Agile methodology include:

  1. Create a process for writing / identifying stories for your project. There are whole books published on writing good user stories (I personally prefer a variation of S.M.A.R.T.), but the basics are:
  • Specifc and Simple - Keep stories short and to the point. Clearly define what you’re going to accomplish and make it easy for others to understand.
    • Good: “Develop a clickable complete wireframe for the site homepage”
    • Bad: “Develop some representation of a visual design that showcases the potential functional components of a site through ocular and somatic user interaction on the primary page of the web application.”
  • Measurable - Stories need to have a clear line between “done” and “not done”. It needs to be clear to everyone what success means.
  • Attainable - The story needs to have a reasonable chance of being accomplished within the sprint time-frame. Often, if a story feels too big it should be broken into smaller more attainable chunks.
  • Relevant - Be sure you ask yourself if the story is important to the project and if it makes sense to work on. It is important that all of the stories support the goals of the outlined project.
  • Timely - It's essential that there is a reasonable chance of accomplishing the story within a sprint cycle. This also is where you consider dependencies (including predecessors) of the story to see if it's the right time to be working on it.
  • Pick an iteration (sprint) length - how long do you want to go between major deliverables? Shorter usually allows for tighter management of the project, but longer is often better for accomplishing more work. Adjusting this to the discipline of your team is best. We recommend 1-month iterations for most initiatives. It’s also worthwhile to create a standing agenda similar to:
      • Review prior sprint and demo functionality (if not already done). Decide what work that wasn’t completed is going to be reevaluated and what is going to move forward into the next sprint.
    • Address any standing team issues that need immediate attention - what are blockers to tasks from the prior sprint or blockers to the coming sprint?
    • Plan for the user stories you’re going to tackle this sprint (more on this later). Assign story responsibilities to project team members.
    • Ensure that each team member buys-in to the sprint plan and feels that they can accomplish their assigned work.
    • Provide a chance for the team to feedback into the process and the work being done.
  • Pick a check-in length and times - how often do you want to talk to your team? Frequent check-ins are essential to managing commitments, project direction, motivation, and team cohesion. However, you can end up with meeting fatigue if you’re talking too frequently. There is a balance between making sure people aren’t wandering without direction and taking too much time away from folks. Be flexible, but 2-3 short meetings a week are recommended. Keep these meetings short (less than 30 minutes), have a clear plan of attack, and start and end them on time. You want to instill a cadence in your project that people can rely on and understand easily. It’s recommended you create a standing agenda where each person speaks to the following:
    • What was accomplished since the last check-in?
    • What is planned to be accomplished before the next check-in?
    • Are there any blockers to the work that is being done?
    • Are there any meetings or scheduling that needs to be done with other project team members?
  • Determine what “done” means and how you’ll showcase it. Team members need to be able to report on their status both during meetings (synchronously) and outside of meetings (asynchronously). Often, teams will meet at the end of a sprint, or just before the planning of the next sprint, to go over the details and showcase their work. Develop a plan on how this will be done, share it with your team, and stick to it. Remember, Agile is all about having complete and working deliverables at the end of each iteration, and it’s important that project members understand what is acceptable. Answer questions like:
    • Who checks the work that has been submitted for accuracy and completeness?
    • How do we share completed work with each other and the community?
    • What indication do we have of something being done?
    • How do we mark something as “submitted” rather than “completed”?
  • Create a commit process that finalizes accepted work. At the end of each iteration you should have work that has been demoed and accepted by the team and is ready to commit to the master branch of your initiative or HEAD. This can include more than just code if you desire (e.g. documentation being published on d.o), but it’s important that there is follow-through on the completion of work.
  • Develop a method for feedback and improvement. This is called a retrospective. If people are into it you can make this a formal part of the process and review each iteration as it’s completed. If you don’t formalize it, make it a quick part of each review or sprint planning.

    • Tools we use:

    • Calendars - it’s imperative that you have a calendar setup to plan and coordinate your team. Google Calendar is a great option as it provides XML / iCal / RSS publicly so you can make sure that people have multiple ways of accessing it.
    • Drupal Issue Queues - While imperfect, this is the single best way to communicate with the public Drupal community around the stories you’re working on and the sprints you’ve planned.
    • Drupal Groups
    • Drupal Initiatives Group - the place where we can go to collaborate on process, planning, and get help on getting things done.

    Proposed Organizational Structure

    insert structure here...

    Drupal 8 Initiatives

    Group notifications

    This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: