Teams – Page 3 – Agile Bacon

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

in Agile Engineering/Teams by Matt Badgley

Sometimes, 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.

Storming. 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.

How can team members help become an effective, self-organizing team?

in Project Management/Teams by Matt Badgley

In my last post, I took a stab at answering the question “How do we change from individuals in workgroups to effect, self-organizing teams?” Through my discovery and reflection on that topic, I turned my focus towards the environment of the team. Now we know that environment is a big part, but the individuals do have an impact and over the years I’ve found some ideas that really impact how we as individuals can ensure we help the team become an effective, self-organized team.

Respect. It goes without saying that team members need to exhibit respect towards one-another. The idea of respect is often woven into an organization’s core values; however, it takes self-discipline to be sure we are treating each other with respect. It is sometimes said that at the end of an argument and or discussion, it is OK to agree-to-disagree as long as we all respect each other afterwards. Well, I would say — show respect during the time of the argument and or discussion. If you do, you’ll often find a faster resolution and you’ll avoid that “uncomfortable”, “bad taste in mouth” after effect.
Embrace Diversity. It is often not fully appreciated to have a team made up of members from different backgrounds, but in my experience — this is when the best results appear. Diversity can be demographic related or experience related, in all cases it simply comes back to learning. By listening to each other and sharing ideas, we learn from each other and inevitably, produce better and enjoy producing. One other by-product of leveraging cross-functional product teams, is of course diversity. The diversity of skill sets swarming on delivering a story helps do so faster with higher value and higher quality.
Trust. Trust is earned. It is primarily earned by doing what we say were going to do when we said we are going to do it. This is a huge challenge and we need to understand as individuals working in a team that a commitment you make reflects upon the team. Therefore, when we commit to completing work during an iteration and deliver on this commitment, we are establishing trust with the business. During our daily stand ups, when we are actionable about what we finished and what we plan to finish, we establish trust in the team.
Focus on Strengths. Much like embracing diversity, we must focus on the strengths of the team members and put each other in a position to succeed. We all-too-often look to improve our weaknesses either by taking on tasks that will force us to learn. Well there’s a difference between improving our skills and experiences, versus improving our weaknesses. A couple years ago, I wrote about how my team used Strengths Finder to better understand where each team member play’s best. From this point, we would define and divvy up work to get the iteration delivered based on our strengths. This became a very natural approach and team members had each other’s back when someone was playing outside their wheelhouse.
DO. I have often used the phrase – have a “will do attitude.” One of the best way of having teams form and self-organize is simply by doing. Do have the hard discussions. Do spend time with each other beyond work — build teams. Do swarm. Do pair. Do work hard. Do have each other’s back. Do adjust when necessary. Do make a difference. Do encourage each other. Do make decisions. Do what you said your going to do. Do appreciate each other’s opinions. Do lead. Do follow. Do take time to reflect. Do step away when necessary.

These ideas and concepts are definitely not mind blowing, nor are they new. But, as I mentioned, these are the basics that I’ve seen work. What are some of the individual behaviors and or practices have you’ve seen or done that helped ensure your team self-organizes?

How do we change from individuals in workgroups to effective, self-organizing teams?

in Agile Engineering/Teams by Matt Badgley

A colleague of mine at VersionOne, Dan Naden who works to support the Agile community, delivered several open questions from a recent Agilepalooza and asked for help answering. The one that jumped out at me and my experiences was “How do we change from individuals in workgroups to effective, self-organizing teams?”

When I first started looking at this question, I was keying in on the word “individuals” and how individual team members impact our ability to come together and self-organize. The more ideas I got down on paper, the more I came to the conclusion that it is generally not the individual team members that prevent teams from self-organizing and becoming effective. It is usually everything but the individuals that prevent teams from self-organizing. Based on my experience where I’ve lived through an inability to self-organize to efficient self-organization — the individuals are usually never the primary blocker. The things that I’ve seen prevent teams from becoming effective and self-organized are:

