Offshore Agile Teams

Good webcast on offshore development teams using agile (perhaps Scrum). The image below shows the medicine that must be taken - colocated teams. Although it sounds like a tough sell, companies that have done this report not only good results but positive experiences from team members.

The notes in red are mine, pointing out the fact that most offshore teams that I have worked with or know people involved with are operating in a dysfunctional structure.

Technorati Tags: agile, offshore, Scrum, software development

Example of Team Agreements List

Team agreements recently came up at a conference. I picked them up from another coach as a means to help set-up a baseline of expectations that the team can have of each other. They don't take much time to set-up (almost fun) but pay dividends back to the team throughout the project. We start each Scrum Master certification training with a working agreement of what makes a great class.

[2/27/17] I updated the list with some new items that pertain more to technical practices (per XP, DevOps and covered in the Certified Scrum Developer workshop).

Here's an example of a Team Agreements list:

1.    Tell the truth and be transparent
2.    Treat all team members with respect and value other team member’s time.
3.    Value team members’ thoughts
4.    When in the team room, cell phones on low tone and take calls outside of the room. During meetings, cell phones set to silent.
5.    Formal meetings have an agenda, have focused participation and begin/end on time (unless all agree to change it).
6.    Have one conversation at a time including during phone conferences.
7.    ScrumMaster will maintain a calendar in an Excel spreadsheet that will include planned leave and holidays. This will be reviewed and confirmed at start of sprint planning.
8.    Be present during specified co-location days from Monday through Friday, 1:30 pm to 10:30 pm, except for travel. Remote team members can work 9:30 AM – 5:30 PM on Fridays.
9.    Be available by cell phone when needed.
10.    Daily stand-up meeting 2:15 - 2:30 PM
11.    Daily Scrum of Scrums call with US from 9:45 – 10:00 PM (9:15 PST)
12.    Task estimated hours to completion to be updated in Rally/VersionOne/JIRA/TFS daily by 6 PM
13.    Dinner hour is free time
14.    All new code (or code touched) must have unit tests.
15.    At least one story per sprint must have the acceptance tests automated.
16.    One team member must learn something new (take a story they don't know) per sprint.
17.    Limit the number of stories in progress to the number of team members (keeps QA from getting overloaded). Often referred to as a WIP limit.
18.    We must have a team name. And the team name changes if management changes the team.
19.    Developers must check-in their code [every 2 hours, or 4 hours, or daily].
20.    If a developer broke the build, they must undue their change if they can't fix it within 10 minutes.
21.    We must pair on at least one story per sprint. A similar agreement is "We must have at least one mob programming session per sprint."
22.   Leave the code cleaner than you found it (relentless refactoring).
23.   At least [x] items from the retrospective must be worked on the next sprint (typically between 1 - 3).
24.   At Daily Scrum, only the person with the talking stick/ball/rat can talk.
25.   If anyone is late to the Daily Scrum they: put a dollar in the beer/cake/donuts jars, or have to sing and be recorded and uploaded to YouTube (true), tell a joke. Or, one team reversed it - if everyone was on time, the team got cake/pizza/new car. :-)
26.    HAVE LOTS AND LOTS OF FUN!
Technorati Tags: agile, scrum, communication, management, teams, projects

Sample Agenda for a Sprint Planning Meeting

Here's a thorough, high-level agenda for a Sprint Planning meeting. Of course, don't use what you don't need...

1. Product Vision and Roadmap [Product Owner]
2. Development status, state of our architecture, results of previous iterations [Team members]
3. Iteration name and theme [ScrumMaster]
4. Velocity in previous iteration(s) [ScrumMaster]
5. Iteration timebox (dates, working days) [ScrumMaster]
6. Team capacity (availability) [Team members]
7. Issues and concerns? [ScrumMaster]
8. Review and update definition of Done [Team members]
9. Stories/items from the backlog to consider [Product Owner]
10. Tasking out [Agile Team]
11. Issues, Dependencies and Assumptions [ScrumMaster]
12 Commit! [Agile Team]Technorati Tags: agile, scrum, sprint, project management, scrummaster, project manager

Iteration vs Release Planning

Saw this simple sprint iteration and releases comparison chart in a Rally training page. I like the line on the difference of focus - release is "what" and iteration is "how." Just keeping that in mind will help guide sprint planning meetings much better. Also, given that the focus of sprint planning is task-estimating, not story-writing, the assumption is that the top of the product backlog (sprint backlog) is well groomed. Taken from Rally's Agile Planning Step-by-Step Guides.

Technorati Tags: agile, scrum, project management

Should ScrumMasters Code?

One of my mentor's believed that ScrumMasters should be programming as part of their general duties. If you're in IT, it's likely you know some piece of the programming being done, and if not, have the ability to learn some small aspect (SQL, scripting, batch files, etc).

As I finish up my first Rails project several months ago, I learned a number of things. In the end, I switched my laptop over to a dual-boot Windows\Ubuntu machine. I'm been using Ubuntu ever since, and only had to use Windows for old specialty apps (and even those now have web-based versions). I'm emailing, exchanging and editing documents, tracking bugs, organizing and prioritizing work all from Ubuntu. The boot time is faster, installing apps is easier, and viewing all my windows greater in Ubuntu.

I went to Ubuntu in order to get the developer's web site up and running on my machine. Along the way, I've learned about Subversion and Git, production vs. dev mode on Rails, and how configurations are saved and published (or held).

