Remote Team Members with Agile Scrum

Even under the best circumstances, not having Agile Scrum teams collocated is difficult. There are lots of issues some of which have fairly easy answers, and some don't. We have a partial team in Cost Rica and our teammates in CR have done a great job given the physical separation from the main teams, however it has been lots of issues and difficulties (which I'm sure they can attest to).

• Scrum is about face to face problem solving, decision making, and team collaboration. Some collaboration can be done online and some just happens as talk goes back and forth in the team area. Going overboard with electronic communication in this area (in addition to regularly scheduled communication) is the only way to really address it. Setup web cams, chat clients, and even team area web cams (to catch banter, team play, team work, and all that happens). Of course meetings have to all be connected with audio and visual (use VOIP and remote sharing for low cost solutions). We also did bring the remote developers in-house for a month training. I would consider this essential to starting team relationships that will are ultra-critical for Agile (and three months would be a better time frame than the one month we used).
  
  
• Ultra clear communication required. This is not indigenous to Agile, but applies to any type of non-collocated project team. Having worked at HP for over 10 years with multiple teams around the world, I know that working together with my remote partners required constant vigilance for changes, plans, retro's etc. The big problem is that, with traditional waterfall there is typically much more well defined requirements and milestones that remote teams can work from/toward. With Agile, we have only just enough of everything, including documentation, forcing frequent and face to face communication. This is a tough problem, no matter how good your people are. Of course there are other aspects of communication, from User Stories and Conditions of Satisfaction, to non-verbal communication (which is very difficult with remote teams), and team building. These all have to be addressed and solved.
  
  
• Meetings. Scrum is lightweight. The meetings are essential and critical to success. This means that remote locations (or team members) need to be included for Sprint Planning, Scrums, Reviews/Demos, and Retrospectives. Scrum also requires frequent impromptu meetings, where decisions are made. (Our Product Owners sit with the teams, further increasing the potentially for quick change and decision making). If the team doesn't communicate or connect like it should, there could be serious consequences. The only real workable solution in my opinion lies in making the remote location a team(s) of their own, and they need to be co-located with each other. This can be difficult in terms of economies of scale if you only want to keep a few remote team members - with more team mates remotely together you can save on fixed costs.

From my experience with remote teams in both Traditional and Agile environments, having remote team members will require lots of additional work, usually money, and lots and lots of patience. If you must have remote teams using Scrum, I highly recommend having them be their own team, make sure they have the communications technology and protocols in place, and remain as consistently Agile "by the book" as possible. <><

References:

1. http://tinyurl.com/non-it-scrum

Using Agile with Non-Software Projects

Part of the reason for writing my last blog was to show the essence of Scrum and how it could be extended to other types of non-software projects.

Agility is the ability to both create and respond to change in order to profit
in a turbulent business environment. - Jim Highsmith, Agile Project Management

I read a fun interview with Alistair Cockburn about how he used Scrum to build and add on to his home a few years back. Obviously this is a non-software project and was very successful. The main portions of Agile that he took advantage of were:

• Work Incrementally
• Willingness to make changes on the fly as needed
• Open Communication
• Feedback to help guide next steps
• Daily Standups
• YAGNI - "You Aren't Going to Need It" - do only what's needed, change later if necessary
• Time and material contracts
• Venture Capital Funding (funding as you need it)
• Customer Involvement and steering
• Small wins
• Process miniature
• Developing Collaboration and Trust

Agile Practitioner and Coach Robbie Mac Iver used the concepts of Agile to manage a complex business process in the supply chain domain. Some of the tenets discussed there relating to how they used Agile were mentioned before.

• Focus the team on the real business value
• Clarify the work streams and the alignment of the team
• Enforce what “done” means
• Make progress and issues visible (sometimes “painfully”)

Iver also mentions in his About section on his website that he belives that using Agile for business really provides three important deliverables.

• Effectiveness - Teams are working from the top of list of work that the business leadership has characterized as the most important, the highest priority. As these solutions are delivered, the business sees immediate gains and doesn't have to wait for "everything" (stuff that could have been planned for with longer planning) to be done.
• Information - The business learns very quickly what works and what doesn't. Information is discovered quickly and decisions can be made rapidly without significant loss (as compared to traditional projects).
• Control - The business is given more control because they can see quickly the state of situations and make decisions about which direction to go. They can work on projects that actually produce value, not just projects that might produce value, and stop whenever they have made "enough" progress to provide that value.

<><

References:

• http://www.agileadvice.com/archives/2006/06/interview_with.html
• http://www.swdecisions.com/documents/WP-ScrumForNonSoftware.pdf

Agile Essentials

Agile is a process framework most typically used in software development projects ideally suited for projects with high uncertainty. However the basic principles of Agile can apply to just about any type of context. The founders of Agile have developed a "Manifesto" that describes the basic tenets of Agile.

The four tenets are as follows*:

1. Individuals and interactions over processes and tools
2. Delivery of value over comprehensive documentation
3. Customer collaboration over rigid contracts
4. Responding to change over a detailed plan

Some other aspects of Agile are:

1. Early and continuous delivery of value
2. Adaptive insted of predictive to give maximum flexibility
3. Visibility for good and bad
4. Inspect and Adapt frequently
5. Become iteratively better
6. Result driven tasks
7. Face to face communication
8. Cross disciplined, motivated, empowered teams
9. Sustainable pace
10. Continuous attention to Quality

Agile Scrum (a particular flavor of Agile) arose from proceses that were designed to increase speed and flexiblity in the delivery of business or social value. It is a collaborative and change embracing method that cross-functional teams use to produce high quality deliverables through iterations of work time.

