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…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…