Onboarding a Team to Agile — The Process Part

Are you thinking of just jumping in and seeing how it goes? Do it! The four methods below are at the core of most what most agile teams actually do.

1. Iterations

Core to agile is the practice of working in discrete iterations. Iterations are one to four week periods where you start with a prioritized list of ‘user stories’ you want to implement (see below) and close with some amount of working software. You don’t necessarily need to release that software if you’re not ready, but it should be ‘potentially shippable’.

These iterations usually have four chunks: A) Plan, B) Work, C) Demo, and D) Retro.

A) PLAN

I know what you’re thinking—‘hasn’t this guy just been rabbiting on about how plans are bad?’. Reasonable question. I used the term ‘plan’ here because that’s what’s in general circulation, but really this step is more about refining your inputs (in the form of user stories—more on those soon), and prioritizing the user stories.

As you can see in the diagram below, the main articles (in yellow) are a series of ‘backlogs’, which are lists of user stories sequenced by priority. You start with a master list of stories (Product Backlog), pull roughly the amount you think the team can do in an iteration (Draft Iteration Backlog), discuss them, and then arrive at a prioritized list for the iteration (Iteration Backlog). The most important part of this discussion is making sure the team understands the stories and their value for the user. A healthy planning session involves lots of questions, revisions to the stories, and usually some sketching/wireframing.

To help the discussion, some teams estimate (very generally) the size of the stories to help prioritize the value of the story relative to its cost in terms of time. Not all teams do this, however. Some teams find that estimates lead to excessive planning overhead, contention, gaming, and other bad stuff. In fact, there’s a whole #NoEstimates movement that advocates an alternative approach to working without estimates. Interesting, huh? Rather than trying to analyze whether estimates are right or wrong, decide with your team whether or not you want to try them, and then see if you think they’re making your practice of agile better or worse. That may sound like a lot of work and uncertainty, but that culture of experimentation is at the core of a team’s successful practice of agile.

You may also have noticed the Iteration Goal and Iterations Tasks. The goal (sometimes referred to as a ‘theme’) is a kind of conceptual summary of where the iteration is focused. Some teams find these helpful, others don’t. Stories vs. tasks is a whole interesting topic in and of itself, but basically same deal with those: some teams find it helpful to explicitly put the tasks to implement a story into whatever they’re using to track progress, others don’t.

These planning sessions generally take no more than half a day with part of the team where they revise, edit, discuss (often with wireframes/sketches), and prioritize user stories.

B) WORK

The input to the iteration is a prioritized backlog, the output of the last step (Plan). Team members self-organize to pick user stories to code and (generally) see them to completion before starting another story. The team starts the day with a brief ‘Daily Standup’ (see section #3 below) and, beyond that, formal meetings are kept to a minimum so the team can focus. This isn’t to say everyone works in isolation with their headphones on: informal collaboration about how to approach coding a story (and even pair programming) are encouraged and consistent with agile’s foundation ideas. Once the allotted time for the iteration is up, whatever stories are in working form are the output of this step. Agile iterations are fixed with regard to duration, not content.

The team’s work is often tracked on a kanban board, like the one you see below.

source: By Dr ian mitchell [Creative Commons CC0], via Wikimedia Commons

The basic idea with these boards is to:

  1. Help the team members think in terms of the teams’ agreed-to process about how work moves through their delivery pipeline
  2. Let anyone on the team who’s interested know what their peers are working on so without having to go to much trouble
  3. Make sure work isn’t stacking up in one part of the development pipeline (peer review, test, etc.)

Teams adopt somewhat different (but always explicit) rules on this, but basically the idea is that the story backlog remains fixed during the iteration. The reason for this is to help the team and stakeholders they interface with develop habits around getting working/testable software in front of users often to maximize learning and to create focus during the work period.

Team size is another important factor and the standard practice is somewhere around five to nine for best results with this plumbing. If you have a large group you’re going to refactor into agile teams, I’d stay in that range. If you’re working as a team of one, I’d actually still use most of the practices here. If you go much larger, I think you’ll find it unwieldy and get better results by splitting and re-chartering the team into smaller groups.

“The key to making this work is discarding the ridiculous idea that there is one standard practice of agile that works for everyone and you just need to do it right.”

If you’re wondering who’s in charge, this is the wild part: in theory, no one. There is usually an agile coach to help the team with their practice (or scrum master in the methodology Scrum), but the more you have to lean on someone for command and control, the less your practice of agile is functioning. In reality, many teams have some kind of lead or someone they can rely on for this, but it’s important to take note of the idea that the less that person is having to go around telling people what to do, the better. The goal is self-organization.

Finally, these teams are generally dedicated and colocated, which can be a challenge for managers trying to get started with non-dedicated or remote contributors. The main reason for designing around dedicated colocated team members is that the overhead generated by project switching is high and you lose some of the team cohesion benefits agile offers. What should you do if not everyone is dedicated or on site? Agile is still probably better than the alternatives. My advice is to try for fixed times in which they work on your project (like afternoons or Mon. & Tues.) and then just be very conscientious about the issue and test tweaks to your process and tools to make it work over time.

C) DEMO

This is a session at the end of an iteration where the team, and sometimes outside stakeholders, takes a look at the working software. If there are surprises, soul searching, crying, or other dramatics during this session, that’s a bad sign.