Scrum itself is specifically a lightweight process framework that is designed to focus the teams on delivering the highest priority items first. The fact is, that most projects or programs spend much of their time attempting to deliver some less-than-well-defined artifact, only to find that by the time it's done it's no longer relevant or needed. Scrum defies this by demanding that the highest priority items are addressed first, exposing issues, forcing the understanding of risk and dependencies, and in general bringing visibility to the team and the rest of the organization it lives in.

Read more information about the details of scrum. How would Scrum apply to your context?
<><

References:

1. http://www.agilemanifesto.org/
2. http://www.scrumalliance.org/articles/22-scrum-delivers
3. http://www.mountaingoatsoftware.com/scrum

*For the purposes of abstracting Agile out of the software world I have changed the wording slightly from the original, but it carries the same connotations (1).
* The focus on the first half of the statement doesn't mean that we don't care about the second half and need to consider them.

Agile Defect Fixing

I just read a posting on AgileBuddy about accounting for bugs in an Agile world. The post talked about accounting for bugs, team capacity, and whether bugs should count in team velocity.

It is very clear to me, both from the literature and from experience, that you should account for defect work done in the sprint. You must account for all the work done, otherwise you set false expectations for your business partners, for other stakeholders, and for the team itself (creating a tendency to over task and over commit). There is more than one kind of defect however and they don't all need to be treated the same.

Defects found during the sprint that are a result of coding done during the sprint (sprint defects) should be part of your normal code/fix work. We don't track hours or points for these because they are part of the original story point/task hour plan. This does mean that you have to think about that during sprint planning. We should be planning on code quality, requirements clarity, and the things that create less defects too of course.

Defects found that are not a result of the sprint or that are found during the sprint and the team/PO chooses not to fix them (based on time and priority), are put into the backlog for future sprints. These need to be prioritized by the PO and estimated just like any other backlog item.

If a defect is planned to be fixed during the sprint, we consider it part of the sprint backlog and it gets counted in the velocity. We typically add a "bug" story that gets x number of story point assigned to it, then we add defect tasks that approximate the story point estimation. This allows us to keep working on defects that are found at other times or by other stakeholders/customers.
I don't think that punishing the team by not including their defect work in the sprint is productive. We have a lot of legacy code that the teams are not the originators on and to make them accountable for previous years mistakes (before Agile) doesn't make sense. I do however believe it's important to keep the team accountable to their commitment of story points and to completing the sprint defect free. The basic point is that the team working on an issue, isn't necessarily the one that created it (which can cause mixed feelings and eventually a lack of productivity).

Agile and QA is an evolving process for us, but as we move toward more automation and more consistency in our Agile implementation, we're starting to see better and better results. There is much more to say about defect management in Agile to be sure, stay tuned.

Demo Scripting

Recently we've started a simple, but very effective, process to help our Agile Scrum demo's go smoothly. We write up a short document, called a Demo Script, that describes what we're going to demonstrate for the sprint, and pass it out to the stakeholders before the demo starts. It's very simple, but it has lots of benefits.

Benefits of a Demo Script

1. Start a demo script at sprint planning to begin to understand what will be shown to the Stakeholders. This helps get the creative juices flowing about how the functionality in the sprint is going to be deployed and demonstrated. Some deployments can be very complicated. Getting the team thinking about the end is a good way to mitigate risk and keep the team focused on the right goals. Clearly, the script will change as the sprint progresses, but it should roughly correspond to the commitment that the team makes to the Product Owner.
2. Allows the team some think-time to understand if a particular environment needs to be setup or updated to allow for final demonstration or production deployment.
3. Gives the team a way to write down and walk through the steps they intend to take during the demo (pre-demo demo). This should be more than just a list of stories. It could list specific pages in a website that are visited, usernames/SKUs to look up, particular emails that are sent, or whatever it is that the product is doing. Writing down the steps helps the team understand clearly what they are going to be showing.
4. Gives the stakeholders something they can look at before the demo so they know if they need to be there, be prepared, or pay more attention in particular sections. Provides them a reference for the new functionality to keep with them. Provides an instrument to discuss potential changes or impacts to future/other work/products.
   
5. Helps the team practice in a room if the demo is in a place that isn't dedicated for that or that needs to be changed for some reason.
   
6. Provides a simple release notes of sorts (in lieu of some other more rigorous form).
7. Provides a common point of reference for the team to drop or add an item quickly, before the demo (depending on how soon you send it out).
8. When the team successfully demonstrates all the done functionality on the script, it becomes a statement of their success. Since things that aren't done, aren't demonstrated, the stakeholders are left with a clear understanding of what was accomplished.
9. Provides a way to reference work that didn't have visible outcomes. We always try to link actual end user functionality to every story, however sometimes those stories produce work that is not really demonstrable without taking more time than necessary (like on a sprint where there is no deployment potentially). This hard work needs to be made visible and this provides a simple way to do that.
10. Provides a simple list that support functions in the organization can reference in other discussions to form more complete documentation.

Tips on building your Demo Script

1. Have a good title - Name of team/sprint
2. List the team members names, including the Product Owner
3. Include a list of stories for sprint that have been completed
4. Include a list of steps that will be taken during demo, and then stick to them.
5. Remember to include done and undone work (retain visibility for accountability)
6. Don't include anything that distracts from the work of the team for that sprint. Other documents can fully describe things that need more work, bug lists, future stories, retrospective reports, etc. Including too much can detract from what is being presented.

The Demo Script is, in a sense, both a working document and a marketing instrument for the team. It clearly shows what is done and provides a high level view of the status of the sprint for the stakeholders and user representatives. Use a Demo Script to bring visibility to the hard work completed by the team. <><