© 2011 Don Gray The agile training class for a newly formed team was almost complete. We’d covered values, practices, roles, the product backlog, done simulations teaching the Scrum process and I could see the end of  training. A little team building activity, and we could start tomorrow with building the backlog, story sizing, then start the first sprint.  Forging ahead, the team selected a name, came up with a list of team norms, and they became a team with me as their ScrumMaster. Or did they? Over  the next few

When we flip the safety discussion over, we find trust. When I trust you I provide the safety you need to take risks and speak your truth without fear of ridicule, rejections or retribution. What Does Trust Mean? I like to use the following four beliefs I learned from Esther Derby to define trust in the workplace. I believe you have the ability to do the things you say you’ll do. I believe you will do the things you agree to do  – or let

Most of the time, most of the people don’t put a lot of thought into their behavior. They run an “auto-pilot” program that governs how they respond. If we examine the elements that generate behavior, we get something like this list: Physical sensations – information coming into us from “the real world”. Beliefs and Values – concepts and things important to us Feelings – both physical and self-esteem Data/facts – information I “know” Thoughts – What we do with the data/facts Intuition – Hunches based

©2007, 2009 Don Gray and Jerry Weinberg Engelbert watched Pam nervously chew on her knuckle as she stood in the door of his office, answering his call. “Come in and close the door.” He motioned her to a seat, then stood and pointed an accusing finger down at her. “We need to decide how you’re going to explain what happened with the UDCRM release”, he said. “You’ve managed to upset everyone. Sharkey told the CEO the customers are screaming because we can’t ship on time.

We’ve defined safety to mean we can take risks and our coworkers/management will support us, especially if setbacks occur. We have the ability to speak our truth without fear of ridicule, rejection, or retribution. Throughout the day we will feel differently about the risks we’re willing to take and what we might say. I’ve seen conversations spin on a dime when a senior manager stuck his head in the conference room. How can we measure safety in the workplace? What does it mean to productivity?

When I talk with other coaches about teams, I  hear a lot about “creating safety” and “safe teams”. I don’t hear much about how to do that. While debriefing a coaching simulation the 2010 AYE Conference we listed things coaches did and models coaches might use. Someone said, “Create a safe environment”. I replied, “And how do we do that?” And out came ideas and suggestions on how to do that! I’ve been flipping through my agile books looking for discussions about teams and safety.

Joe Little does a marvelous job recruiting speakers for the Agile-Carolinas meetings. This month was no exception. Israel Gat from BMC Software discussed “Leading the Disruption”. This presentation focused on releases 2.3 and 2.4 of their distributed system management software. Near the presentation’s end Brooks’ Law was mentioned and the question posed, “Does Brooks’ Law still apply?” Adding manpower to a late project makes it later. ”Brooks’ Law” Why is it so? Jerry (Gerald M.) Weinberg chose to use Brook’s Law in Quality Software Management:

The current mantra for software development hinges around “better, faster, cheaper.” To support these efforts, companies attempt to improve their development process. While helpful, improving the current process has two negative side effects: diminishing returns. The more improved a process becomes the less room for improvement exists. Eventually the process will be as good as possible. over adaptation. The development process becomes highly adapted to the existing system leading to problems when the environment shifts. I say if you want to improve your process, improve

One of the smartest things I did as Interim VP of Engineering for Padcom was let Don talk himself into coming to play with us over the course of several hours overlooking the Puget Sound one weekend morning. Padcom was a small tech company with some unique internetworking technology in the process of building-out into the bigger-time. The unique IP was in software but one of the challenges was shipping a next generation ruggedized client as a delivery vehicle to access markets in public safety.

“Whoever has the gold, makes the rules.” Murphy’s Golden Rule