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 …
   

Problems with Mingle Project Management

I like Mingle, but it's not perfect. I've posted a few times about the benefits of using Mingle, so now I'll mention the problems.

We had read of performance issues, but I experienced where the cliff is. We have Mingle running on a virtual server with 4 GB of memory. We created a custom project using one tree and approximately 15 fields in the card. As we approached 1200-1500 cards in the project, performance dropped significantly. Users could count to 10 - 30 before items loaded, especially in grid view. As we neared 2000, grid view failed completely. Users new to Mingle started asking for another tool. Stakeholders in planning meetings would lose their patience waiting on it. My advice is find a way to keep bugs and features separate. Delete old, fixed bugs, and be disciplined to keep the features list (product backlog) short. Why keep low priority items when there are months of highs in the list?

Exporting data is a pain. Cut and paste text into Excel gets you by, but you can't use any filters (WHERE clause) nor choose what fields to include or exclude. You get it all. Massaging it into something useful for management can become hours per week if you have large backlogs.

As far as I can tell, you can't enforce data integrity. I tried without success. And garbage in\garbage out feeds the two items above that can become a monster.

The project templates look wonderful (XP, Scrum, Agile Hybrid), but there's only one thin page of documentation on their site for each one on what comprises each template. Trying to figure out how to use them (what the workflow is, the objects, details) is essentially up to you. Don't get me wrong - I really appreciate these views into how Thoughtworks does agile project management, but as I kept poking around, feeling like I was trying to put together the lifestyle of some ancient race based on artifacts, I kept thinking, "The creator of this template could have taken one day to document it and the whole world would be ready to go." As is, the whole world will play Sherlock Holmes and my guess is many will give up and go to what they know and lose out on a great agile mind-share opportunity.

agile, scrum, xp, extreme programming, project management, mingle

Agile Planning Poker Rules

I posted earlier on planning poker, and since it's a popular post, I thought I'd post again on it.

One item that came up in a recent sprint retrospectives (in the "Where do We Need to Improve?" list) was getting better requirements and estimates. So, after the following planning meeting, where the CEO selected his highest priority items, the team met to review those items.

The meeting seemed to be another poor meeting of nothing definite or different being done - lot's of "Well, I'll need to look at that one more," or "Well, management says it needs to be done by next week, so what does it matter how long I think it will take?". I was ready to call the meeting until Martin asked about the planning poker cards (shwag from Phil Scott at the Agile Panel Discussion at the LA Code Camp). He hadn't used them before so we walked through the instructions:

1. Each team member is given a set of cards.
2. One person read the item to be estimated.
3. The team & customer discuss the item.
4. Each team member privately selects a card representing his/her relative estimate.
5. After all have chosen a card, everyone shows the chosen card.
6. If all estimates match, that item's estimate is complete.
7. If estimates are not the same, the group discusses the differences (focusing on the outlying values).
8. Repeat until consensus is reached.

Few notes on modifications we made to the rules -

• We don't have any business members there, but call in the requester if needed.
• We re-estimate until within one card value of each other, or take the median value if there's a majority.

The team really enjoyed, and benefited from the experience. The secrecy of each persons' pick not only made it fun for them, but it got each person so plugged into the task at hand. There was kidding of those who's estimates were way outside the norm. For outrageously low estimates, we rewarded the low-bidder's confidence by giving them that task, but with an agreement that if they met the estimate, we'd buy them lunch. It was particularly enjoyable to see how much this engaged Jeoff, our only team member with the strength Competition. There was great discussion on all the tasks the team had ahead of them, and we left the meeting with a lot more shared knowledge, both where we're weak and where we're strong.

You can buy planning poker card sets from Mike Cohn's Mountain Goat Software site.Technorati Tags: agile, scrum, project managment, software, team building

Agile Leadership Coaching Quotes

I was at a leadership coaching event and had these quotes as good takeaways. Although the training wasn't specific to agile environments, I think they all apply quite well.

• It's a leader's job to make the goals clear, and the team's to make it work. 
  
• In a dynamic environment, it's more important to have strategic positioning than strategic planning. 
  
• The fix for bad leadership isn't teams or teamwork, it's good leadership. 
  
• You don't know what you're capable of. 
  
• There's often a gap between information and application. 
  
• What are your growth hashmarks? Because speed acclimates and it will be hard to tell if you are growing as a leader or not.
  
• The ideal situation is the right job [or role] + the right mindset.
  

Agile Project Management Tools - Mingle, Rally, or...?

I previously posted on comparing different agile project management tools: Mingle, ScrumWorks and an Excel file with dates, hours and a burn down chart. After hearing several agile consultants at Code Camp, I thought I should pass on their (better?) response. 

The question on a tool recommendation came from an audience member who said they had been using Rally, and end the end required one person full time just to manage the tool and data. KenKolcheir, who works for ThoughtWorks, obviously recommended Mingle, with a laugh, but I heartily agree it is a great, easy to use tool. Denise Phillips recommended VersionOne.

