search
top

People Over Process

Processes Do Not Communicate with Each Other, People Do

The reality  is that it can take a lot of “Doing Agile” before you, your project, your business, your team, your team members, are “Being Agile.” Trust me, there is a big difference and the “people part” can be the biggest obstacle. Malcolm Gladwell says it takes 10,000 hours to master something and if you do the math, you have to work 40 hours 52 weeks a year for 5 years to pass the 10,000 mark but the reality is that people have work to do and practicing agile skills is not going to be something most do actively so it is going to take time!

When you start “Doing Agile” it can be overwhelming. You are learning at the most basic level – writing good user stories, what is acceptance criteria, how to define “done”, to how to run a planning meeting, estimating work,  even how to run a sprint review without it taking half the day and things are changing things quickly as you learn from each iteration. It is SO easy to get bogged down and frustrated because it takes time to figure it out the simple mechanics of it all, forget the additional need to figure out how individuals fit in this new world. Training is just the start and there is no specific calendar of success for when the true transition from “doing Agile” to “being Agile” happens or how long it will take for the people on the team to do the same. This awareness can help you, no matter what role you hold (Scrum Master to CEO to team member), ensure you see the connection between your agile growth and each individual who is part of it.

Agile adoption is a transition for the business, the team, the project, the process and the people and it is going to take time. Some look at this and think it will solve EVERYTHING. It is the magic bullet that will just make it all better. NOT!

You cannot treat this like installing a piece of software on your computer, press a button, wait a little and it just works. You need to give yourself time to learn not just how this stuff works but why it works. Most often priority defaults to, and focuses, on the JUST process – how does it work, how do we make it better, how do we do it faster. With the people who will actually be doing the work, an afterthought.

The core purpose of agile  is about returning active communication to the process. Processes do not communicate with each other, people do.

The challenge of your transition is to engage your people as you create, define and refine the process your teams will use; it allows each person to become a contributor, an investor, and an owner not only in how the process works and improving it over time but making sure they can and will use it. It is their process, their “how,” so let them help create it!

I was blessed and cursed with learning agile when my entire game studio “went agile” together – training, learning, failing – together. Almost 4 years of working together growing from 20 to almost 100 members, hiring, lay-offs, firings, construction, priority shifts, different options, work styles, communication issues… I saw it all, the good, the bad, and more than ugly… yet when I look back I forget most of the challenges and focus on the lessons: what broke, why and how did we solve it. Most of the times, “how did we solve it” was simple – we got the right people to have a conversation.

A good metaphor for the early days of an agile transformation is to consider yourself on training wheels even if you have an agile expert working with you. As with most people who learned to ride a bike, there is no schedule of how long you will need those training wheels, even when Mom or Dad are helping you, you have to master the skills yourself. You are on your own time and even after you take the training wheels off, you may take a long time before you reach a level of confidence when you ride your bike alone, you feel “wobbly” and unsure. For a while you might be more comfortable riding in your drive way or neighborhood, away from the distractions and dangers of a busy roadway nearby but eventually, you want to try out a more challenging environment. When you finally say “I got this” it is all about you feeling your skills are ready, developed enough to take it on. Even if you are being pushed to move to that more challenging environment, as you do it, you will be reserved and cautious, tentative about using your skills. It is the same with agile, whether you are doing Scrum, Kanban, Lean, XP, it does not matter. Agile skill and confidence is a matter of use and practice using the skills and the though process, not days on a calendar. Each person on the team will have different levels of reserve and caution based on their own personal readiness. Keeping that in mind helps agile mentors and leaders ease concerns and minimize resistances when necessary for each person.

So, how do you ensure that the people do not get lost in the transition to agile?

A great example of how easy it is and how often people get disconnected from the process is to look at the Retrospective, a meeting that is supposed to be all about the team members looking back at what happened to the team during the iteration and figuring out how they want to move forward based on what happened. A lot of teams do not have this meeting at all or if they do, they do not allow it to be the meeting it is meant to be.  I read so many discussion group posts asking “How do I run an effective retrospective?”, measuring progress, tools to use, so much focus on the process of the retrospective. It saddens me that so many of them forget that the retrospective is first about a conversation, a place where voices can be heard, opinions expressed, participation encouraged. Rarely do I see questions about how to get people to contribute, how to encourage trust and honesty when you are in stressful discussions, or how to get person who speaks well at stand-up to say a word during the retrospective.

