Tag archive

team

Presentation – Doc is a Four Letter Word

in Agile/Resources by
Documentation Formula

So it’s no secret, I like to talk — and here’s a fun one I’ll do with different groups. This is a session that I have had the honor to do in a number of settings that presents ideas and techniques teams can us to help overcome the quagmire of documentation. Hopefully help folks rationalize what documents are required and those that are not. Look over the slides and let me know if you would like me to come talk to your group. I can be reached at matt@agilebacon.com.
 

Put It On The Team

in Agile/Agile Engineering/Project Management/Teams by

Do you want to have more effective daily stand-ups? Do you want to have the planning meetings flow better and increase the value of these meetings? Do you want to see continuous improvement flow from your retrospectives?

If your answer is yes, then put it on the Team.

I’ve written about trust, relying on strengths, and improving self-organization many times — and the message of these can all be summed up as putting it on the Team. Make the team responsible for solving problems, make the team responsible for defining how to deliver, and making the team accountable for delivery. Most of the times when we talk about the concept of the Team self-organizing, is it more focused on the “how” part of delivery, and not the process. However, remember that the meetings (or ceremonies as some call them) are primarily for the team. Specifically, the Iteration Planning, Daily Standup (or Daily Scrum), and the Retrospective meetings — these are for the team, not the stakeholders or managers. Do the stakeholders and managers gain value from these meetings — Yes, but the real value is the fact that the Team takes ownership of what they are going to deliver, they take ownership on holding each other accountable to deliver and working through problems themselves, and they take the on responsibility the responsibility of improvement.

A lot of times we (as in Managers, Scrum Masters, Team Leads, Type-A Team Members) want to install processes and templates around these meetings. This usually happens after a few weeks or several months of trying an agile framework and either not following the guidelines of the framework or the team not taking the initiative to make improvements. We’re not getting any value and the team is resisting and or blaming the whole concept — we want to fall back to more structure and being told what to do.

A great example of this is when a team’s stand ups start becoming mundane, over-run their time boxes, and team members don’t show up. So what happens is we come up with a template for the team to keep up with for daily stand ups as well as establish a set of metrics we answer to during the stand-up. And of course, this just becomes one more thing for a team member to keep track of as well as an unintentional mechanism of command-and-control.

As an ex-Director/Manager, I often wanted to step in and help — and I usually would come up with a template and or some hard-prescribed structure and tell the team to follow it. I wanted to help and that’s what managers genuinely want to do, but I was quickly put in my place when one of my team members said, “let us figure it out, it’s our problem.” I gave guidance and advice, but otherwise I got out of the way. I let the Team come up with how they were going to make their meetings more effective. And at the end of the day, they simply looked at the frameworks themselves and decided to more closely follow the existing framework guidelines — e.g. keep stand-ups at 15 minutes and stick to the script, then allow the time remaining to become open space troubleshooting time.

TeamworkAt the end of the day, remember that more process does not equal more better. Rely on the Team to solve problems, over instituting process and templates to solve problems. I think I’ve heard this before somewhere …

How can Scrum Masters help their teams to Self-Organize?

in Agile Engineering/Teams by

Working togetherSometimes, teams need a little nudge to help to self-organize. Remember self-organize means the team takes ownership of not only how to produce the desired end results, but they are active participants in understanding the product/project and they work together to ensure they are operating as a team. It is not too uncommon for teams to sit back and wait to be told to self-organize. I usually see this with newly formed teams or teams that have historically worked under command and control environments.

A colleague of mine argues that most people operate this way — they want to be told what to do. Part of me agrees with this concept, I see this during training sessions all the time. But I don’t think this lack of self-starting self-organization stems from people not knowing how and needing to be told. Instead, I think it’s people waiting to be given permission. This behavior comes through loudly in training sessions with folks new to Agile. I’ll often use various interactive facilitative techniques during training and it usually takes at least one person to help get the interaction going. Some of the tricks and advice I’ve used and received not only works during training workshops, but I think the same things can be applied by Scrum Masters (as well as those folks in leadership positions) to help kick-start or trigger a team to self-organize. Here they are:

Practice the Pregnant Pause. The idea is that if you want to trigger conversation, create silence. Here’s how it works, state the problem or objective, or simply a broad statement that you want to trigger conversation about. Now, here’s where the fun begins – count to nine. Let the silence begin. In fact, if you have to count to 99 — I guarantee that someone will break the silence. A good friend of mine called it doing a Michael Cain, say something and throw a long pause in there and just let the team fill in. If they don’t, then maybe the meeting or discussion is over.

post it on white boardStorming. I’m not referring to Tuckman, instead I’m talking about brainstorming. There are some great techniques that you can leverage out there that will get team members involved, even those people that are normally quiet. All you need is a whiteboard, maybe some easel paper, post-it notes, and some markers. It is a amazing to see what starts happening when someone throws out a question or a problem statement, and then watching a team start brainstorming ideas.

Get Out. Yes that’s right, sometimes it’s best to just throw out an idea and instruct the team to come up with the solution, and then walk out of the room. I’ve done this myself, and I’ve never been let down — even with brand new teams.

Become a Facilitator Master. Above I mentioned brainstorming, to do it well you’ll need to practice and learn some techniques. There are many good books that can help, [amazon_link id=”0596804172″ target=”_blank” ]Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers[/amazon_link] by David Grey, Sunni Brown, and James Macanufo, [amazon_link id=”1591843197″ target=”_blank” ]Unfolding the Napkin: The Hands-On Method for Solving Complex Problems with Simple Pictures[/amazon_link] by Dan Roam, and [amazon_link id=”0470601787″ target=”_blank” ]Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity[/amazon_link] by David Sibbet. Taking a few hours to read the books and a couple hours practicing some of the facilitating techniques will carry you a long way and help the team out greatly.

Have Some Fun. It sounds easy, but it’s been shown time and time again that the team’s productivity is often related to their attitude and the general feeling around the project. When the team starts getting too busy or too tense — this is the time when the Scrum Master should step in, assist, slow-down, or just feed the team with encouragement and substance.

Go to Top