Tag Archives: teams

Agile Coach to Team Relationship

Posted on by

The role or function of an agile coach can be be a bit of a challenge to wrap your head around if it is new to you. Depending on your situation and on agreements with people in your organization, an agile coach could work with a wide range of responsibilities. It could be working closely with a team to improving aspects of the whole organization.

When it comes to coaching a team it can be confusing for team members what type of relationship is natural for them to have with an agile coach. What’s in it for us? What is required from us to get something out of this?

Some basic things are needed to establish a good foundation for such a relationship. Getting some of them out in the open can help. To clarify what this foundation can look like I created this image a few years ago. It is meant to be used as a starting point for a conversation or negotiation between coach and team.

If you are a coach yourself I hope it can help you explain to your team what type of relationship you can offer them. If you are a member of an agile team I hope it makes it easier to understand what an agile coach can do for you, what it will mean for you to have such a relationship and what you can expect from it.

If you prefer an easy to print document, here is a pdf-version – My Role as Coach (pdf).

Team coaching in practice

Posted on by

Have you worked with teams that don’t communicate well? Or teams that don’t collaborate? What about teams that deliver late or with poor quality? Or maybe teams that are in constant negative conflict?

How do you tackle these issues? It might feel like you can fix everything by changing some of the people on the team. Before you do that, consider how you’ve set the stage for your team. Will removing and adding some people really solve all your problems? Or will the new members find themselves in the middle of a dysfunctional team, and end up unhappy and not delivering to their full potential?

Here are some of the things you can think about when you work with teams to create an environment where they can succeed.

read more »

Constellation retrospective

Posted on by

constellationThis is a strong retrospective for bringing issues up to the surface. Instead of just one person expressing an issue as a positive or a negative, the whole team feedbacks about the importance of the issue. The team then decides which issues to tackle. The retrospective also exposes issues where there is not common view, and highlights areas of alignment. It also allows the team to ask tough questions in a safe environment. read more »

What makes your team tick

Posted on by

Screen Shot 2017-04-13 at 16.31.45

You have a team member who has a pressing issue. It’s the single most important thing that they need to resolve. They explain the problem to a coworker, suggest a solution and ask for support… and all they get is a tepid response. This is a situation that repeats itself across workplaces every day. There are many reasons why people refrain from helping. They might not have the competence, they might disagree with the solution/problem or maybe they just don’t have the time. But what happens when they have the competence, agree with the assessment and could easily make time, but choose not to? Why don’t they? How do you help your team navigate these situations?

read more »

How to set role expectations and working agreements

Posted on by

teamcultureConflicts in teams about how to work are common. There are expectations from team members on each other that aren’t being met. In a given team, members might be implicitly expected to perform a certain task. The team might have unspoken policies that seem to be common sense. Sometimes people pick up on these unspoken rules and implicit expectations, but when they don’t, you have a team in conflict. You can’t avoid all conflict (and a dose of healthy debate and discussion is good for teams), but you can help teams by explicitly defining the roles and working agreements. Instead of dealing with conflict after the fact, you start with discussion and agreement. The following workshop is the one I use with my teams and organizations.

read more »

The Pirate Ship – Growing a great crew: a workshop facilitation guide

Posted on by

The Pirate Ship is a workshop format that will help you grow amazing teams. It is “speed boat” on steroids. I have now been using it for a couple of years, and the time have come to share this useful and productive format.

I do a lot of workshops with teams. Very often the workshops are about the teams themselves. It can be anything from getting a newly started team up and running to helping a mature and stable team find new inspiration and challenges.

read more »

Crisp consensus model 2.1

Posted on by
Our consensus signs, by Jimmy Janlén

Our consensus and meeting signs, by Jimmy Janlén

At Crisp we try to use consensus when making important decisions. Why do we do that?

Crisp is a very flat company. Most of us have no boss and report to no one. Basically you can be part of Crisp in two ways: either you have your own firm and have a partner contract with Crisp (all consultants have this) or you are employed by Crisp (administrative personnel). Crisp is owned by most (but not all) of the members/partners. The owners have, however, renounced their right to run the company (from all but legal necessities). This means that the company is run by all partners and employees with an equal vote each. We no longer have a CEO and we elect our board. This means we have to have good ways of making decisions together. And consensus is a very good way of making decision in a flat group like ours.

read more »

Scrum in the large – demystify roadmaps and progress tracking

Posted on by

A good thing with Scrum is that it helps the team focus on short term goals instead of dealing with big tasks with dubious value.  But we cannot either resign and give up long range visibility of where we are heading with the excuse of “we are doing Scrum”.

The latter is dangerous since we are not alone in building the business value of software.  Sales, marketing, support, third parties  -all need to work together to make the software a successful business value.

Pull in the same direction

If we only provide "next sprint" visibility your Marketing manager might – after one year silent resistance of your Scrum trial – go ballistic about lack of date visibility and lobby for a return to the waterfall/Gantt approach.

So let’s demystify the roadmap: a roadmap should help you all pull in same direction.

If you can get all surrounding parties to attend your sprint demo and sprint planning, you have come a long way. But in many cases that is impractical, you would simply be to many or you might loose focus (having to explain details of scrum instead of doing actual planning for example).

A typical roadmap would stretch for about six months. If should provide the overall view as of the release dates of your sprints and the expected content (user stories).

The trick is to demystify the date and content relationship.  By providing visibility in the planned dates for the sprints, the actual content in the sprints might actually matter less. You can move to a more fruitful discussion of “what happens if" (we switch the order of sprints, or move this story )..  Instead of  “I have no clue in what you guys are doing” .

A simple roadmap at sprint 1 could look like:

Sprint 1 Roadmap

Now after sprint 2 things change. A new competitor makes us revaluate the sprint content, order tracking switches between sprint 3 and sprint 4:

Roadmap before Sprint 3 

And since we publish the roadmap on a website or accessible place, we no longer need to provide tedious status reports!

Suggestions where to keep your roadmap:

  •     Published to a web server using Excel
  •     In a Google Spreadsheet
  •     On the wall of your coffee room

Happy Scrumming!