Over the past year, I have had many conversations with people that always seem to revolve around two questions (much to my dismay and resulting squinty-eyed look):
- Where are you going with agile at your company?
- What kind of standardization (and/or framework) do you provide for the company?
Before I answer those questions, let's start with a story. When I was first practicing agile in 2006, I was asked to document our scrum process so the team would best understand how it worked for projects that had an end or "release" before we moved onto the next project. We came up with a visual that looked like this:
Looking back on this experience, it made perfect sense for me to standardize the process. We were a small team, and the documentation we produced was what worked for the team at the time we created it. Twelve years later, my perspective has changed, and I view documents like this as ambivalent or chaotic neutral at best. At worst, they are often used as the holy grail to solving team problems. The danger is always in how the information is used.
"Look over here – this team seems to be doing well, we should just copy what they are doing!"
Teams are different because they are made up of different people with different situations. Certain practices can be easily shared across teams, but in my experience, trying to standardize processes doesn't actually work and adds unnecessary overhead on teams. To make matters worse, the introduction of certifications in the industry has over-emphasized the idea that implementation of agile is the only thing that matters, rather than the idea that teams experiment and learn together what works for them. This is the same danger we face with capturing metrics on teams and using them without understanding their intent and purpose.
"This team over here can do 60 story points a sprint, but this team over here is only doing 40. Clearly, there is a problem."
Yes, there is a problem, but it may actually be "jumping to conclusions." Comparing what one team can do vs. another is a shorthand management approach to agile at its worst. It's a symptom of both a lack of understanding of the intent behind self-organization and continuous team improvement and also an indicator that the industry of agile has spent a lot of time focused on the performance of small engineering teams. The hard work of addressing how the rest of the organization gets work done remains largely unfinished.
So, when faced with the question: What kind of standardization (and/or framework) do you provide for the company? My opinion has always been first and foremost based on this statement:
Do not do what works for another team. Do what is right for your team.
And the harder question: Where are you going with agile at your company? My answer is a little squirrely, but it is an honest one. We go nowhere together if we don't stay true to the foundational truth of what agile was asking us to focus on in 2001: building trust and transparency in teams so they can work together to accelerate their learning in a safe and open environment. We go nowhere together if we look to push process onto others without striving first to understand why and what is needed.
One might think after seeing the above picture, "Get that cat off the router before it overheats," without first asking, "Why the cat is sitting there?" I can attack the problem by removing the cat, or instead, I can eliminate the problem by providing the cat with a heated bed in the winter so the arthritis in his back legs doesn't feel quite as bad when it is cold.
3 guide rails for teams
I'm sure you are thinking at this point, "OK, Jen, that's not really solving the reason we asked the question in the first place." Many people I talk with about the subject of agile often feel trapped by the status quo, like this cat. I understand that—I have also felt that way. Sometimes, I still do. In an effort to help with this problem, I ask teams I work with to follow some guide rails, and I advocate others teams embrace these practices as well.
Track and share your work so others in your organization can understand what it is you are doing.
The key here isn't that you are tracking the work (although that's a bonus!), it is that others beyond you can understand why you are doing the work. If you can't communicate the customer value to someone who isn't involved in the details, do you really understand it yourself? Additionally, there is significant value in being able to empirically explain how you are going to measure the impact of the work you are completing. This follows the simple user story format of: As a customer, I need this piece of functionality, so that I can achieve this result. This is followed by: We know we will have delivered this result by these sets of qualitative vs. quantitative measurements.
There is truth in the phrase, "Begin with the end in mind."
Continuously work on improving your practice as an individual and team.
This includes the process in which your team and product get work done and what your job function is. If you are an engineer, learn something new about coding and practice it. If you are a project manager, try out a new facilitation technique you read about. Process doesn't only refer to how you move cards around in a tracking system. Make sure you are openly talking with your team about the things that aren't working—whether it is related to people process or technical process. Without that commitment, process and technology will become stale.
Perhaps the best we can do in this space is agree to standardize on routinely sharing with the whole organization how we are continuously working to improve and the metrics we use to demonstrate that.
Note: If you come to me and sheepishly confess that your team has stopped doing standups because the team doesn't see the value in spending the time, and the entire team is delivering measurable and clear value to your customers when it is needed, don't expect me to be upset. I am likely going to ask some questions, congratulate you, and send you on your way with encouragement to continue having good conversations about what works.
Finally, if your work crosses team, community, or product boundaries, agree how that is going to happen before there is conflict.
I'm not talking about the details behind implementing a technology. I'm talking about defining everyone's roles in the work, defining where conversations will occur, and defining how requirements will pass back and forth from team to team—establishing as much harmony as possible before work starts and you find yourselves relying on each other to share space together—without a catfight erupting. As technology continues to innovate at a rapid pace, teams with heavy cross-functional dependencies will find that the problem will worsen. In my mind, it is the single biggest reason why projects fail. This is where standardization is most needed because, without standardization, it is hard to automate.
Do the right thing
I want to close by re-emphasizing this statement: Do not do what works for another team. Do what is right for your team. Every failed agile adoption story I have heard in my career is built on top of the failure to follow that mantra. I encourage everyone to embrace that idea and seek help from your local agile experts when the team needs it.
Finally, when approached with a "you must do this because so-and-so is and it works for them…" look back on the guide rails I've defined above. Most teams are put into that position because they are perceived to not share why they are doing something, they do not continuously improve their process, nor do they ensure that dependency-riddled work is handled with minimal day-to-day conflict. My call to action for teams that are in that space is to think about why they are in that position, and what they should do to break free of that perception.
Most importantly to my fellow coworkers, technologists, and agilists: If you don't agree with what I am sharing, you can do what my cats do… or you can share what works for your team.
4 Comments