Seems most organizations self-identify as Agile these days, but that doesn’t mean everyone has made the transition, and for those who have, is the journey complete? Likely answer is “no.”
We’ve covered some of this in previous blog posts, and in our Agile white paper, but worth revisiting here:
OK, so where should you start?
1. Build your team.
Agile teams are best when they are 7 +/- 2 people. Tap and train someone to become the ScrumMaster. This is the cornerstone role, so a practiced CSM or freshly-minted CSM is the only path to take. Create the team to address all inputs and tasks the project requires. This typically includes several developers, UI/UX designers, and testers. Yes, testers.
2. Identify a project.
Best candidates are those that have a critical path, are complex in nature and have executive support. Buy-in is key to driving success. Don’t be tempted to find a small, side project to test out your Agile practices. You want visibility and investment to drive change.
3. Create your process.
Standard ceremonies like daily standups, sprint meetings, demos, backlog grooming sessions and retrospectives should be well understood, actively contributed to, and well attended. Technology that supports and mirrors the team’s work helps speed ramp time, and can enforce the right behaviors. Tools like JIRA, Rally, Basecamp or other project management tools are great for distributed teams. Co-located teams (which are optimal) can use these in addition to big visible boards in the shared space. And all teams benefit from a chat client to limit interruptions.
4. Design your space.
Co-located teams prefer open seating, with flexible arrangements to accommodate project work, and the ability to collaborate at the workspace. Can the team see progress charts either on monitors or big task boards? Are there impromptu collaboration areas right where they work? Can distributed teams use video conferencing for meetings?
5. Invite the right people.
Soliciting input from product owners, product managers, sales, marketing, technologists, customers refines the epics, user stories and tasks. That much we may already know. But what is often overlooked, even in more mature Agile teams, is the true acceptance criteria, or definition of done. These need to accompany all user stories and tasks, with features or functionality not released until they are met. With each successive sprint or iteration, the team will get better at defining done.
6. Perform and measure. Repeat.
Baseline velocity helps refine the number of story points a team can accomplish in a sprint. This shouldn’t be construed as a “management tool,” but rather a way for the team itself to know when they’re getting better at delivery. If story points are way off, are the user stories ill-defined, too granular or is the acceptance criteria misaligned with the project? It’s less big brother, and more team guidance.
Each team will find its own cadence, ways of communicating and the best path towards delivery. The basic tenet of Agile encourages people over processes, but sometimes in our zeal for consistency and definition, we veer towards enforcement versus investigation.
A key element in any high-performing team, knowing you’re doing the right thing, that you have the right people, and that you’re working in the right way trumps an assemblage of individual contributors.
Inspect and adapt.
In this journey, there’s no there there. But you can have accelerated release timelines, happier teams, and better products.
Special thanks to Brian Morzos, our resident Agile practitioner, for his input.