Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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...
Work in fixed iterations (say 2 weeks):
Whoever is testing it, should do it within the iteration:
Write Scrum style user stories:
Designate a Product Owner, even if part-time:
Maintain a product backlog
There are 4 more items in the Nokia Test. However, you can go as far as your team finds it practical to do so.
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.
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.
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
"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.
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!