On my current project, I've started using soapUI to help do some testing for the QA team members. By reading a few pages of the documentation, I learned how to automate the tests and use XPath to confirm data items in the responses. Just getting that hands-on to know the versions of our WSDLs, the endpoint changes, seeing data and changes in the payload gave me a deeper and stronger understanding of the work (and challenges) of what the team is trying to accomplish.

I have a renewed belief that the agile project manager is much more effective when their hands are in the code at least some small percent of the time.

If you're a ScrumMaster, are you doing any programming? Would it help? If so, how? If no, why not? If you're not a ScrumMaster, but a team member, how would you feel about your ScrumMaster getting involved in this way? What if it meant asking more questions, learning and perhaps even making some mistakes?

Technorati Tags: scrum, project management, agile, scrummaster, programming

Kanban and Scrum, Black Box and White Box

This post is a good description of Scrum vs. Kanban - Scrum is a black box (and I'd add "a closed black box", isolated from the Enterprise, but that's part of why it works) and Kanban is a white box. It seems part of the success of Scrum is it's simplicity - you can cover the process, roles and artifacts in 10 minutes. But my experience is that it works best out of the box in small, flat, focused, and/or aggressive companies and needs adjustments for other environments (not thrown away, just adjusting). I've seen some throw it away because Scrum didn't work immediately and easily. Scrum is not a panacea, but commitment and tailoring when needed (e.g., combined with Kanban) will still bring success.

Technorati Tags: agile, scrum, kanban
Trackback: http://www.typepad.com/services/trackback/6a00d83452ee9169e2011571fcf307970b

Improving Retrospectives

For years I've done the classic retrospective at the end of each sprint, asking the team "What worked? What didn't work?" or "More of? Less of? Start? Stop?" But I tried some new techniques recently, and the response was much better.
Most importantly, I used several ideas listed and described in Agile Retrospectives. To start, I asked the team members to choose one of four categories to represent how they felt about being there. This helped to focus and confirm what they hoped to get out of the meeting. I then clarified our values, updating our team agreement with this key, guiding information. The last thing I did was have each of the team members write down 5 idea for improving our scrum. After collecting their papers, I wrote them down on the wall and had the team come up and cast four votes per team member (we had about 20+ ideas).
Throughout the rest of the week of sprint planning, their clarified values and top ideas/problem solutions were referred to again and again, and really helped to shape and guide how the user stories and acceptance criteria were crafted, as well as how the tasks were broken out.
You can also use the "What worked/didn't work" at the end of any recurring meeting in order to improve it the next time.
I highly recommend Larsen's book. The return on investment for improving your retrospectives is significant.

Looking Outside for Ideas

As much as people want to "think outside the box", it really is very difficult to think of an idea or a viewpoint that you wouldn't naturally think of.

As recent Wall Street Journal article describes how Campbell Soup is looking outside for ideas (MarketingProf's summary here). This same approach that a gold mining company took is described in detail, including the great results, in Mavericks at Work.

If this is a good, successful idea, how are you doing it? Scenarios could include asking a Scrum Coach to review your work (your product backlog, sprint backlogs, user stories), setting aside time regularly to read on the topics you're involved in at work (Scrum, QA, automation, tools, the business sector you are in), and setting up periodic meeting-of-the-minds, whether trusted colleagues, a conference or seminar.

I have not once regretted the time I have set aside for any of these. There are always new ideas that I never would have considered that were immediately application to situations and challenges that I was facing. Yet I still don't make it the priority that reflects the value it is.

How about you - where do your ideas come from? How do make sure you put things in place that help you at what you do?

Story Card Template

As I was setting up another new project in a tool I use, I reviewed the default template used for the story cards. Although I always only use parts of it depending on the project, I think it's good to review all of it each time to consider what the needs of the new project are, rather then be unthinking somewhat and stick with "what works" in a general sense. The template follows:

Story Card Description

The 2-3 sentence version of what the card is about

Business Context

Why is this valuable to the business? What is the goal?

Scope Exclusions

Call out anything that is explicitly not included in the card that could be inferred.

Prerequisites to Card Development

* Other story cards that need to be played first
* Data requirements

Detailed Story Narrative

Step by step description of the happy path scenario. Can be numbered or bulleted. Alternate flows can be captured in the acceptance criteria.

Validations

Include any special business rules or validations here.

Authorization

Include special security requirements here.

UI

Indicate what views are impacted by the card. If possible, include a reference to a low-fi prototype.

Additional Notes for Developer

Include any additional notes that you would like to include here to help the developer understand the context of the card.

Open Issues

Include any questions or open issues that we don’t know the answer to when writing the initial draft of the card. Often phrasing the issue as a question and following it up with the solution clearly labeled as the ‘Answer’ helps with readability.

Sample:

Should there be any restrictions based upon the party being a minor, a fatality or having legal representation?

Answer: No. At this point in time, the business has asked for this as a convenience feature that will always bring them directly to edit mode. Even when these scenarios occur today, the Contact Tab is filled out and the Contact Notes will indicate details about the contact (i.e. spoke with the parents of this party or the next of kin).

Acceptance Criteria

Things that the BA will verify during card signoff. Will be used as the starting point from which QA will expand when creating their test cases.

Scenario 1: Description of Scenario

1. Step 1 to demonstrate the criteria
   
2. Step 2 to demonstrate the criteria
   
3. Step 3 to demonstrate the criteria …