Tag Archives: agile

It’s People

Posted on by
Reply

Back in 2021 I took a Lean Six Sigma Green Belt certification class. It’s been five years since I took that class, and I haven’t completed my Green Belt project to become an official Green Belt, but that wasn’t really my goal at the time (and, frankly, it’s still not a priority of mine, even though I still want to get my official Green Belt at some point). I took the class in the spirit of the 7 Habits of Highly Effective People, specifically “Seek first to understand, then be understood.” A few years earlier we had hired a new CFO at our organization who came from GE and had extensive experience with Lean Six Sigma. Our Senior Leaders, who I was working with on a regular basis, were being taught about DMAIC and how it could apply at our company, and as I was one of the key figures in determining how we executed on strategic initiatives I figured it was important for me to understand what was being taught to the folks I was working with.

I learned a lot when I took that class. I learned that Lean Six Sigma was predominantly used in manufacturing, specifically in finding ways to eliminate waste and reduce defects. I learned that Lean Six Sigma was not a Project Management framework, even though when someone attempts to improve a process using DMAIC it is referred to as a project. As someone who absolutely loves data, I was enamored by how much Lean Six Sigma practitioners rely on data analysis to achieve their goals. I learned that Lean Six Sigma was not anti-Agile, and that if done properly the two methodologies could easily work together and produce some spectacular results.

The most valuable lesson I learned, however, is about what I perceive to be a misperception around Lean Six Sigma. I heard, and was myself convinced, that it was a soulless way of looking at human labor. That it was very Taylorist in that it treated people as cogs in a machine, and that if they just did exactly what they were supposed to do and followed the right process everything would be perfect.

What I learned instead was that, in the Lean Six Sigma world, “People are never the problem. Your process is.”

What this meant, according to my instructor, was that if people were not following a process, it was because they were incentivized not to do so. That circumventing all or part of a process served their needs better than following that process. That, in most cases, people want to do a good job and do not avoid a process because they are bad actors. They do so because not following the process makes their lives easier in some way.

In other words, having good processes is incredibly important, but if you didn’t focus your efforts on serving the people who are meant to execute them, they were bound to fail.

Sounds kind of familiar from an Agile perspective, doesn’t it? Individuals and Interactions over processes and tools anyone?

I saw this play out during a senior leader meeting a few years ago. We were reviewing our homegrown enterprise work management process, and we were looking for input on how to improve it. We had printed out flowcharts that detailed all the steps required to get an initiative through the complete lifecycle at our organization. Our new VP of Application Development (so new that he had not “officially” started and had flown down just to take part in this summit), held up the piece of paper and folded it in half so that the start and end points were touching. “If I can do this,” he said, “and get my projects done without going through all of these steps…why wouldn’t I?”

He was right. It was possible to get projects done without going through all those steps, and in many cases a leader did so they were able to get things done faster than by going through them. I won’t go into the reasons why he was right in this post for a variety of reasons, but he very much was.

People are complex. I often catch myself saying that people are messy, but that’s putting a negative spin on the outlook and I try not to do that. Human beings are unpredictable, because we’re all unique. As individuals our actions and beliefs are shaped by innumerable experiences we have had throughout our lives, up until the very moment we are in at any given time. One person might be having a bad day because they spilled their morning cup of coffee, while another person might be having a great day because they thought about someone who did something nice for them twenty years ago. We’re a beautiful and chaotic mix that has been thrown into a blender and turned on to puree to make us what we are today.

No process in the world is ever going to account for that.

That does not, however, mean we shouldn’t try to optimize our processes. Quite the opposite! Part of the spirit of continual improvement is that we should constantly be looking at the ways we work and exploring ways to make them better! Lean Six Sigma is an amazing, data-driven tool that can help you do that. In fact, I would go so far as to say that it’s entirely possible to turn the outcome of an Agile Retrospective into a Lean Six Sigma DMAIC project.

Just don’t forget the people along the way.

Team Building Activity – Look into the future!

Posted on by
Reply

This past Wednesday I had the opportunity to facilitate a workshop with all the senior leaders in our organization to start working on our Annual Objective for 2024. As part of that workshop, I put together a team building activity to bookend the workshop. I got a lot of positive feedback from the attendees, so I thought I’d share what we did here, along with my lessons learned, so that others could use it if they were interested.