Teams Are Too Large. Teams that are too big will not self-organize because the team members are made insignificant because their contributions may or may not impact the overall product delivery. Not too mention that when teams are too large you will usually see the Alpha team members overpower and control the non-Alpha team members. This is why the recommended team size is in the single digits (I’ve seen the range of 5-8) thrown out there. Not only does right-sizing the team make planning more efficient, but it also reduces the discussion circle; thus, making it easier to share information and shorten the time to make and react to decisions that impact the team and the projects.
Workspace Challenges. Studies have shown that the right workspace leads to highly productive teams and in talking with many teams, it’s obvious that the wrong workspace fosters silos as well as the perception of meetings purgatory. Ideally teams are co-located and share a workspace that is conducive to easy chair-spinning conversation. A workspace with plenty of whiteboards, private zones, and an information radiator will ensure a well informed, collaborative team. When this cannot be achieved, the use of rapid and personal communication tools can help teams. IRC chat, video chat, and online collaboration tools are good ways for team members to collaborate.
No Vision. There are multiple layers of vision – company, product, project, and team. Obviously a team can control their vision; however, it’s usually a product of the upstream visions. So if the leadership and stakeholders are not sharing the vision. And more specifically, if the team does not have a shared vision of what they are working towards, then there is nothing to bring the team together to achieve. A clearly communicated and shared provision provides a group of individuals a common goal to achieve — this improves focus on decision making and clear definition on what it means to done.
The 3 C’s. And I’m not talking about Ron Jeffries’ Card, Conversation and Confirmation — I’m referring to a Command-and-Control Culture. It seems that even once a leadership team decides to adopt agile and they genuinely buy into agile values and principles, the individuals on the teams are still reluctant to take ownership of how to win (a.k.a. achieve). Not until the the team is forced to make decisions, do they actually make decisions. Team members that have worked in a culture that is historically command-and-control tend to have either a victim mentality in that they simply don’t believe change is happening, or they simply are scared to put their neck out there in fear of reprisal even when there’s never been a history of this kind of action. The only way that I’ve experienced changing this culture is to have the leadership share the vision and then leave the room (a.k.a. get out of the way). When the team has success, the leadership shouts it from the rooftops and when failure occurs the leadership should ensure learning and accountability ensues — however, doing so from a distance.
Lack of Shared Trust. A core challenge that organizations (the whole organization) have is the inability to trust others to make decisions. This usually stems from two factors: (1) a command-and-control culture that is a result of traditional project/product failures, and or (2) management team members that have been key to the organization over a period of years and have lived the battles — thus, they feel that because of their experiences — they must be a part of the decision. Remember that trust can go both ways, if the teams don’t have that shared vision — then trust of those making decisions is surely lacking.

So, how do we change from individuals in workgroups to effective, self-organizing teams? We give our teams the environment they need to be productive, provide a clear and shared vision, have leadership get out of the way yet be there when needed, and finally we celebrate our small wins and ensure that we learn from our failures (I’ll assume that this stuff sounds familiar; however, if it doesn’t give this a read www.agilemanifesto.org). I’m sure there are more organizational behaviors and I’m certain that individuals impact our ability to self-organize, but I firmly believe that everyone has the ability to work as a self-organized team and if they are empowered to do so — they will do it effectively.

Please let me know what you think. What are some organizational challenges that you’ve experienced that prevented teams of individuals from becoming effective, self-organizing teams? Or, do you think the organization has nothing to do with it and it’s the individual team members?

Come to the Science Fair

in Product Management/Teams by Matt Badgley

Remember that thing we folks that practice Agile call the Agile Manifesto. You know the thing that where 17 smart folks got together and came up with a set of four values and twelve principles to help guide and shape the behaviors of those involved in software development. Everyone might not be able to rattle off the principles, but most of us understand and appreciate the common sense of the four values. At the core of all the Agile Manifesto values is a well maintained relationship between the delivery team and the customer (or Product Owner). And this is where challenges have emerged and often things start falling down. Here’s a common scenario that often plays out:

