By: Sharon Peterson Misgen
This month, DevJam Agile Coach Sharon Peterson Misgen provides a lucid and candid account of a day-in-the-life of an agile coach. From the initial meeting with the team (in this specific case – a team underwhelmed by previous attempts at agile), through the various implementation phases with their different ceremonies, processes, deliverables and challenges, all to way to a successful delivery of value to delighted end-users. Sharon touches on some ‘real world’ challenges facing agile teams and how to successfully navigate the different personalities, roles, agendas, priorities and internal dynamics to form a cohesive team that delivers business value. Read Part 1.
It was my first day with the team.
Why do I coach agile? Being an agile coach is one of the most rewarding and frustrating roles I have ever done. There should be a Hippocratic Oath as an agile coach: “First do no harm.” By the time I work with many teams, most team members have been through many flavors of agile–some good, some maybe not so beneficial. Most modern software teams are “doing scrum” or “doing agile”, but often they feel, or have been told, they are “not doing agile right.” Agile and scrum are fairly simple to understand, but they are not easy to do well or do consistently. Frequently, agile and scrum feel like they are in direct competition with the traditional SDLC roles of project manager and business analyst. This sometimes leads to teams finding they are doing many or all of the process practices from all of the SDLC worlds, leading to something like WaterScrumFall or WaterFragile. I try to take it back to the place where we do the things that add value and have an impact and stop doing the things that no longer add value. Maybe we need to find some new things to measure to fill in for the old standard measurements. Maybe it is time to think about a few things differently. Let’s at least have the conversation about that.
I start our new team’s session by introducing myself, telling a little about my development background and trying to establish rapport with the team members. Humor counts. We talk through some logistics for this session. I tell the team that as coach, my job is to push them out of their comfort zone and ask them to do things they don’t normally do. We do our best learning when we are a little bit uncomfortable; when we try something we haven’t done before; when we try something that we may not do perfectly the first time. It has to be okay to try things that don’t work the first time, or the second. I promise I won’t ask anyone to do anything they can’t do, but I will push them out of their comfort zone. I ask the team, are you okay with being uncomfortable? Do I have your permission to push you a little bit? I get some smiles, some shuffling feet, and a few nods. Good.
The new team was huge, there were not enough chairs or desk space. The HVAC was challenged with the number of bodies in the room, so the room fluctuated between stuffy high humidity and the arctic. Between the odd shape of the room and the limited whiteboard space, we had to be creative.
The team runs the gamut from intern to mid-career developers to senior developers with 24 and 30 years of experience at this company. We have three product owners, a couple of development managers, a scrum master, and a couple of architects. We kick off with the team’s expectations for this session, what do you want to learn? To experience? To accomplish? The challenge is to keep things rolling, not too much fire hose for the interns, not too much tortoise for our seasoned team members. Agile has made the rounds with this team before, and judging by body language, folded arms, and slightly scowling countenances on a couple of faces, it isn’t necessarily welcomed back. One team member, let’s call him Kevin, makes a cynical remark about how this training will eventually end and they can all get back to business as usual. There are a couple of chuckles at that.
We get through the logistics and overview steps. We start outlining this team’s effort. Team members introduce themselves. What are the skills they bring to the table? What skills are needed? What are the team’s strengths? What are their constraints? What are their challenges? What are their goals for this effort and what are the corresponding success measures? How do we know if we have met our goals? What is the market opportunity we are addressing? Who are we building this for, who are our personas?
Our product owners have twelve personas which have been developed and refined, but we only need three or four for this effort. They start to review the personas with the team. The team starts to tune out, some check their phones. I ask the product owners questions about the personas, why should we care about that aspect of this persona? What is this guy’s day really like? What are his pain points? The team joins in with more questions. They ask about adding another persona, not on the list. The product owners play ball, they tell good stories from their own professional experience about why the personas need our tools. They give color to the personas and talk about their struggles and challenges. They are open to adding the persona for the development team. We are at a good stopping point and break for lunch. We haven’t even started the hard work yet, but I am hearing the right conversations between the team and the product owners.
After lunch, we start talking about wireframes which have been built out by the UX architects and product owners. I am worried that the team will take a look at the high fidelity images, pay minimal attention as they are reviewed and then not challenge the design at all. This happens when things look fully baked and final. For this project, it is fine that the wireframes are set, but the team needs to have the conversation. I ask Jenny, one of the product owners, to take point and draw out the UX design by hand, explaining each element as she goes. I emphasize the purpose is to have the development team gain a deep understanding so they have context as they build each story. Kevin is frustrated by this approach, groans stating that this is a waste of time. We will have the high fidelity wireframes in the room after we have the conversation, but we need to have the conversation.
Jenny is game and gets started. Kevin sighs and plays along. I ask a couple of questions and then step back. The conversation goes where it needs to go, the developers ask a lot about “what if” and “what about” and “why does it work this way here and not like the other page” sorts of questions. Do we need to persist this data? What happens when that button is pushed? What level of user is our persona, will this construct help or get in the way? The UX and CSS team members make note of a couple of things which were missing and/or wrong on their wireframe. They have a couple of “oh” moments… maybe the high fidelity wireframe wasn’t quite up to date. We have just tested the design. More team members are learning something about something they thought they already fully understood, more “oh” moments, more lightbulbs coming on… We’re off to a good start!
Stay tuned for Part 2!