10 tips for doing Scrum when you’re decentralized, part-time or doing other stuff you’re not supposed to do

• integrating existing packages, not developing software
• deploying a visual design
• working with a decentralized team
• working with a part-time team?

The new Scrum Breakfast Club portal is based on WordPress and who knows how many plugins. My part-time “team” and I have been working on this project for about 6 months. Calling us a team might be a bit optimistic, because we were:

• 5 part-time people, 
• located in two countries (6 hours apart)
• working no more than 40% on the project
• working for five different companies, and
• only 2 people have been involved for the entire project.

Despite these obstacles, we did produce a cool product (IMHO) and we enjoy working together (also IMHO)!

As we have gone through process of creating WordPress-based web presences using Scrum, I have learned a couple lessons which I will carry forward.

1. Produce something that works every week. This is a wonderful constraint which prevents both individuals and the project as a whole from wandering off.
2. Do functionality first. It’s easier to get the design right when you know what the system is supposed to do. You may even iterate on your target audience, which would cause the design to change.  A good design requires understanding the deeper why of your system or product and its customer and users. Especially in a startup context, it may take awhile for that to emerge.
3. You can iterate on design. An excellent template architecture is a helpful, so most of the changes are in CSS. In our case:
• Version 1 focused on functionality only. It had just enough design, standard templates really, so that we could work with the system. 
• Version 2 was slightly embarrassing, but more or less attractive. People could work with it, but there was some stuff that was bad or downright evil in design or usability. 
• Version 3 – what we are about to publish – is something for the public, and even here, we are implementing it in iterations 3.1, 3.2, 3.3 etc. We designed for the overall goal (market, usability). We started implementing and deploying with the most visible pages. Then polish and minor pages.
• Don’t break stuff that already works. 
• Postpone activating design elements that require new functionality, until the corresponding functionality is present. For example, we want to do some fancy pop-open login and registration widgets, but those are going to wait until we can implement them.
4. Trello is your friend for communication. Trello is nice lightweight Kanban board. Our workflow is basically: Backlog->Ready->Forecast->In Progress->Ready to Review->Ready to Deploy->Done. We use tags, columns and email notifications to enable rapid and effective communication throughout the team.
5. Focus on getting things done. We agreed to always pull from the rightmost column on the board. Spillover, is almost always sign of something bad. The story might be too big; the acceptance criteria might not be clear; the team member might be working on something else. or the team worked on it at the last minute. 
6. Grow up, then grow out. First we added functionality to WordPress, often in the form of a new plugin. Then we discovered what we broke. Since many plugins are poorly documented, and the interactions between them even less so, we couldn’t always prevent things from breaking. So we fixed everything we could find before moving on to new functionality. Basically a stop the line mentality. In Trello, we added a column “Bugs” and tagged the items in yellow. If a bug was present, it was handled with top priority. This is getting things really done!
7. Definition of ready is your friend for getting things done. For each column in our Trello workflow, we created a permanent card with the definition of ready to enter that column. To enter the Ready column, each story had to have a how-to-demo checklist. This makes it much easier to know how to implement the story and how to confirm that we have achieved the goal during the Review. To leave Ready and enter the Forecast column, the team (member) had to be confident they could get the story by the end of the sprint.
8. Do the work at the beginning of the sprint. Did I say get stuff done? Get it done early. The biggest danger with part-time staff is that they work on other things until they feel they can’t postpone your stuff any longer. If they do their 20% on the first day of the sprint rather than the last, their chances of getting stuff done are much higher! Getting stuff done also removes a major source of tension between the players in the project.
9. WordPress is the friend I love to hate. There is plugin for that. Yes, and the interactions between those plugins can be quite unpredictable. It enabled us to get started quickly, but I suspect before our product is done we will have reimplemented all of the key plugins to suit our needs. I’m not complaining, because my site is live and I can generate potentially revenue to pay for that development.
10. Automation is your dearest friend. This includes virtualization, backup and source code control. Yesterday, a system programming error during the sprint review managed to destroy all three instances of our system. Embarrassing, but…  We recovered the system by creating a new virtual machine on linode from the daily backup, restored the WordPress configuration (database) from the daily Updraft Plus backup, and the current file configuration from the source code control. 45 minutes later we were back online and there was no impact on our schedule. If fact, we are actually deploying a week earlier than I had hoped! We will also get better reliability, because this incident convinced us to separate test and production on separate nodes.

What is the best possible step forward for the business, given what I know today?