An organization starts making a shift to use an agile related process, let’s say Scrum. They train the delivery team and the product owner, then kick it off with a team or two. Everyone starts to work and they start seeing productivity gains right away. And the teams are seeing vast improvements in communications and building products that customers like. The organization then says — let’s have a few more teams start drinking from the Agile fountain. Things are going well, but what starts happening is that during this scaling process — people start competing for meeting rooms during the sprint planning and review cycles, and the product owner’s time quickly becomes a constraint. Thus, teams start alternating their sprint schedules to deal with the room/resource issue and the product owner spends less time with all teams and seems to only focus on those teams that work on things that are not doing well or they like.

Now you are asking, what’s the problem? Well, one of the best things that you’ll find when you start working in small incremental delivery cycles is that the teams form a rhythm (or cadence). This helps for predictability that helps the organization in planning and more importantly, helps the team members in planning their lives. Most people like repetitiveness and everyone is habitual (or at least most folks involved in software development), so by having multiple teams on different rhythms — organizations lose the natural state of “steadiness” that comes with shared cadence.

The other big problem with the scenario above is that the face time and feedback with the customer (or product owner) is critical to having success with all four of the agile values. When teams start realizing that time with the product owner is being a challenge, they tend to simply give the product owner a pass on attending any of the iteration planning and or review — and they just ask for his or her time for stories and acceptance criteria. This means that they lose out on the critical feedback that comes out during the reviews and demos.

Does this sound similar? If so, here are some ways to help overcome these common time constraints that appear when you start scaling out agile.

Introduce a Gap. If you are using an iterative approach, introduce a gap between your iterations. The idea is to get everyone on the same iteration schedule and rhythm and by adding the gap, you’ll give time for folks to juggle room schedules and stakeholder time to ensure participation. During the gap, the team will have time to properly plan the upcoming iteration, work on a design/research spike, and or work on an item from the team’s technical wish list backlog. The gap also can afford the team a quick breath and might also be an easy period to squeeze in some personal business time.
Go Short. This may seem to be non-sense; however, if you are using an iterative process then trying working in shorter cycles. Although it takes some adjustment, shorter cycles reduce the time it takes to iteration plan and review. The end result is a tighter focus and that focus is generally on what is needed next. Similarly, move to a lean or continuous flow process (give this a read to learn more).
Lunch-and-Collaborate. Schedule meetings around lunch and, of course, have food. Lunch is generally less formal and can be perfect for brainstorming, story workshops, demos, and team building. Although team members some times need a break from work, most team members don’t mind meeting when food is involved 🙂
Record Your Demos. A meeting that you don’t want to miss out on getting feedback is the demo; however, this is a meeting that for some reason the product owner and other key stakeholders will often miss. This meeting is not only about showing off and having the team get some positive feedback — it is more about just getting feedback. Try recording the demo. Make the video less than 10 minutes, don’t worry about it being Oscar quality, just get it done and sent out to all those that can give input. Solicit feedback within 24-hours of sending out the video, re-enforce the need for the feedback and participation. In addition to the value of getting feedback from the stakeholders, the recorded demos are great timeline artifacts that can be used for retrospectives.
Conduct a Science Fair. Often when scaling agile, there will be a product owner that works with multiple teams and making time for reviews and demos for all teams around the same time is near impossible. So to get around this, conduct a science fair — have teams assemble in a meeting room and demonstrate their latest accomplishments. This is not only a fair for the product owner, but this is a great time for teams to get together and see what the other teams are up to. This is an event that the whole organization can be a part of and it is a great way to get an organization excited about capabilities forth coming.

So if your teams have had some challenges with face-time with the customer, difficulty establishing a cadence, or you are just not getting valuable feedback — try one or all of the approaches above. These approaches can not only improve the collaboration, but they can be fun and challenging which will show up in improved team morale.

Reinvigorated Retrospectives

in Agile Engineering/Teams by Matt Badgley

Have you these statements lately?

“Our retrospectives have dried up.”
“Why are we doing this? We never do anything about it.”
“Uh, I don’t know – there’s nothing that we need to change.”

Well, this is not uncommon for agile teams to reach the point where their retrospectives become ineffective or the team members stop seeing value in the meeting. In fact, this occurs with both newly formed teams that just haven’t grasped “Inspect and Adapt”, and mature agile teams that have either lost sight of the need for continuous improvement. There are multiple reasons why retrospectives may be going south, but there’s three biggies that stand out in the crowd:

