Skip to main content

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

How do you use Scrum when you're
  • 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.
As a final thought, for me as Product Owner (and entrepreneur), Sprint Planning is an opportunity to ask:
What is the best possible step forward for the business, given what I know today?

The answer might not be software development. I ask myself that question every week, and it really helps me to do the right thing!


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…