Agile Checklist from the Trenches

I've been working on projects for a number of years now. Whilst I'm not claiming to be a certified Scrum Master (which personally I don't think you really need to get certification), if you go about managing projects with a sense of common sense and realism, adhering to core principles, not only adopting a process but ensuring consistent implementation of the processes -- then you're bound to be successful.

Most of my experience with Agile/Scrum comes from running multi-site projects, with teams situated in different parts of the world, with shared product ownership. One can maintain the spirit of Scrum in such projects, but it requires some management and oversight...compared to the classic small person teams of 10-30 people located under one roof, in the same building, on the same floor. Physical location is important. It is really quite interesting the effects of geographical location of development teams plays on the success of the project, the dynamics of the team, and the overall end-goal of product quality. It's not as straightforward as this, just Google for "multi-site software development". But still, on principle, managing a small local team of mixed individuals versus a global team, incurs less management overhead but share underlying Scrum philosophies.

This post is a brain dump of my lessons learnt and observations so far with Scrum/Agile, the headings comes from an Agile Refresher workshop I attended last year at my previous company but the explanations are all my own opinion.

Hopefully you apply some of these learnings to of your own Scrum projects:

Best Practices - multi region projects

1. Team Setup

• No one man teams
• Ensure all people are given equal opportunity to choose tasks, even though there might be an expert in the team that can do most, if not all the jobs on his/her own. Avoid allocating work to specific technical experts, embrace knowledge sharing. Use the experts to help with user stories and work distribution
• Consider and assign people with multi site collaboration skills
• Working in a multi-site team requires to have people who are skilled at soft skills, a natural talent for bringing people together and engaging in meaningful discussions despite cultural differences.
• Consider if you have to duplicate roles on sites, e.g. have a proxy Product Owner (PO) or Development Owner (DO)
• If the local and off-site teams are equally sized requiring similar management overheads, consider adding proxies on the remote site - as this enables some central control and synchrony. Challenge with this of course is for the local & remote POs to communicate and understand each other well

2. Align Expectations

• Set clear vision and get team buy-in
• It's important to set clear goals for the project, and directions for all the teams. Propose, instead of direct how the project will be structured, involve the team in fleshing out the organisational structure since the team members know best what their strength's and weaknesses are - bring all of this to light at the start of the project creates an atmosphere of inclusion, better chances of getting team buy-in, because the team will have contributed to defining the vision and be determined from day one to actively contribute to the success of the project
• Define roles and responsibilities
• This is important to all development processes, not just multi-regional.  Clear roles and responsibilities must be defined so that people understand what's expected of them. In local and remote teams, this thus avoids duplication of work, people are less-likely to step on each other's toes, or choose work without first understanding the process of getting new work assigned to the backlog. In the case of strong minded technical people who are confident and self-motivated, try to give some responsibility and autonomy to these guys for example, being the proxy PO or DO. 
• Define decision process
• This is quite important in keeping with defining the roles and responsibilities. Decisions need to be made quickly, it's about reacting to the current need, wearing the hat of pragmatism. Beware of strong minded and loud personalities, ensure that everyone buys-in to the decision process - be clear as to where the buck stops! 
• Define success criteria (for a  multi regional collaboration)
• In the end we not only want the project to be successful in terms of meeting its objectives, we want the team, the people that led to completing the project, finish the project feeling a sense of accomplishment, having learnt something and for the team to grow from the experience. 

3. Communication

• Set-up Communication Structure
• Face-to-Face
• This is always preferred where practical. Certainly with local on-site teams, F2F should be encouraged. Discourage email and phone calls especially when the team is co-located. Be sure though to limit the number of meetings - meetings must have a purpose and add value to the project.
• Video Conference (weekly)
• The next best thing to face-to-face is Video conference - especially with remote teams. Ensure you have the right tools that enable a please VC experience.
• Email Distribution Group
• Setting up an email distribution group is useful for quick, directed communication. Beware of unnecessary email though.
• Reporting (team internal, group, external stakeholders, etc)
• Agree on the reporting mechanisms up-front, with clear owners for reporting. Keep the local Scrum management fluid, less admin heavy and try to make public whatever the team is up to. Do not spend too much time generating reports that no one will read.
• Iteration planning
• This might come as a surprise to most people new to Scrum, but you have to have a clearly defined iteration planning process, including pre-planning, analysis and design, etc - ensure the planning sessions are well communicated in advance, keeping an up-to-date backlog that is publicly accessible is also good practice.
• Demos
• Demos are key to communicating to stakeholders the progress of the project. Ensure regular demos are held, made publicly available - communicate via email, wiki or blog - but get the message out to your target audience!
• Shape Communication Culture
• No matter what school of project management you come from, there is an underlying problem in all: Communication, communication, communication. Instil this culture by:
• Provide feedback
• Continuously seek out opportunities to provide feedback at team level, or even at individual level.
• Create Information flow (using email group and other means)
• Don't hide information - open and transparency helps as long as you're confident the team can deal with this information, otherwise it has to be limited information flow
• Make sure everyone has the necessary information, be inclusive
• Everyone one the team must have the information to help them get the job done - there should be no secrecy
• Be open about language issues - create a culture where it's OK to ask for repetitions
• This is important because for most remote teams, their first language is most likely to differ from the core team on location. Cut-short whatever cultural blame-games are going on, instil openness and be frank that there is the language barrier - the team must respect this difference and be patient to repeat discussions or instructions if required.

4. Agile/Scrum

• Create common understanding of what Agile means for your project, including Retrospectives every iteration, Shared Backlogs, Iteration Demos, etc.
• It is important the entire team understand what Agile/Scrum means and how the project is going to adopt those principles. Get all misunderstandings corrected and clarified at the outset, for e.g. the myth that documentation is not required, etc, etc.

5. Team Building

• Early Face-to-Face meeting - cross pollination
• As pointed out above, face-to-face is personal, adds human touch - helps with getting to know one another. This should be encouraged
• Build Trust
• Generally managers (POs/DOs) take a long time to build trust - ensure that when people come to you to solve problems/impediments, that you act immediately. This will instil confidence in the team that management is listening and can be counted on to solve issues. Protect the team if things are not going well - managers are a shield to the team.
• Create Team Spirit (we want the team to succeed)
• As covered above, encourage peer dialogue, pair programming, etc. Promote team exercises, challenge team in other ways to possibly solve problems not related to work - all of this will get people to gel together, building team spirit
• Be Respectful
• Especially with multi-site teams with cultural differences, respect is important. This can be learnt by promoting cultural awareness. Where the POs/DOs are senior technical people themselves, allow yourself to step away from the problems and let the problems be solved by the team
• Empower - give people responsibilities equally across regions
• Where there is interest from people who have shown competence and can be trusted, then continue to add more responsibilities. Where teams are separated geographically and the skills are equally matched ensure that work is evenly distributed. Where there is a skills gap, try to bridge that gap with doing knowledge share sessions, etc - promote cross functional knowledge, avoid domain experts.
• Recognise Success/Failure equally
• Remember we're all in this to learn. We're working with people - projects will come and go, but the people will most likely remain the same.  Reward successes, and see failures as just delayed successes. Failure is just one step to success, to wisdom - try to understand the reason for the failure and then help the team to overcome this.  Make sure the team adopts a "no-blame, no name-and-shame" attitude.

6. Management

• Project Management (PO & DO) to follow team closely
• Multi-site development teams require some close management, not micro-management - but POs/DOs/PMs must ensure there isn't any hidden festering issues. All the while the management team must adopt the stuff described in the above points
• Be aware of the culture you have in the project/team
• Management team must be aware of the culture of the project, and have realistic expectations
• Intervene when experiencing problems, e.g. by doing Force Field Analysis / Root Cause analysis with the team
• Where required, if you spot the team going down the wrong path - then step in and offer assistance. Don't dictate, be tactful in approaching the problem - ensure you get to the root cause
• Exchange ideas/best practices between projects, e.g. knowledge-bridge
• Helping other projects out as a result of learnings from your project is a nice way to network, promote knowledge-sharing and instil values in the company of sharing knowledge rather than having competing teams
• Inspect and Adapt
• As always, no process is perfect. Neither is a process static. You have to continuously reflect on your processes, team, behaviours, outputs, etc and be willing to change direction, adapt your processes and be open with failure as well...