The idea with agile is that frequent informal collaboration within the team should lead to working software that doesn’t surprise anyone and that this demo is just a chance to enhance shared understanding about what the team built, how, why, and what kind of outcomes they’ll be looking for on the part of the user to evaluate what worked and decide what’s next.

D) RETRO

Here, crying is potentially OK. This is where the team discusses how the iteration went and decides what practices they want to keep, discard, change, or add. You’ll find a list of questions to guide your discussions—the three you see in the diagram below are a good place to start. The output is an update (if there is one) to the team’s charter (or some shared doc) about their practice of agile.

The key thing is to avoid the blame game while still getting at the fundamental, underlying reasons things happen. For example, if a feature broke really bad, really early during testing and was hard to fix, why did that happen? If the answer is because it wasn’t tested during development, then you would ask why that was. Was the necessary test infrastructure not available? Does the team lack a shared view on when/how/where to test things? Was the scope or intent of the feature not well articulated? And you’d keep going! The ‘5 Why’s’ is a popular practice where you ask+answer the why question five times.

Most people (and by that I mean just about everyone) are trying to do a good job. The team just may not have a shared understanding about what that means—in fact, you can pretty much guarantee no two people ever understand each other perfectly. You’re just trying to improve on that shared understanding across the team in this meeting. The purpose of this session is to both drive to that shared understanding and decide how to achieve better outcomes by tuning the team’s practice of agile.

By the way, the key to making this work is discarding the ridiculous idea that there is one standard practice of agile that works for everyone and you just need to do it right.

2. User Stories

User stories are micro narratives about something you’ve learned the user wants to do. They have three clauses:

  • As a [personas],
  • I want to [do something]
  • so that [I can achieve a goal/reward].

For the practice of agile, stories are important in that they help the team break their work down into discrete pieces that focus on outcomes for the user and encourage discussion. Discussion is the goal—stories are not a different way of writing ‘requirements’. They are the centerpiece for discussion in a fundamentally different way of working where the team does what it thinks makes sense vs. operates against a fixed specification of requirements.

An epic story describes a relatively more general interaction, like finding an automobile part. Let’s say we have a team working inside a company that does HVAC (heating, ventilation, air conditioning) repairs and they’re building something so the field technicians can find out about availability and pricing for replacement parts. An epic story might be something like:

‘As Ted the HVAC technician, I want to identify a part that needs replacing so I can decide my next steps.’

Stories, or ‘child stories’, and test cases within that epic might describe smaller, more specific interactions within the epic, like searching part number, or type, or uploading a photo for identification. The child stories have the same format as the user story and the test cases are just basically little ‘notes to self’. Here are some example child stories and test cases that detail the epic above:

‘I know the part number and I want to find it on the system so I can figure out next steps on the repair.’Make sure it’s possible to search by part number.

Make sure descriptive info. appears as the search narrows (photo?) to help avoid error.

‘I don’t know the part number and I want to try to identify it online so I can figure out next steps on the repair.’Make sure it’s possible to search by make/model of units

Make sure it’s possible to search by type

‘I don’t know the part number and I can’t determine it and I want help so I can can figure out next steps on the repair.’Make sure an estimate of the turnaround time for an expert to review is available
‘I want to see the cost of the part and time to receive it so I decide on next steps and get agreement from the customer.’Make sure it’s possible to dispatch a request by email to the customer in case they order their own parts and/or carry their own inventory of spares.

NOTE: How would the customer respond so we can help structure the next steps as we would otherwise?

Make sure it’s possible to indicate priority

Make sure cost associated with priority delivery are available

Good stories are based on validated learning about what matters to the user and have a testable reward. Storyboarding them is also a great way to help the team think through them. I could go on all day about user stories, but if you’re interested in more I’ll refer you to my online tutorial: Your Best Agile User Story.

While stories are highly capable of being detail-oriented about user experience, they don’t (or shouldn’t) prescribe the implementation, leaving individual developers free to operate against their evolving perspective of what makes sense vs. follow an arbitrary plan.

User stories are also a critical junction between product design and the practice of agile. That’s important because the high-functioning practice of agile deals not only with getting software out the door, but also making sure it’s actually valuable to users. If you’ve been in the business any length of time, you probably know that the odds of a given feature being a big hit and heavily utilized are low—very low in some places.

The Venture Design process you see to the right is one approach to increasing a team’s success rate with new development. The idea is to make sure user stories are building on a foundational understanding of the user, what actually matters to them, and validated learning about whether or not a given proposition is valuable enough for them to engage with the software.

3. The Daily Standup

Meetings—most of us hate them, but we also can’t seem to help ourselves. The daily standup is agile’s solution. Around the start of the day, each team member answers these three questions:

  • What did I accomplish yesterday?
  • What will I accomplish today?
  • What obstacles (if any) are impeding my progress?

While some teams allow outside stakeholders to attend, the general rule is that they can’t ask questions. If individual team members have questions (or suggestions) for each other, they agree to catch up individually after the meeting. The idea is that with support from the agile coach and/or team lead, this is enough of a meeting to deliver on a shared understanding of what’s in progress within the team.

See why IT Teams

Love ProjectManager.com

Track all your projects – Free for 30 Days

START A FREE TRIAL