Why Teams Don't Work

---

This title does not seem to fit with today’s mantra of building teams, creating high performing teams, spinning up Agile teams, now does it?  Yet it seems to be a popular choice for those trying to teach the fundamentals of teamwork.

Why Teams Don’t Work

The Harvard Business Review published “Why Teams Don’t Work – An Interview with J. Richard Hackman” in May 2009.  Hackman maintains that in order for teams to “create magic”, they must be real.  When asked to expand on what this means he noted that his research yielded fewer than 10% agreed who was even on “the team”.  He notes that not everyone who wants to be on the team should be included and some individuals should be forced off.

Think about this as it relates to Agile or Scrum teams.  It is well-known and taught that characteristics of Scrum teams include:  members are self-organizing, cross-functional and 100% dedicated.  Yet many organizations ignore this, decide the teams for the people doing the work and tell them that they are now on a team.  Or worse, on more than one team.  Maybe Hackman is on to something in saying teams don’t work because these organizations say they want to adopt Agile or Scrum, ignore characteristics that enable team success and then say things like “Scrum doesn’t work”.

Harvey Robbins and Michael Finley chose this title, “Why Teams Don’t Work” for their book also.  It won the 1995 Global Business Book Award.  They also agree that team members do not have to be best friends but they have to agree that they are on the team and not engage in “turf wars”.  The team has to focus on a common goal and to agree on what that goal is.

Once again this resonates with what we teach Agile and Scrum teams.  One of the Scrum values is Focus.  Requiring a team to be 100% dedicated allows them to focus on that common goal which increases the likelihood they will achieve it.  As opposed to splitting their focus and losing valuable time to the act of context switching between competing goals.

Many who attend Collaborative Leadership Team’s Certified ScrumMaster Class or Agile Boot Camps seem surprised as we talk through the team characteristics.  As class participants paint one picture after another of challenges they face, we find ourselves asking them “Is this a Scrum problem?  Or a people problem”?  They sigh as the realization occurs to them that they don’t have “Scrum or Agile problems” but what these collaborative, transparent frameworks have exposed is the people challenges.

So how do we get better at this people stuff?  If only we had a dime for every time we got this question.  With all sincerity we tell people to read “The Five Dysfunctions of a Team” by Patrick Lencioni, “How to Win Friends and Influence People” by Dale Carnegie and absolutely anything Dr. Phil has written.

The Scrum Master’s job is not about administrivia and is about getting people to work together to deliver business value.  Old ways of doing work allowed us to hide from the people stuff.  We could hide behind design documents, requirements documents, status reports, etc.  With Agile and Scrum approaches, the emphasis is on people instead of the documents leaving many wondering what to do with this new approach.

Don’t have time to read?  Three easy tips for any new ScrumMaster to get started in focusing on the people stuff include:

• Really listen.  Do not “wait to talk”.  Do not type or write as someone talks.  Look them in the eye and really listen to what’s being said.
• Actively facilitate. If someone is interrupting, have the courage to ask them to wait until the person speaking is finished before jumping in.
• Ask questions. We take other peoples’ power away in subtle ways – usually by telling them what or how to do something.  Every time you are tempted to make a declarative sentence, ask a question. This will invite team discussion and enable them to reach their own decisions.  Far more empowering.

Want to learn more skills for working with teams?  Join us as we welcome Harvey Robbins, Ph.D., L.P. for his Creating High Performing Teams workshop November 12:

https://www.eventbrite.com/e/creating-high-performing-teams-tickets-18476066412

The ScrumMaster Files: A Group of People Does not mean Team

---

You are a first time ScrumMaster with a first time team.

The 7 person team has been together for many years before they moved to working with Agile.

You have worked many years with the team before you became their ScrumMaster. Everyone gets along and when you look at where the team started compared to where they are now, you do see progress is albeit painstakingly slow (it seems).

The team all went to the same Agile training as you did. You have really taken to the role of ScrumMaster, feeling this is your calling in life. You have been working hard to become ‘master of scrum’; reading books, blogs, watching any videos or Ted Talks to help you fill your toolkit to make you better equipped to make the team the best version of themselves every day.

The biggest source of frustration for you with the team is how little they talk or interact with each other. In the beginning of your scrum journey you felt it was due to lack of confidence in working a new way. However after 7 sprints you hoped the team would be more like an Agile team; collaborating, discussing, dog piling tasks to done.