Activity: Looking into the future
Time Required: 10-15 minutes
Materials Needed: A decent sized ball. I used this kick ball.

  • Get your participants to stand in a circle, ideally arms-length apart.
  • Stand in the center of the circle and introduce the activity while holding the ball. Here’s a paraphrase of what I said to my team – “Today, we’re going to predict the future. Now, as many of you know, I’m an actor. The last show I was in was about a medium who used a crystal ball to speak with dead Hollywood celebrities. I learned something very valuable when I was doing that show – Genuine crystal balls are heavy, fragile, and expensive. The crystal ball we were using was the most expensive part of the show. Even more expensive than my salary! Because I want to be responsible with our members money, and because I don’t feel like cleaning up a bunch of broken glass, I’m going to ask you all to use your imagination and pretend that this fine kick ball is, in fact, a very fancy crystal ball and that when you are holding it you can see into the future.”
  • Introduce the rules of the game. These are the rules that I shared with the group on Wednesday (you can partially see them on the slides behind me in the picture above).
    • Only the person holding the ball can speak.
    • Players who are not holding the ball may communicate with eye contact, gestures, etc…but no words.
    • Prediction must be accompanied by the current count of predictions
    • If a prediction is a repeat of a previous prediction the team must start over
    • Predictions may, however, BUILD on previous predictions. Example – “1! There will be a rain of trout that hits New York City!” “2! The ambassador from Chile will suffer a serious injury after being hit on the head by a falling trout.“
    • If the ball hits the ground for any reason the predictions must start over.
    • If a new round of predictions begin, predictions from a previous round may be repeated
    • You cannot throw the ball back to the person who threw it to you.
  • Explain that the goal is to see how many predictions the team can hit in the time allotted. You should challenge the team with two goals – One of them that you think should be achievable, and one that should be hard. In our case, we used 25 and 50. Put some kind of bet in place to make it interesting. I initially had the idea to be the “bad guy” and assert that the team would never hit the goal and my partner (Adam Ulery from Compass Productivity) would be the “good guy” and bet that they would. I volunteered to agree to conduct the rest of the meeting using my puppet, Mr. Judgey, if I lost. We were discussing our bet with the CEO before our workshop, and he got into the game in a big way. He offered that if the team hit 25 predictions we’d donate $2500 to the local chapter of Celebrate Birthdays (the charity the team was sponsoring for the day), and that if we got to 50 we’d donate $5000. I threw in me using the puppet for the rest of the meeting as a bonus to tier on the 50 predictions.
  • Toss the ball to one of the participants and get the game started!
  • Play referee and make sure they follow the rules.
  • If you can, record the session.

The point: I based this activity on an exercise we have used as an ensemble warm up in a few of the productions I’ve done in the past. In that activity, the goal was to keep the ball in the air and count out every time you hit it, and the point was to get everyone in the ensemble thinking and working together as a unit before the show begins. It’s also a lot of fun. In this case, I wanted to add on to that by getting them thinking about the future as our workshop was around building an Objective for 2024 that would focus on the Most Important Thing our credit union would accomplish next year.

Retrospective:

  • What went well: The team hit the stretch goal, with a list of 50 predictions that ranged from serious, silly, far-fetched, and realistic and pretty much everything in between. We had some laughs, shook off the after-lunch drop in energy, and got into the right mindset to do some forward-thinking. We raised $5000 for charity and I got to freak everyone out with my eerily accurate Muppet. We gave a spontaneous lesson-in-the-moment about stretch goals in relation to the 25 and 50 targets, getting the team to agree that if we had started with 50 as the goal, or even 75, that they would have been less motivated to try and hit it.
  • What didn’t go well: I didn’t anticipate how quickly the team would devise a strategy to get to the goal without dropping the ball. In the theater world, the ball is constantly moving. In this scenario, the team member got to hold it while they were making their prediction. They quickly realized they could just hand the ball to the person next to them and let it go around the circle. There was also no motivation to make a prediction quickly, so team members holding the ball could pause to think about an answer.
  • What I’d do differently: Add the following rules to the list above –
    • You cannot pass the ball to the person immediately to your left or right.
    • You cannot move from your spot.
    • If you hold the ball for more than 5 seconds the count resets.

Conclusion

After we finished the workshop I closed our time together with the following (again paraphrased, because I don’t work from cue cards my friends):