But the consensus from all the panelists was to keep it as simple as you can. If you can get by with cards on Post-Its stuck to a wall, do it. Also, this method provides a ready "information radiator" that helps visibility, communication and focus for those nearby or come and go interacting with the team. If you choose to use a the tools from ThoughtWorks, Rally, VersionOne, or Microsoft's Team System 2008, it would be very helpful to have a large monitor or fatscreen on the wall with your cards or a dashboard (with burndown, etc) as the information radiator.

I tried Post-Its, but switched to Mingle so our CEO could access the product and sprint backlogs from his computer and be more directly involved. This is what we needed and has been a key to the success of the organization really getting behind scrum.

USC SoCal Code Camp Presentation Docs

Below are the handouts used for the presentations at the SoCal Code Camp at USC. 

Session 1 - Leading a Team and Developing Team Members - Currently or hopefully leading a small team, managing a project, or over a department? We reviewed the research from several top management experts including Jim Collin's Good to Great, Marcus Buckingham's First Break All the Rules, and Ken Blanchard's One Minute Manager. Using agile as our team context, we reviewed leadership, management, the difference, and what is the role of management today when agile teams are self-managing - the Agile Manager and organizational change. The handout is here. 

Session 2 - Agile Scrum Method with Strength-Based Teams - This session was an overview of the Scrum agile process, tools I've used such as cards and Mingle, and highlights a strengths-based approach which takes advantage of using team members for tasks and roles where they are more likely to excel. Scrum is simple (but not easy) and a tremendous help to achieving success in projects. Agile environments are designed to capitalize on each individual's unique strengths, but there's not much guidance out there on how to do this. This workshop reviewed the different approaches and levels I've used with a strengths-based approach on my Scrum teams. The handout is here.

Session 3 - Discovering Your Strengths - What are you naturally best at? How can you leverage that to become world class? It might be innovation, bringing out the best in others, or knocking out task after task. Many of us don't know our strengths, much less how to build our work day and careers around these natural talents. Instead, guided by our managers and others, we become experts in our weaknesses and spend our lives trying to address these "areas for improvement", while our strengths lie dormant. We review some of the book StrengthsFinder 2.0 and watched the first of six videos from Marcus Buckingham's strengths video series. We covered how to leverage your strengths and how to continue to develop them. The handout is coming...

Session 4 - Agile Panel Discussion with Phil Scott - Neudesic, Denise Phillips, Paul Hodgetts - AgileLogic  and Ken Kolchier - ThoughtWorks. No notes yet but I will try to collect the questions and answers. 

Code Camp Connections

If you are coming to the SoCal Code Camp, you can stay connected to others through the SoCal Code Camp group on LinkedIn. Click here to join and connect with others who are a part of it. Also, you get get real time updates and join the code camp conversation on Twitter. Click here and then click Follow.

Agile and New Ideas for the Enterprise

In a previous post, I commented on what to do after successful implementation of agile to an IT team. What I found from others was that the next step is to move towards the agile enterprise, and I pointed to looking at the P & L and what drives ROI. A complement to this "what" is "how", and a great book on how to introduce this agile growth, and other new ideas, is Fearless Change by Mary Lynn Manns and Linda Rising. It is a book of very practical and comprehensive patterns to use to get support and buy-in, and it is the sum of collected experiences from many professionals.

Despite my best efforts, I often see problems and opportunities through my lens and not through the lens of those I work with. The book references work by E.M. Rogers which breaks down people into groups of Innovators, Early Adopters, Early Majority, Late Majority and Laggards. While I and others in IT, web 2.0, or project management might be Innovators or Early Adopters, two thirds of the world around us are Early Majority or Late Majority. These groups need to see others successful with an idea first, or are naturally cautious or skeptical (they could have the theme Deliberative). Moving a new idea such as Agile Enterprise, with all the visibility and accountability, is a paradigm shift, foreign and likely scary for some of the very people that will not only benefit most from it, but also whom you vitally need their support. From my initial reading of Fearless Change, I believe this book will be a significant help in getting you there. Also, understanding the strengths of these stakeholders will help you speak their language and motivate them.

Book Review - Agile Software Development w Scrum

ASDS is a very good book, but only for the few who want to be Scrum experts. The material is thorough, and not necessarily easy to get through, in part because the Schwaber and Beedle walk through every part of Scrum in detail, as well as cover situations that likely don't apply to most, and they even go through philosophical views that some may care little about.

To be sure, there are gems in the book, and I learned a few important points, but I have been to ScrumMaster certification training, read two other agile books, and been mentored by a CSM/PMP. I feel the book only moved me from 80% comfort level with Scrum to 85%.

