Agile Team Start-up

A few weeks ago, a junior Scrum Master asked me for a check-list of tasks for starting a new Agile project.  I'm not a fan of check-lists, but this topic seemed appropriate, and useful. It also is a good one to ask for feedback and additions - what would you add to this?

My starting point would be to imagine what a Scrum Master should ask or do when beginning a new, long-term engagement (at least 6 months) at a client location, with a team who don't know each other or Agile methods!  Here goes....

1.Basic Environment

• What is the security, building pass, access times policies of the client location?
• What is the Desk policy? What furniture is available - can you bring in more?
• Can you use the client’s printers, scanners, video conference, rooms, stationary?
• Network, Wi-Fi, Servers, databases infrastructure: Can you use the client’s or bring your own? Who supports them?

2.Team Environment

• Can the team sit together? Who else is around? Can you control how hot/cold, bright/dark, noisy it is?
• What can be used as a physical Scrum board? Can you stick stuff on the walls?
• Do you have a TV or projector for reviews, etc.
• Find a Talk token, Ÿget a notice board, hang posters, calendars, etc.

3.The Team

Assuming the team doesn’t know each other, it is important to create good social relationships first to then build them as a team with a shared understanding, culture and skill base to prepare for development work.  Try to get them from ‘forming’, through ‘storming’ to ‘performing’ as easily and quickly as possible…

• Use team games for Introductions, get to know each other, team socializing
• What snacks, food, music, dress code is acceptable? Not everyone welcomes donuts!
• Collect and publish team contact info, locations (virtual and physical)
• Agree and publish the team’s availability – including PO & SM
• Agree working agreements
• What are the core working hours of the team?
• How to deal with holiday, illness, and absence requests, etc.
• Coaching ‐”Shu Ha Ri”
• This is a good time to offer some Agile coaching to the team to raise their awareness of their Agile journey, for example, through “Shu Ha Ri”.  This helps sets the culture of realistic expectations, improvements, coaching…
• Training. This is also a good time to organize some basic / refresher training in the following topics to bring everyone to the same understanding.
• How to behave as an “Excellent team”
• Scrum
• Effective Story breakdown techniques
• What Tools will we use e.g. for CI, Jira, etc.
• Values: Now the team is forming, what values will it embody?
• E.g. Commitment, Focus, Openness, Respect, Courage?
• Pick a Team name, create some culture
• On-boarding. When new team members join, how will they be brought up to speed? Can the training, teams values be documented? Use a buddy system?
• Future Retro: Now the team has formed, get them to start looking forward to the work ahead in terms of outcomes. A nice way to do this is to hold a retrospective looking forward to the future, asking “What would you like to celebrate at the end of the project?” The focus should be not only on what they deliver, but how the team delivers, how they behave when issues come along, what the client/users/managers will say about them. It also helps practice their first retro in a safe environment.

• Practice review – PO and team: Similar to the future retro, hold a practice review to find out how to hold effective reviews.  Important stakeholders should be attending, so make it as good as it can be.  How are the team’s presenting skills? What room and setup is best?  What progress indicators will the team show?  The review subject can be all the activities the team has done so far. 

4.Ready to Sprint

After building a functioning, informed team, the final stage is to get ready to Sprint, to identify the specifics of Scrum and the vision and existing backlog of the project. These should be carried out by the team collaboratively:

• Choose an Estimation scale (e.g. Fibonacci) and  Identify stories as references
• Write the Definitions of Ready and Done, and publish them
• Choose a Sprint length and schedule, including:
• Sprint Start day
• Planning location
• Daily stand-up time and place
• Review, retro
• Backlog refinement
• Product Vision, Features, Non-functional requirements.  This is where the Product Owner can now step forward and introduce the team to the specifics of the product, presenting the business situation, current backlog, risks etc.
• Milestones, phases, release plan: How has the product schedule been planned – e.g. Discovery, Alpha, Beta?
• What Metrics will the team publish? What is their audience, their ownership and frequency?

Round Up:

One of the key parts to a Scrum Master’s role is to guide the team’s success and productivity, and the most important part of this is when the members first come together.  Once these points have been met, the team will be in a great place to start development and negotiate the challenges during the lifetime of the project.

But is there anything more that should be included?  What would you add or change for your teams? please add your comments below.

Team Culture: difficult to change

I find that one of the most difficult aspects of change a team may have to undergo is one of culture.

Changing the membership, meeting times, workload, locations etc of a team, its relatively easy to get buy-in, as long as you give good reasons and gain consensus.  But there are other aspects of moving a team to an agile way of working that call for much deeper and controversial solutions.

Many teams (including my current ones) on their first agile project still have old-style tendencies that hinder best performance and becoming fully agile.  For example, even within the same team, there can be an "Us and Them" attitude between developers and testers, and at times with POs also.  While these are obvious divisions, this is in the context of traditional management methods which set up these divisions for their own convenience.  But this can be a continuous source or argument, shirking of responsibility and, frankly, arse-covering which all detract from productivity.

To be fair to my teams, the culture of the project did not start with Agile - in the beginning it was a traditional, quasi-waterfall project with design, 3x development and test teams, all with team leaders and managers in the usual hierarchy.  This has been a difficult culture to change: we still need the people who are the team leaders, even if their role has diminished significantly, but this preserves the divisions between them.

One of the central tenets of Agile is its focus on teams, teamwork, and working together towards a goal, and so members need the space to be flexible and adventurous in working outside their comfort zone role when needed.


One example here is when a team realized they didn't have enough test resource to test all the stories developed by the developers.  When given this problem, the team mulled over the suggestion of developers testing each others code, with a caveat that a tester would still do final testing.  Most of the developers were ready to do this, but when pushed, the testers - and test manager -  somehow managed to find enough time to do the testing after all (by working weekends!).

Another example is within the test team themselves - when none of the Siebel tester's in a team would test a Data migration story because "they don't do that"

A true cross-functional team would allow this to happen - in a controlled and visible way so as to maintain quality - but also to enhance productivity without using more hours.  But I felt that while the old divisions remain, Agile's goal of super-productivity can only be approximated.

To help solve these problems, or to try to break the divisions can call for difficult decisions, such as the obvious one of removing the team leaders - but this is often not possible or popular!  Better to engender a new culture of sharing, team-ownership and safety to allow team members to be adventurous.  This could be done through workshops where testers show developers how they test, and vice-versa, and inviting testers to develop some stories in line with their ability (Testers are often good developers too).  Not only does this encourage all the good things of agile teams, but supplies a form of training and teamwork not possible in traditional methods.