Tag Archives: teams

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!