If you are a consultant managing projects, or you want to teach, coach or train in this area, read the book. If you a internal project manager,product manager, or IT manager, I recommend you get Agile and Iterative Development: A Manager's Guide and read the section on Scrum. It's simpler, cleaner, and the rest of the book gives good background to agile and options you may want to consider.

If you are a team or development lead, or the senior developer, get Agile Project Management with Scrum. It's an even easier read, focused solely on Scrum and gives lots of enjoyable stories of real situations the author went through, good and bad.

After Scrum, the Agile Enterprise

The other day, Joseph Little (blog here) posted to the Scrum Development board on Yahoo! asking for input on what to include in an advanced course that he and Jeff Sutherland were leading (Agile 201). One item I raised was "What do you do when your agile project efforts are going well? What's the next step to capitalize on successful to move agile into the enterprise?"

Well, I came across a great post on exactly that - Agile Leaders - The Next Hurdle from Steve Garnett. Simply put, the next step is Lean Thinking & Financial Understanding

"It's alright being bloody great at Agile, and knowing how to deliver software and create self-organizing teams, but always remember that the engine for change, the real way to effect change, is control of the P&L."

Agile2008 Conference Submission

Agile2008 released the conference track recently here.One presentation that won't be there is my submission. Though it had some positive feedback, it didn't make the cut.

As the presentation was unique among the others I reviewed, I thought I would post it for others. I submitted it under the Leadership and Teams track. Despite the let down that I wasn't selected, I had a career highlight in getting very positive feedback from Jim Highsmith. :-)


Agile Strengths-Based Teams - How to Coach and Lead According to Strengths

This workshop will review the different approaches and levels I’ve used with a strengths-based approach on my Scrum teams. We will discuss my experiences at the individual level, listing team members’ specific strengths (with descriptions) and how I created new team roles tailored to allow each member to play to their strengths, involving the team in the way they work, and fostering improved communication and interdependency. Also, group discussion could cover hypothetical roles and situations, or run through a simplified strengths assessment for attendess and then walk through how they could make adjustments to leverage those strengths more on their team and with stakeholders and customers.

How Does Strengths Relate to Agile?
Jim Highsmith writes, “Agile Software Development Ecosystems are designed to capitalize on each individual’s and each team’s unique strengths.” and also that “developing each individual’s capabilities” is a key contribution to project success. In the spirit of agile, working with others according to their strengths is part of valuing individuals and interactions over processes and tools. And adding the strengths paradigm to agile project management addresses several key points from the Agile Project Leaders Network Wiki of Knowledge, such as:

• Individual Leadership Style - Involving the team in determining the way they work
• Handling Team Dynamics - Encouraging individuals to self select tasks
• How to generate an open environment where people feel safe to express themselves.

Aren’t We Already Doing This?
Agile leaders should use a strengths-based approach as a tool, but don’t often do. Most people don’t know how to identify their strengths at a granularity that is practical and helpful. Those that do most likely don’t know how to make changes in how they work that enables them to capitalize on those strengths.

Strengths Is Not a Silver Bullet, But an Agile Accelerator Tool
In terms of in terms of productivity, profitability and employee retention, managers using a strengths approach had a 86% greater success rate than other managers. Strengths-based teams performed 44% better. But the most powerful benefit of the strengths movement is when agile leaders use it.

NOTE: Depending on group consensus, have a separate short session or workshop where the group takes Gallup's StrengthsFinder assessment. The results could be discussed, and attendees could then come to this workshop knowing their strenths profile.

Process/Mechanics
Facilitated a discussion on my experiences of introducing a strengths-based approach within a Scrum team at the individual level, listing team members’ specific strengths (with descriptions) and creation of new team roles tailored to allow each member to play to their strengths.

I. Samples of My Agile Strengths Implementation Experience

1. Team Member A has Strengths of ‘Focus’, ‘Deliberative’ and ‘Competitive’
2. Team Member B Goes From Impractical Complainer to Responsible, Driving Junior ScrumMaster
3. Team Finally Understands Team Member C, Because of Her Strengths

II. Review how to leverage strengths for better performance from ourselves and our teams. We would discuss:

1. Strengths themes vs. granular strengths
2. How to grow your strengths week by week
3. Ways to leverage the power of the agile + strengths combination
4. What if there is lots of overlap or gaps?

Finally, discuss how my efforts and experience coaching and influencing the organization in both agile and strengths, and the parallels of improved communication and collaboration.

Leadership is Simple, But Not Easy

As posted on the Mavericks at Work blog, leadership is simple but not easy. Same with agile. In the end, all you can continually do without being fueled by results is to be the change you want to be.

What makes Southwest Airlines successful has been studied, written about and public knowledge for years, as mentioned in the Mavericks blog here and here. But companies still don't (or can't) do what Southwest does.

The success of agile has been studied, written about and public knowledge for years, but companies, and even teams, still don't (or culturally can't) do it. The barriers I've seen are mainly letting go of control and trusting others.