As a scrum master, I ran retrospectives for a team transitioning to agile and as they became a high performing team that had been working together for years and I have to say in 50+ iterations together, not one retrospective was the same as the last. Why? Because I used the emotional temperature of the individuals (which was usually based on how good, bad or ugly the iteration went) to help me determine what type of retrospective the team needed for that iteration. When we had a great sprint, retrospectives were so constructive, feedback was easy, agreeing on issues, proprieties, and next steps and  was easy. When the sprint went bad, whether it was the work blowing up, bad planning, an individual on the team not meeting commitments or even someone or something from outside the team causing issues, that heightened emotional temperature meant it would be a challenge to get to something constructive until “war stories” were shared and the team had a chance to move past the emotion attached to the experience. The amazing thing about a challenging sprint retrospective is that it can provide both an outlet for frustration in a safe environment as well as a bonding opportunity, reminding each person they went through “that hell” together and they were not alone in it. There were times that my only goal in a sprint retrospective after a sprint went VERY WRONG was to ensure that the team members came back to work on Monday!

During my project I moved from product owner/scrum master team focused roles into a project focused/leadership role and since I had not worked with all of the different teams I wanted to learn more about what was happening and how folks were feeling. I did not want to make changes without understanding what was going on. I went to all of the scrum masters and asked them to ask their teams if they would let me sit in on a retrospective or two. Some might wonder why I asked, I was technically the “boss” so I should be able to whatever I needed to do. Well for me, this was the first step to building trust as a leader but I also wanted them to know that I respected this as their meeting and having an unwelcome outsider (so to speak) there would change the dynamic of these meeting. I did get invited to attend but when I did, I sat on the floor, in a corner, away from the table where the team sat. I was there to listen only and the best way I could do that was to not sit at the table. I rarely said anything during these meetings unless asked and did not give feedback about how what I saw at the meeting – it was their meeting. During Scrum of Scrums meetings though, I talked to the scrum masters about what I observed and in most cases, the scrum master was doing all of the talking! Very few team members had anything to say and most folks were messing around on phones or doodling… so much for inspect and adapt. And finally, if there were issues, potential action items, while it was written down, there was never any follow-up so nothing changed! Just watching their body language you could tell it was not their meeting and they felt they did not matter to the outcome.

I requested two changes from the scrum masters solely aimed at restoring a voice to each team member to remind them they did have a say:

  1. Scrum Master Speaks Last. I requested the scrum master became the last person to “have a say” as a member of the team during the meeting. They could kick-off the meeting by encouraging the individuals to start, but hold their opinions and issues to the end, if they already heard a summary of the issues it prevents team members from fully expressing their feelings, perspective and opinions. “Yeah that” does not provide a lot of insight to help improve the process. Take notes, be a good facilitator by encouraging the conversation, but also use the time to do a personal status check of the iteration and the state of the team’s feelings about it. Were there things that you were not aware of? Were there things you could have helped mitigate and did not? How did you miss it? As a scrum master it can be hard to get the team to give you feedback on how well you are doing and what you can do better. In time, as team trust increases, they will start being more honest… oh boy will they! 🙂 When the team members are done, add your insights and perspective using it as a chance to fully understand what happened, what could have been done, and how they want to change it so it does not happen again!
  2. Create a Team Action Plan. Before the meeting closes, make sure to write down the issues that came up and agree on how the team wants to move forward. Rank the issues that came up but have the team decide what is the most important thing they want to fix by the next iteration so they set priorities for their own improvement. Ask who is the best person on the team, or outside the team, to help fix the problem, and figure out who on the team is best person to drive the issue. It is not always the scrum master! Having an action plan puts the solution and the ownership of the solution on the team. It can change their attitude when they feel they can make a difference in their own success and it a very powerful thing to remind them of after an iteration that went south. And make to revisit this list at the next retrospective so that they know they are having a direct impact on changing things.

Within a few short weeks of implementing just these two changes, I started hearing people saying things about “feeling like I have a voice again,” “being part of the solution,” and even the atmosphere was described as “feeling better.” One of my product owners actually commented that people were more engaged in other meetings too. There was a lot more talking going on! It did not take a lot to move the needle. Retrospectives can be such a powerful opportunity to start cementing the bonds of trust and improving the project environment at the same time!

Remember that while there is a lot of stuff to do – stand-ups, planning, user stories, estimating, retrospectives – each and everyone is about improving communication between individuals who use them to get things done. Respect the individuals as users of the process and refine the process to fit the needs of the individuals and teams  not the other way around. Think of how you would write a process user story for your team members – remember who the user is for the process you are defining or refining and ask them what they need and want!

Be agile in your project AND your process. To do that well, you need to engage your team members to help create processes that they not only will use but that they believe in because they helped create and refine them.

Updated: May 23, 2013

Leave a Reply

top
%d bloggers like this: