Category archive

Teams - page 3

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

in Agile Engineering/Teams by

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?”

Team hugWhen 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?

You might be interested in

Come to the Science Fair

in Product Management/Teams by

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.
  • sciencefairConduct 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.

You might be interested in

Reinvigorated Retrospectives

in Agile Engineering/Teams by

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

sailboat3_webThere 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:

  1. Assemble the team, you’ll need a whiteboard (or sheet of easel paper), sticky notes, and black pens.
  2. 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).
  3. 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.
  4. 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.
  5. 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.
  6. 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):

  1. Assemble the team, you’ll need four posters (easel paper), sticky notes, and black pens.
  2. Hang the four posters (easel paper) around the room and title the posters appropriately, one for each “L”.
  3. 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.
  4. Divide the team up into four subgroups and assign an “L” to each group.  They should read all the notes, consolidate and identify themes.
  5. Have each subgroup report on the themes – this means read out-loud and converse.
  6. 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.

You might be interested in

Self-Organizing and Strengths Finder

in Agile Engineering/Product Management/Teams by

Team WorkA key part of any good team, especially an agile team, is teamwork and more importantly a team of hardworking individuals that both care about their teammates and they understand the strengths of their fellow teammates.  In the sporting world you will often hear of situations where one player will attempt to play outside his strengths.  Or what is more prevalent, a player has an outstanding year due to either scheme or competition or simply a well formed team that emphasizes the strengths of the players.  Then that player is a free-agent and goes to another team, and the player’s career sags.  This is primarily due to familiarity, chemistry, and scheme that doesn’t fit the strengths of the player.

There is a concept that surrounds Scrum teams and that is the concept of “self-organizing” team.  Now this concept is often not clearly defined and depending on the Agile coach and or trainer, a team member might view this differently (see Does Self Organizing Team Imply Self Assembly?) .  Nonetheless, if we define self-organizing in the simplest form of a team that has the ability to take inputs and based on knowing certain attributes of their fellow team members, work is doled out, people are paired up, issues are worked out, team members are brought in and pushed out, and, in summary, things just start getting done and done effectively.

The “certain attributes” that a team uses for team self-organization often includes:

  • Team member workload
  • Technical background
  • Domain expertise
  • Team member availability
  • Understanding of the tasks-at-hand
  • Priority of tasks
  • Team member “likes”
  • Team member weaknesses
  • Team member strengths

Of course, all of these are important to consider; however, one would argue that the strengths are where all self-organizing should be focused.  As you guessed it, I’m the one to make this argument – and I encourage everyone who runs any type of team to take advantage of Clifton StrengthsFinder from the Gallup News organization (yes, that’s the same Gallup that does many politico and social polls).   StrengthsFinder came about from Dr. David Clifton – he is known as the father of Strengths Psychology.  The focus of StrengthsFinder is to help people identify their top five strenghts where they work best, understand these strengths, and see how focusing on using these strengths versus working on improving areas of weaknesses is much more productive, self-rewarding, and ultimately successful.

Some have grouped StrengthsFinder into the area of self-help or lumped it with personality tests such as Meyers-Briggs Type Indicator.  It is definitely not a personality test and if you did want to categorize it as self-help, you will find it to be much, much better and more effective than any other self-help book or tool.  When I was approached by a colleague that went through the StrengthsFinder exercise and he express the passion that this is for real and fulfilling, I was convinced I had to give it a go.  So after I took the 30 minute survey and got my results, I quickly learned and understood better why I say, do, and act certain ways.  It helped me rationalize and focus my energies within the areas of my strengths so that I can help my team and the company become more successful.  This didn’t mean I wouldn’t ever work on improving my weaknesses, but it did help me recognize where I can use my strengths to overcome or disguise my weaknesses.

So, you are now asking, why does this have anything to do with Self-Organizing agile teams.  Well, soon after going through the exercise myself, Dave (my colleague mentioned above) implored me to have our whole product development team go through the survey – we did.  After everyone had their top five strengths, we compiled the list and posted it on our team wiki.  We all sat down and discussed what we learned about ourselves and reflected on the strengths of others.

At the time when we did this exercise, we were about ten months into using a Scrum agile methodology.   We had earlier delivered a huge product release and we were coming off a really tough period where everyone was getting burned out by the product launch, supporting new customers, and having some frustrating issues largely due to incomplete quality processes.   Soon after experiencing StrengthsFinder, we saw that the team which would normally “mouse-up” during difficult team discussions, would start leaning on each other strengths.  This helped me as the team lead, to simply sit back and let the team work through challenges that when previously encountered, the team would simply brush under the rug.  Going through StrengthsFinder seemed to give the entire team more confidence and it helped those team members that would often simply focus on trying to improve their weaknesses to instead, embrace their strengths and take on the tasks that best suit them.   Not only would they have more self-confidence, but they also embraced the strengths of their peers.  When we would start new feature or enhancement development, the team members often signed quickly and they would ask a fellow team member that may have been stronger in another area to assist (e.g. using a person that has the Relator strength to interview subject matter experts).

Within two months after working through StregnthsFinders, we experienced measurable quality improvements and we moved closer to a self-organizing team where anyone on the team could lead within their strengths.

So if you are working within an Agile team and you are struggling with the “self-organizing” aspects or your team has hit a continuous improvement plateau, give Clifton StrengthsFinder 2.0 a try.  The books required can be obtained for less than $13 at Amazon or Borders.

You might be interested in

Five Ways to Establish Trust

in Agile Engineering/Product Management/Teams by

As everyone knows, a key success factor of an agile process implementation, specifically Scrum, is establishing trust between the team delivering and those waiting on the delivery (basically between the product development team and the business).  In order to establish trust, a development team should be meeting their commitments made during the planning meetings; thus, delivering what they said they would.  Sounds like a pretty simple formula and for the most part — it is.

Never trust the teller. Trust the tale.
– DH Lawrence

Outside of simply delivering what you said you would in a sprint, here are five ideas to establish trust:

  1. Always act with integrity. It goes without saying, truth sets you free.  But what is more than simply being honest while communicating with someone, but it is more important to perform your job duties with integrity.  This means, no cutting corners, maintain the utmost quality, and always keeping the team informed when it comes to matters that may impact the core deliveries.
  2. Ask questions and share information. Make sure that if an idea is not understood, be sure to not be afraid to ask a question (sometimes, the first thing that comes out the mouth is “I don’t know”). Be sure not to assume you are all-knowing about an issue, so share what you know — this is an excellent way to facilitate conversation and potentially discover what you don’t know.
  3. Reasonably accurate expectations (estimates to complete). In the agile world, estimation can be challenging.  This is primarily due to the lack of data present at the beginning of tasks.  The easy way to overcome this and become more accurate with your estimation is to be sure to break down stories into common development tasks.  This may include an analysis, design, build out, unit test, etc type task.  I also like the proto-type, stub, or even the sub-functional task where a small piece of functionality is implemented.  Estimates generally get better the smaller the task and they are of course better when more than one person sets the estimate (leveraging the experiences of others will help).  Finally, always accurately update estimates to complete daily.
  4. Deliver within the boundries of the commitment. Simply stated, don’t always try to be a hero and deliver beyond the expectations of the original commitment. This can be viewed by management (be it product or development) as sand bagging estimates, or simply going rogue and “doing as you want to”. Not to say that finding a great way to do something that was much more productive is not a good thing or seeing that you can do a lot more within the context of the product functional area is not appreciated. But the right way to handle this is to disclose that you found a faster way to do something and your estimate-to-complete is much less than orginally anticipated, so you would like to work on another key capability that is similar to the functionality being implemented. Negotiating this within the context of the daily standup (and possibly within a follow up meeting) would be the correct course of action.
  5. Consistency is key.  Having one good sprint is not enough, a team needs to establish a trend of delivering on sprint tasks on a consistent basis.  This applies to the team as well as the individual.  Once a team is able to demonstrate a consistent trend surrounding capacity, story points delivered, hours worked, etc — the product stakeholders can start to reasonably expect that what the team says they will finish will in fact be delivered.

Remember the idea of trust should also exist within the scrum team and between scrum teams where there is a need to share deliverables or even if you all work within the same development organization. The five ideas above should be applicable to ensuring that all scrum teams work well together and within the overall scope of an organization.

What techniques or ideas do you have about how to build trust with the product management or project stakeholders?  What have you’ve done that works?

You might be interested in

1 2 3
Go to Top