After trying many different techniques from what you have read and not seeing any improvement. You have tried ideas from other scrum masters in the organization and even ideas from your mentor and agile coach with little to no success. It still feels like you have to ‘pull teeth’ to get them to talk and bring up ideas or just interact.

The team does provide updates at the daily scrum on their own individual work. During the retrospectives the team does come up with some ideas. They are starting to pair ‘some’ but the team still mostly works in their old roles and do not seem to understand how empowered they are to determine how best to get their work done together as a team.

Not surprising the team struggles to consistently make their sprint goals. It has been hit or miss for the past few sprints on what they commit to in sprint planning and what they actually deliver at the sprint review.
Some things to consider to get you started:

• Have you talked with members one on one to learn more about team members as people?
• What would you try to get the team to communicate with each other?
• Is there a particular Retrospective technique that you would try?
• What would you do if you were the ScrumMaster of this team?

Increase Transparency & Morale through Sprint Reviews

---

Collaborative Leadership Team (a Certified Agile Consultancy in Minneapolis, MN shares our thoughts about the opportunities Sprint Reviews give us that go beyond a simple demonstration of work.

Sprint Reviews are a time for the Development Team and their Product Owner to show what they have accomplished during the Sprint to all interested stakeholders.  This Scrum ceremony is an easy and effective mechanism for Agile teams to increase visibility into the product they are creating.  Since the Sprint Review typically happens on the last day of the Sprint, the Development Team has the privilege of demonstrating the work they completed during the current Sprint and highlighting how that work fits into the overall product vision.

Anyone is welcome to attend Sprint Reviews.  The more the merrier!  This ceremony is an “inspect and adapt” mechanism for the Product Owner to get early feedback from stakeholders and provide them with transparency.  This active demonstration of potentially shippable product increases trust in the Development Team’s ability to deliver high quality, working product, trust in the Product Owner for what they chose to focus on and an overall increase in morale as an organization.

In a Sprint Review there is no room for a PowerPoint slide showing how the product should work.  Instead the Development Team does a live demonstration to show how the product actually works thus far.  There can be angst about showing a live demo as sometimes things go wrong with environments, machines, or any number of things.  That’s OK!  Agile is about taking small risks, learning from those experiments, and making improvements along the way.  If a team discovers repeated issues with environment stability while doing Sprint Reviews, this can be addressed in a Sprint Retrospective to address such an impediment.

While showing working software or product, Sprint Review participants can get excited and ask for additional features.  That’s OK!  Simply smile and reply with “Thank you for your feedback.  We can add that to the Product Backlog and it will be ordered in relation to the other items in the backlog.  Let’s talk about that after the demonstration.”  Sprint Reviews need not be a cause for concern or fear of scope creep based on the empirical nature of the Scrum framework.  We inspect, adapt and provide transparency.  It’s not a license to keep piling on the plate.  The plate is ordered in terms of what we will do first, what comes next and so on.  If a better idea comes along and shoots to the top of the list, it’s OK if somethings drop to the bottom – or even off of the list entirely.  This Scrum ceremony should be a time to celebrate the progress the team has made in the current Sprint and talk about what we can potentially do next.

Since showing iterative or incremental, working product is often a new way of doing work, it is important for the Product Owner to set appropriate expectations with those attending the Sprint Review.  The ScrumMaster can assist by teaching those outside of the Scrum Team the intent of this ceremony and helping to neutrally facilitate any conversations that come up during the ceremony.

Sprint Reviews are great opportunities to not only increase visibility and transparency into product development but also to increase morale by demonstrating work done and accomplished goals. 

Want to learn more?

Click here for our June 2nd Certified Scrum Product Owner (CSPO) Course

Did we Really use Scrum to Build a Car in 1 Day? Yes!

---

It was so much fun, we did it again the next day!  Collaborative Leadership Team and Keyot sponsored Scrum Inc.’s Joe Justice and Joel Riddle to lead us in an eXtreme Build Parties this week.  CLT and Keyot brought our clients together for the experience ranging from those who have heard about Scrum to those who have been working this way for years.

Regardless of Scrum or Agile experience levels, work history or current “day jobs”, these people had a great time and learned a lot in the process.  When we say eXtreme Build Party, yes it’s a party.  Complete with dance music, synced lights and beer.  The atmosphere energized people and helped them feel open to the learning experience and as Justice points out, there has never been an injury working this way.  Treat people like adults, they act responsibly.

Both parties were closed with a commitment circle where participants were asked to take 1 idea from the experience back into their work environments to help with everything from team work, increased communication and making work visible.  Here are the biggest “Ah-Ha!” moments from the crowd:

Scrum is Simple: Scrum is really only 3 roles, 5 events, 5 values and 3 Artifacts.  At the start of each day, Joe and Joel lead a brief Scrum overview and asked the participants how long it typically takes to spin up project teams.  The answers ranged anywhere from 6 weeks to 6 months!  Joe facilitated each days’ participants into self-organizing into cross-functional teams of no more than 5 people.  Each day this was accomplished in 7 minutes or less!

Scrum is Disruptive: Joe provided a word of caution to those newer to Scrum.  “Initially things may feel exactly like chaos.  And that’s perfectly normal,” he added.  Traditional ways of working focus on having the right plan.  The only problem is change happens.  Scrum teaches us to inspect, adapt and provide transparency which is really about continual planning.  Everyone did a great job of demonstrating the Scrum value of Openness, however nervous, heading into Sprint 1 planning.  By the end of the first Sprint, there were cheers, high fives and celebratory music for passed tests and getting Product Backlog Items to “Done”.

Scrum Breeds Productivity and Innovation: The number of participants who had never built a car far outweighed those in attendance who had any automotive experience.  And yet, each team on each day continued to gain Velocity – “clicking” as a high performing team and accomplishing work more quickly.  Rather than reach for new Product Backlog Items that were not yet “Ready”, Joe taught them to help the other teams out so that all Sprint Goals could be accomplished.  Not only did more work get done, “cross-pollination” occurred, spreading knowledge across teams rather than it remaining in “siloes”.  As teams picked up steam and worked together to accomplish the planned tasks, they were then able to add new items to the Product Backlog that were innovators – improving the base product.

Want to learn more about eXtreme Manufacturing? 

Please visit Joe at Scrum Inc.:
http://www.scruminc.com/extreme-manufacturing-build-party/

Want to learn more from the Collaborative Leadership Team about becoming a Certified Scrum Product Owner?

Please visit us here:
http://collaborativeleadershipteam.com/certified-scrum-product-owner-cspo-6/

Why an Agile Build Party?

---

Why a Build Party?

• As Agile and Scrum move into the mainstream, people are using this approach to build many other things – beyond software.
• Build Parties are perfect for introducing agile concepts to an organization or to help practiced teams re-launch.
• Because attendees apply the Scrum framework to solve complex problems, build parties are a terrific way to win buy-in about agile practices.
• No Agile experience or automotive background is necessary.

  Click here to learn more and register!

Whose car is it?

• Keyot and Collaborative Leadership Team partnered with Scrum Inc to bring this Build Party to the Twin Cities of Minneapolis and St. Paul, MN.
• Scrum Inc will be shipping one of their WIKISPEED vehicles to MN for the Build Parties.
• The car used for the party is owned by Scrum Inc and will not be sold to anyone for profit as a result of the Build Party.
• Costs for the day pay for Scrum Inc staff, shipping the car of course and the awesome training that will take place.
• Joe is a Certified Scrum Trainer for Scrum Inc:  scruminc.com.
• Joe still maintains WIKISPEED as a volunteer based organization.  For more information about WIKISPEED please visit:  wikispeed.org

What can I expect if I attend?

• We kick off each build party by having the attendees self-organize into five person scrum teams, complete with a Scrum Master and Product Owner.
• Teams then swarm on the backlog to complete as many stories as possible, with quality.
• Each sprint the teams get a chance to review their work with the facilitators while using scaled Scrum to address impediments, demonstrate their work, and refine the backlog.
• Keyot, Rally and Collaborative Leadership Team are ensuring that everyone will be well hydrated and fed throughout the day including a continental breakfast, lunch, dinner as well as adult beverages.

 Click here to learn more and register!

Can we drive the car?

• Yes but that is entirely up to the teams!
• Some teams succeed in completing the car by the end of the event.
• Some teams do not succeed in completing the car by the end of the event.
• Either way, the experience in working “hands-on” as part of a Scrum team is totally awesome!
• Where else can you apply Scrum and eXtreme Programming concepts in a Manufacturing setting as a way to jump start your learning?

What will the environment be like?

• Keyot has a garage attached to their building so we will be “covered” from the elements.
• If weather permits, the garage doors will be open.
• There will be music and power tools so dress accordingly.
• Close-toed shoes are highly recommended.
• Tying back long hair is also highly recommended.

Click here to learn more and register!