I spent a good deal of time working in and around Renaissance Festivals when I was younger. Yeah, probably not much of a surprise given the fact that I’m wearing a kilt. When I was doing so, I got to know quite a few fortune tellers – Tarot card readers, psychics. You name it. I’m sorry if I’m ruining the illusion for you, but none of these people possessed any kind of supernatural powers. What they had, was the ability to look at the world as it is, look at trends, ask probing questions of their patrons, and make a relatively accurate prediction about what their future looked like. We did that together today. We may be right, we may be wrong, but we used our collective knowledge together to gaze into the future and make some predictions. I’m excited to see how they turn out.

Bonus: Adam recorded the session for me, and I’m going to keep track of their 50 predictions for 2024 to see how many come true!

Update: I can’t believe I left out one of the most impactful parts of this! As I was finishing my summary, I asked everyone to pass the kick ball around the room one last time and sign it as we moved on to our next activity. This, I told them, was our contract that we were committing to building a future together as one big team. I gave the ball to our CEO as a memento of the event and a reminder for everyone of what we did together.

Some thoughts on “Comprehensive Documentation”

Posted on by
Reply

There is no value in documentation.

Why Would You Say Something So Controversial Yet So Brave? is a quote from The Eric Andre Show rendered in an image macro and used as a reaction image on Tumblr humorously in response to relatively banal statements.

I am sure that if you know me personally, or if you are at least tangentially aware of what I do and how I view the world, you are rolling your eyes right now and writing off my statement as being naive. My ask is that you go along with my thought process for a minute to understand what I am really saying.

One of the four values in the Agile Manifesto is “Working Software over Comprehensive Documentation.” Many people inherently interpret this as meaning that those of us who resonate with the manifesto believe that we should never document. This is patently untrue. In fact, if you look at the statement under the four values it explicitly says that “while there is value in the items on the right, we value the items on the left more.” Agile enthusiasts do not advocate for the abolition of documentation.

What we want is documentation that is valuable, and for documentation to be valuable it must be useful. The people it was written for must be able to find it. They must be able to understand it.  The documents must be relevant to the current environment.

Having a document repository that nobody uses is wasteful. Putting effort into populating such a repository is wasteful. Using physical and/or virtual space to store documentation that is never referenced is wasteful.

One of the reasons why I am so critical of “traditional” project management practices is because of the amount of documentation that is considered a requirement for projects to be completed, and the main reason I feel that way is because I see most of them being designed as cover for the Project Manager. Often, I see situations in which a Project Manager has all the responsibility for ensuring project success but none of the authority to make it happen, so they make sure that they document everything that they do to be able to say they have done their job when a project fails or is delayed. I cannot tell you the number of times I have seen this happen personally. I have, in fact, watched a Project Manager bring up said documentation and force people to look at it to prove exactly this.[i]

I do not claim to have the right answer for what is the proper amount of documentation in any given situation. Like most things in the Agile world, it really depends. As a developer, I was a huge fan of self-documenting code (using variables with long, descriptive names to describe what the code was supposed to do), so I did not spend a lot of time adding comments to my code. I also contend that if your organization does not have individuals dedicated to the creation and curation of knowledge most of your documentation efforts are going to end up being wasted (largely because doing so is a full-time job). If your end users search for a document on your intranet and cannot find it, it might as well not exist.

Even more controversial is the notion that your systems/processes/products should be designed in a way that does not require documentation in the first place. Documenting complexity does not generate value for your users but eliminating that complexity does.

Creating documentation is a process, and like any process you should constantly evaluate it to determine whether it is generating value. If it is? Think of ways to make it more valuable! Maybe teach others how to do what you are doing or find ways to make your documentation more accessible to your end users.[ii] But if, as if often the case, your documents are essentially locked in a disused lavatory behind a sign that says “Beware the Leopard” your time could be better invested.

[i] In the specific example I am thinking of, the PM in question asserted that it was not their fault if the people in the meeting were unaware of a situation because the PM had followed the communication plan. My contention is that if you followed the communication plan and your message still did not get across the fault is in your communication plan, not the people.

[ii] If, for example, a user says they searched for your document on your company intranet and could not find it ask them to show you what they did and give that feedback to the people who manage the intranet.

They Moved My Cheese

Posted on by
1

Kanban board

Sharpies are important

When I decided to start this blog, my plan was to chronicle my experience as a member of middle management and my possible path further up the corporate ladder. I should have remembered that old saying about best-laid plans and what not, because a week after I created this blog and put up my first post my proverbial cheese got moved.

A lot.

Nothing bad, mind you. I didn’t lose my job or anything dramatic like that. I was asked to take on the role of Scrum Master/Agile Coach at my organization.

Continue reading →