They’ve Become Monotonous. Ok, so we’ve been asking the same three questions for the last six months – “What can we Start? What should we Stop? And, what should we continue?” Although this format is tried-and-true, it takes on Borg-like repetitiveness – especially when it happens every two weeks.
No Actions Taken. “That’s a great idea”, “We should do that”, “We need to make that happen”. These are all great phrases often exuded during retrospectives and rarely are the items that these phrases share context with are implemented. In fact, after the fourth retrospective performed – those actions and or issues mentioned in the first retrospective are re-digested.
Quiet Majority. The quiet majority are those in the room that simply never speak up unless called upon. These folks often are incredibly smart, but there are those in the room that tend to overpower and then those that have just given up on sharing their input because of the first two reasons identified above.

So now you are saying, “this is exactly what’s wrong with our retrospectives, but what should we do about it?” Well, here are a couple great ideas that work:

Sailboat

There is a great game called Speedboat from The Innovation Games Company. The original goal of Speedboat is to frame up a constructive manner by which customers can provide product feedback without spiraling into a complaint session. The great thing is that this game can be used by teams for performing retrospectives. This game has been transformed and adapted to Sailboat (first saw this posted here). Here’s how it works:

Assemble the team, you’ll need a whiteboard (or sheet of easel paper), sticky notes, and black pens.
Draw an ocean, a sailboat floating on the ocean, and a couple anchors. If you are the artistic type, feel free to add some flare (I like fish).
Hand the pens and sticky notes to each of the attendees, and ask them to write down the bad things (or issues) and good things (or efficiencies) that have been discovered since the last retrospective. Give everyone 5-10 minutes to write down their ideas, thoughts, and or opinions – encourage the team to participate.
After everyone is complete, put the sticky notes on the sailboat – the good things represent wind in the sails and the bad things represent the anchors that slow the boat.
Once the sticky notes have been placed, have the team organize them into themes or simply groups of like items (e.g. issues surrounding quality). Eliminate duplicates and consolidate where possible. Within each theme, rank the different sticky notes.
Now the team should discuss each top item and identify issues that need to be worked and or stories to add to the backlog.

4Ls

The 4L’s is a retrospective technique put forth by Mary Gorman and Ellen Gottesdiener. Teams like this format in that it’s quick and forces all parties in the room to interact. The 4L’s are: Liked, Learned, Lacked, and Longed For. As you can see, the 4L’s give people a simple area to focus their thoughts that can easily be translated into issues and or stories for the backlog. Here’s how it works (taken straight from Mary’s and Ellen’s Blog):

Assemble the team, you’ll need four posters (easel paper), sticky notes, and black pens.
Hang the four posters (easel paper) around the room and title the posters appropriately, one for each “L”.
Ask the team members to individually write down what they Liked, Learned, Lacked, and Longed For since the last retrospective. They should write down one per sticky note. Give the team 5-10 minutes and ask them to put their sticky notes on the corresponding posters.
Divide the team up into four subgroups and assign an “L” to each group. They should read all the notes, consolidate and identify themes.
Have each subgroup report on the themes – this means read out-loud and converse.
As a team, decide how they might use the data. For example, ask “How can we satisfy the “lacked” or “longed for” items?” Identify issues that need to be worked and or stories to be added to the backlog.

Both the Sailboat game and the 4L’s encourage full team participation, they are fast and focused, and they can be fun. No matter which technique you use for your retrospective, always remember a few key rules:

Focus on process not individuals. If there are issues between individuals, have them work it out and if necessary – involve a 3rd party.
Involve everyone. The approaches above help drive this; however, be sure folks are contributing and more importantly they feel their input is important.
Do something about it. The items identified should be tracked and acted upon.

Please share your ideas and thoughts, retrospectives can and should be fun — and they are immensely valuable.

Teams - page 3

You might be interested in

You might be interested in

You might be interested in

Sailboat

4Ls

You might be interested in