5

I know that Scrum team is between 3 and 9. But it's quite often that the initial bootstrap project team is of two developers. What specific set of practices would you recommend for them to follow in order to be focused and efficient?

Should they plan Sprints at all? Should they conduct daily standups etc...

  • A Scrum Team is officially 7, plus or minus 2. This is very specific and turns out to be supported by a fair amount of neural science.This is not to say you can't have agile teams larger or smaller. Just to official definition. – Joel Bancroft-Connors Mar 7 '15 at 22:57
  • @JoelBancroft-Connors 3-9 is Scrum Guide boundaries. Anyways, both definitions keep team of 2 out of the play :) – Vadim Tikanov Mar 8 '15 at 23:40
  • Sometimes it helps to go back farther. The 2009 scrum guide says "The optimal size for a Team is seven people, plus or minus two. When there are fewer than five Team members, there is less interaction and as a result less productivity gain." There is a reason for this, there is hard nuero science. If I had to guess, the change in the 2013 version was to try and make Scrum more competitive to XP. Optimal team size is 7, +/- 2. This isn't an agile thing, it's a people thing. All respect to Ken, he can't rewrite nuero-psychology. – Joel Bancroft-Connors Mar 9 '15 at 0:02
6

You can use the Nokia Test as a starting point

The Nokia Test (also known as the ScrumButt Test) was developed by Bas Vodde of Nokia and tuned by Jeff Sutherland, the co-creator of Scrum.

  1. Work in fixed iterations (say 2 weeks):

    • You can establish a velocity that is valuable for release planning.
    • Helps to avoid the death march at shipping time by maintaining a steady pace.
  2. Whoever is testing it, should do it within the iteration:

    • Stories should be 100% complete to avoid any crisis at shipping time.
  3. Write Scrum style user stories:

    • Opportunity for close interaction with stakeholders.
    • Allows you to respond to change.
  4. Designate a Product Owner, even if part-time:

    • All requests for change in priority flows through one person.
    • Gets stories 'ready' with acceptance criteria before iteration starts.
    • Owns the release roadmap with dates based on actual velocity.
  5. Maintain a product backlog

    • Makes visible that lower priority stories may not get done.
    • Clearly specified and prioritized by return on investment (ROI).

There are 4 more items in the Nokia Test. However, you can go as far as your team finds it practical to do so.

3

Could use a little more information about the team. Do you have a product owner? A designer? Any other contributors that you wouldn't consider "developers"? Or is it just your dynamic duo against the world?

At your size, scrum is too much structure, I think. If it really is just the two of you, just work in the same room, if possible. If you can't, keep a shared digital collab space, whether it's for sketching, file sharing, or whatever (set up an online OneNote book, a Trello board, and/or a HipChat/Slack team space sort of thing--whatever works for you).

Remember that two of the biggest benefits of scrum are visibility and communication. As long as you're aware of what each other is doing and constantly on the same page, you can avoid the strictness of scrum until you've grown a bit. And even then, you might not need it. Scrum is great, but it's not the end-all-be-all of agility. Pay attention to how your team works and what kind of improvements you want to make. If sprints aren't helpful, don't be afraid to do pure, pull-based Kanban. Agility is about constantly improving, and scrum is just one of the experiments.

3

Be Agile, don't necessarily try and do scrum at this point since it may be overkill for such a small team. Consider borrowing these ideas from Scrum or Kanban:

DO CONSIDER:

  • Visualizing all work on a storyboard or Kanban board

  • Writing Agile stories using INVEST principles

  • Writing Acceptance Criteria

  • Having the 2 developers agree and commit to a definition of done

  • Define at least the following steps in your work visualization: defined, developing, testing, staged, production

  • Having a daily scrum or stand-up to build communication discipline

  • Having retrospective-like checkpoints often and ad-hoc, allow the team to define what to change and how long to commit to the change

  • Planing and reviewing work increments often and ad-hoc

  • Empowering the team to try new things and if they fail, fail rapidly.

DON'T

  • Ask the team to follow any framework without them understanding the value of all parts that compose the framework.

  • Implement formalized processes without the team buying in first or understanding what problem they are trying to solve with the formalized process.

  • Take it personally when the team wants to rapidly change parts of their process.

3

The most viable agile practice is fast feedback. That's why short iterations are preferred. The next one, directly connected with the planing, is customer collaboration. You have to meet with the customer every 2 weeks, discuss the things you are going to do, then run 2 week sprint avoiding any interruptions, then demonstrate what you have done and ask for feedback. Repeat.

The daily standup may be quite informal when there are just 2 people, but I would suggest that you still have fixed time for this meeting, as on this meeting everyone (the customer for example) is invited as well. The most important part however is to keep track on the progress and impediments, as well as of the focus on the sprint goal, as during the sprint most likely you will have to decide what to drop and in what to invest more time

  • Spot on. I'd say if you're looking for a formal framework, Extreme Programming is going to be a good place to start. – Joel Bancroft-Connors Mar 7 '15 at 22:59
  • I agree with keeping a fixed daily standup, even with a team of two. I once ran a project with three, and we thought we didn't needed as we we're sitting together in our own little corner. But we struggled and starting again with a daily standup really helped to get focus and flow. – Stephan Mar 9 '15 at 9:22
0

"The most viable agile feedback is fast feedback" is something contestable specially when working on a agile framework. Agile may really get confusing and lead to scope creep with short iterations, agile scoped, and no scope (with a fast feedback mechanisms changing priority structure of development). Agile does not mean no scope or no schedule or no plan. It just means we develop products with agiled scope. While scrum is good and agile is fad; but only until it does not lead to scope creep and changing priorities due to constant feedbacks or any other that changes direction/duration/quality of development of product. Not sure why I would not use scrum for 2 or more when needed; and just restrict to 3-9 or... @Ashok - Nokiatest is good start point.

0

The only agile practices I always recommend are creating a product vision and regular demos. If you can't agree on what the product is supposed to be, then you can't build it or make technical decisions. If you aren't using demos to get feedback, then you can't tell if you're making progress. The choice of where to go next depends on your situation.

If you are working for a client and need to make on time delivery commitments, then Scrum is a good place to start. Create a product backlog and prioritize it with your customer, estimate the product backlog with your partner (stop estimating when you've identified enough work to fill two weeks), and run your first iteration (two weeks) to see how well you estimated. End the iteration with a customer demo and get feedback (if you're not getting feedback you're not practicing Scrum). Iterate again over the next top priority deliverables. Daily Scrum meetings are optional for super small teams, but speak daily and keep any roadblocks in the open so helping each other solve challenges becomes routine. Once you've worked out how to set expectations with your client, then see if any XP practices will help improve your velocity and quality.

If you're working for yourselves, then starting with Extreme Programming (XP) practices is a smart way to go. Begin with configuration management (for example Git + GitHub or GitLab). Add automated testing to decrease the time you're manually testing and increase time available for new development and optimization. Once this foundation is in place, introduce Scrum and then continue to add technical practices that you think will add additional value to your workflow.

Remember, Scrum and XP are just templates, yet neither is part of the original Agile Manifesto, so don't let the details bog you down. Scrum is about improving your ability to reliably make delivery commitments and XP is about improving quality and working smarter to have more time for making your product. Pick the methods that work for your team and invent new ones!

  • I can add links to resources if this answer is helpful. – Michael Hogan Mar 16 '15 at 17:48
  • I added some links to more information. Mike Cohn and James Shore have useful books on these subjects. For a small team, Curt Hibbs' The Art of Lean Software Development offers high impact recommendations and is a great place to start. – Michael Hogan Mar 17 '15 at 4:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.