Tag Archives: Scrum team

  • -

Team Team Scrum Team: Team Building or Team Work?

Tags : 

Team building or team work? Team building is a bit of a strange idea. Think of the great sports teams or project teams of all time, did they do “trust falls” or high ropes courses for team building? Great teams form when good people learn to work together, to trust each other, and have an environment where people can learn and grow into a great team.

“OK, what are the top 10 books on team building?”

How many books do you need? If I recommended 10, how many would you read? How many work related books did you read last month or last year?

I would recommend starting with 1 video based on a TED talk by Daniel Pink.

Then read the book that the video is based on so its points sink in.

Drive: The Surprising Truth About What Motivates Us: Daniel H. Pink: 8601234640691: Amazon.com: Books

Then read up on one framework/model for thinking about team formation:

Tuckman’s stages of group development – Wikipedia

A recent article on teamwork covers some of the challenges of modern team work where team members maybe dispersed (its OK, has some good examples)

The Secrets of Great Teamwork

and finally this classic book by Richard Hackman on leading teams, that while a bit dated supports many of the ideas presented above.

Leading Teams: Setting the Stage for Great Performances

Leading Teams Book Cover

Richard Hackman, one of the world’s leading experts on group and organizational behavior, argues that teams perform at their best when leaders create conditions that allow them to manage themselves effectively. Leading Teams is not about subscribing to a specific formula or leadership style, says Hackman. Rather, it is about applying a concise set of guiding principles to each unique group situation–and doing so in the leader’s own idiosyncratic way. Based on extensive research and using compelling examples ranging from orchestras to airline cockpit crews, Leading Teams identifies five essential conditions–a stable team, a clear and engaging direction, an enabling team structure, a supportive organizational context, and the availability of competent coaching–that greatly enhance the likelihood of team success. The book offers a practical framework that leaders can use to muster personal skills and organizational resources to create and sustain the five key conditions and shows how those conditions can launch a team onto a trajectory of increasing effectiveness. Authoritative and astutely realistic, Leading Teams offers a new and provocative way of thinking about and leading work teams in any organizational setting.

…then there is how not to do it: TEAM TEAM TEAM from IT Crowd.

Use those as jumping off points to additional learning.

Finally, none of this matters if you do not have the environment for effective team to arise. For that you should use Scrum, a team based framework for doing the most important work first, in short cycles, and using feedback (retrospectives) to continually improve the environment and the team.


  • -

New ebook, Agile Advice

Tags : 

book coverMy colleague Mishkin Berteig started his Agile Advice blog in 2005 when we were both doing Agile coaching for teams at Capital One. His blog was one of my favorite Agile blogs, he was getting out the lessons we were learning and providing smart succinct advice. In many ways Mishkin’s blog was ahead of its time, offering sage advice to issues and situations that many people had yet to come across. Mishkin has taken his blog content, tuned it up and added additional interesting stories in his new ebook Agile Advice. You can check out the blog for many great ideas, while the ebook is a more convenient format for those looking to improve their coaching and Agile transition knowledge.


  • -

Should scrum team members talk directly with customers?

Tags : 

A recent discussion on linkedin was started based on the question: Should teams talk directly with users or customers?

It provoked me to write the long response below.

“What do you mean by customer? Do you mean user? Sponsor? Another manager?

The Product Owner (PO) should be representing the various stakeholders for the system being built. The PO should also be creating alignment among the team and the stakeholders as to what needs to be accomplished in the release. This is a balancing act between the various needs, business and technical. The PO is not an information hub, everything doesn’t have to go through the PO. A good PO creates alignment around the vision and the solution, and steers based on their ongoing learning and subject matter expertise.

So I’d split my response into the stakeholder groups:

For users:

In general it is a good idea for a Scrum team members to talk to users. As Geir Amjso mentioned, the PO can become a bottleneck if they try to control all information. Also their maybe some nuance that a user can provide that will help a developer understand the problem more clearly. This conversation is framed in the context of a sprint and is about clarification and understanding to implement the solution.

Another benefit of having users and developers interact is that spark of innovation. Innovation happens when people with tools and techniques really start to understand a problem. Users sitting down with developers creates empathy and helps teams become motivated to provide pain relief or innovations that surprise or delight.

For sponsors:

Not a good idea without the PO around. The sponsor is usually more concerned with the high level issues and the politics/expectation management for the product/project. The sponsors should engage the PO, and if they are going around them to the team, there is something else going on.

For other managers:

It depends. It may make sense if there are dependencies with other teams/vendors and the team is managing those issues within the sprint. It may also be an end run around the PO to get work done that is not planned in the sprint. In this case the team should refer them to the PO.

Scrum does specify meetings where interactions between teams and customers are more formal. However Scrum says nothing about restricting communications to the Scrum meetings. If communications are restricted to these meetings only the team will be slower and have less opportunities to learn. As a Scrummaster the goal is to get great software developed and do it with the highest level of engagement from all parties. This means there are lots of communications that should happen on an ongoing basis between all members of the project community. A Scrummaster needs to enable work to flow from request to working software, and this involves maintaining the flow of information. Will their be deviation? Sure, however the Scrummaster is there to detect when the team or the stakeholders are getting off track (i.e. adding scope, changing direction, etc.) and help them stay on track.

Sure you can talk to the team! Take a seat!


Sure you can talk to the team! Take a seat!