Credit: Sydney Morning Herald. http://images.smh.com.au/2011/04/09/2297260/Adam_Thomson-420x0.jpg
Last time, we looked at the very basics of Agile; with links to some preliminary reading and supplementary.
This week, let's talk a little bit about starting up teams.
How do I get started?
The ideal would be if you spent 1-2 weeks in pre-sprint planning to get setup. At this time, you would:
- Stop referring to people as "resources" or "FTE". They're people.
- "De-mistify" agile for the executive teams with an interactive session (learning workshop is best, but a presentation is also fine)
- Engage the executive level to ensure you have their support to proceed and make (sometimes quite drastic) changes.
- Identify the important scrum roles - see below in "Who are we going to need?"
- Identify the members of the scrum team(s). If there are 3 or more scrum teams, you will need a scrum-of-scrums. That's an advanced topic for later.
- Create a preliminary backlog - see the video above for how.
- Setup required technologies to support this backlog; best of breed are:
- Target Process
- Rally
- JIRA with Green Hopper (actually the least good option, as it is not a pure scrum tool)
- Setup the calendar invites for the ceremonies (see the scrum guide) and set expectation with the team that these are compulsory and trump all other meetings.
Who are we going to need?
In a perfect world:
- Product Owner. This must always come from the business, and must be a direct customer of the product. Ideally he/she is the single business owner of the product being created. Ideally they are at executive level. Remember - they do not need to attend all ceremonies, but they must always be available to the team.
- Scrum master. A full time scrum master should be able to cover 2-5 delivery teams of 5-9 people. An alternative approach is to convert project managers to this role. If this is the case, you'll need an:
- Agile Coach, able to influence both at executive level and guide execution at team levels (you'll only need this if you have a multi-team arrangement; or no-one in the team knows scrum at all and they can't afford to hire multiple outside scrum masters). The Agile Coach should also be able to "coach the scrum coaches" and run the scrum-of-scrums as scrum master.
In a not so perfect world:
- Product Owner: Compromise on any of the criteria listed in "perfect world", noting the below*. Alternatively, promote a Project Manager to Product Owner.
- Promote a project manager to the scrum master role and get a medium-term agile coach (no less than 6 sprints).
At bare minimum:
- You want the best scrum master you can find. A good Scrum Master can also act as Agile Coach in a pinch; and should be knowledgeable about training new Product Owners and other Scrum Masters.
* The most common Scrum answer to "can I do X thing that clearly breaks scrum?" is it depends. Scrum is an extremely lean approach and all of its ceremonies and roles are interdependent and crucial to its success - there is not more "fat" to trim from the process. The moment you stop using any ceremony or change the roles identified, you introduce inefficiency and less rigor It may very well be most suited to the environment and thus "okay" to use in the local context, but it's not scrum. A good scrum master will know all these rules. An effective scrum master will learn which to apply, when to apply them, how to apply not just the ceremonies but infuse a team with the ethos and spirit of Agile. A direct example from above: e.g. not having a single product owner will dilute the prioritization and introduce noise and uncertainty. Not having them empowered (as someone who can make decisions about the product) will severely dilute the effectiveness of the team in verifying value on a highly iterative basis. Not having them available to the team will defeat the ideal of having a consistent, always available voice of the customer on which to verify value and "fail fast".
Who is suited to which role?
aka What do I do with project managers/program managers/executives/external parties/suppliers/vendors?
Qualities of a good Scrum Master - a nice person with fundamental Scrum knowledge. Determination & persistence for continual change for the better (for yourself, for the team, for challengers and challenges). Real understanding of the needs of the organisation and business in the context of scrum.
Qualities of the good Product Owner - commitment is key. Core skills are business process analysis, requirements analysis, product lifecycle management, configuration management, organizational marketing, IT program management and consensus building.
Project Managers
Ask them the question - are they more interested in:
- the scope, value, priority of the product itself?
- the people, tools, process and team development thereof?
If they answered the former, they are a natural Product Owner. The latter, a Scrum Master.
Program Managers
If the project is of sufficient scale to need a Program Manager to whom multiple Project Managers report to, then a scrum-of-scrums if a must. Ask them the same question as for project managers. They are then either the Über Product Owner or the Über Scrum Master.
Executives
It depends. The only role you need to make Scrum effective is the Product Owner, who should be a empowered person who can make decisions on behalf of all stakeholders taking their needs and input into account. All other executives can be stakeholders.
External Parties and Suppliers
The short answer is - what they do does not directly impact the effectiveness of the self-reliant, well-built scrum team who has capability to produce working software. However, in complex environments, external parties and suppliers can represent stakeholders, additional user story considerations or impediments to the scrum team. This is an advanced topic.
Vendors
In a staff augmentation model, a vendor team member is like any other scrum member. Where they belong to separate teams (e.g. a separate testing team for the purpose of doing end-to-end system testing only, or a completely separate development team), they are as an external party or supplier.