"You should do more jenkins than jira"
Below are the slides from a lightning talk I made this week at #agile2016. It describes a problem of relying on jira-like tools for backlog management.
One of my clients recently stopped a jira license and when back to paper. This was so inspiring that I decided to share the story to the world.
Below you find some ideas can you can do this as well.
Today I ran a 60-minutes webinar on Agile and Scrum for the alumni of the Organizational and Relationship Systems Coaching (ORSC) who I studied with.
Both: the ORSC and the Agile communities can give each other so much! I'm looking for the next years of bridging these communities.
See the video + slides of the recording of the webex session.
Otherwise, enjoy the slides:
Agile Coaching Canvas is packing bags, as over the next months I'll be running this interactive workshop on some of the coolest Agile events worldwide:
Read my new article ScrumMaster is not (just) a Team Coach/Facilitator.
Just reread the Scrum Guide.. Still no updates.. Not a word on this subject.
The only occurrences of the root 'lead' found twice are:
"The Scrum Master is a servant- leader for the Scrum Team."
"The Scrum Master ... leading and coaching the organization in its Scrum adoption."
The only reason Scrum Guide isn't mentioning this commonly seen role is probably because it is not relevant to Scrum. I guess this is true...
But still it can be of your high relevancy when it comes to a Scrum adoptions - because this role is most likely present and is a part of the system you're working in. So it can't be ignored.
Today on my CSM class (surprisingly full with Team Leads) I got surrounded by them seeking for the truth. They wanted to know how do I see this role fitting with Scrum organizations?
Start collecting lists of all issues risen on retrospectives. Until you have them all.
Yes, simply retrospective after retrospective keep adding outstanding problems to an ever-growing list of documented and known issues.
Until one day someones says: "Hey. Why to have this meeting? We already have all the issues listed, huh?"
Always keep action items in Excel sheets on you local hard drive.
Yes, seriously. Being a ScrumMaster you should make sure the action plan is not lost in between the meetings. So keep it secure. Microsoft Excel is probably the best choice. No one would find it and mess it up.
Keep doing that until one day someones says: "Hey. Why to have this meeting? We never do what we agree to do, huh?"
Never remind or check for progress on planned action items.
Yes, plan your retrospective agendas new and fresh every time. Play with post-its, balls, balloons, words. Make it easy-going and fun. And never bring the last retro's action plan. It will create a sour feeling and awkward pauses. It will break the spirit.
Keep doing that until one day someones says: "Hey. Why to have this meeting? We never do what we agree, huh?"
Volunteer and assign yourself planned action items.
Leading by example and servant leadership are here to stay. So volunteer for all action items. If you can't make them, who can? You're the process leader in the end, that's how you lead: pray what you preach.
In the end, you will never find the needed capacity to do all that is planned on you. Because this is not the only meeting where you show how to volunteer.
So keep doing that until one day someones says: "Hey. Why to have this meeting? We never do what we agree - even our ScrumMaster, huh?"
Let participants complain, justify and lay blame.
Retrospectives are to release the steam. So make that happen. For every issue addressed help to find someone or something to blame it on.
And if all the options are already taken - help to justify. There are always a set of good arguments to be found why something had or hadn't happen.
Until one day ...
Now seriously - do quite the opposite!
And see if the retrospective cheat sheet and the accompanying book can help you make your retrospectives affective and efficient.
This is not a vanity post.
This has become a pattern over the last year: at each class I teach I'm approached by several people who say my flip-charts look very good.
To my eyes there are not. I know how I want them to be. And I'm very much off my personal goals. But I'm happy if this makes others happy. The secret is that is very easy and in this post I'd like to share several key advices how to make your flip-chart drawing look 5-x times better.
1. Put everything into boxes
Literally everything. Every statement, word, phrase, part of your drawing - put a simple black box around it. Is it that simple? Yes!
2. Color the background
Yes, color everything. But leave you boxed titles, key phrases and other drawings in white. The background will make the white elements highlighted, jumping off the image.
I use wax crayons for coloring background, I guess any others would work. But not the markers - the background colors should be lighter, so use some kinds of crayons.
You can also logically separate several parts of your image by putting them in different boxes and using different background coloring.
3. Add shadows
I'm using a gray bold marker to add the shadows under the boxes, on the figures and other elements.
I always do it on the right-bottom side, assuming the light is falling from top-left. There is a little trick though:
- for flat objects (like boxes) - add a shadow outside of the elements
- for 3-d objects (like people figures) - add a shadow on the elements.
4. Use markers whose chisel nibs are wedge-shaped
Yes, Sadly 99% of office markers have round edges. So get your own and carry them around.
This makes your font nicer. The same goes for the shadow markers - wedge-shaped edges are the must here.
Well, frankly speaking that's it. Take any of your sad-looking flip-chart drawing - add boxes, background and shadow and it will be 5-x times more attractive. I bet you.
"If you are a hammer - everything is a nail."
Over the last years we've trained an army of ScrumMasters and Agile coaches.
Sadly some of them can be dangerous. As they can be carrying hammers in their pockets.
That hammer is called 'Scrum' or sometimes is referred to as an 'adaptive team-based framework for process improvements'.
No, I'm not going mad. I still think Scrum is a great tool for some of us to get started gaining agility. I saw many successful implementations and happy endings. Still I know it is a dangerous tool. And shall be used with care and knowledge. And also - not always.
And one of them is "making safety a prerequisite" - that's they one on a blue background:
Last weeks I've spoken several times on this subject: in Minsk and Kiev.
This is going to become my main talk of the year.
Basically my message boils down to the following thoughts:
My slides provide an exaggerated example of how one decision of forming teams (component teams) adds to the complexity of overall organization. Cultures changes of course follow.
At Agile Eastern Europe Season 7 - I ran a workshop based on my recent mini-book Agile Retrospective Kickstarter.
The biggest surprise was that there was much more participants than we could physically fit in the room. Woah! This was really unexpected.
Luckily we were able to find a room to re-run the workshop on the second day. In total I had 30+26 people attending. Considering the size of the conference (around 300 people) that's quite nice.
I shall be glad.
My first workshop this year on the Focused Agile Coaching seems was well accepted. 120 minutes of rich coaching dialogs with a 15-minute demo session. Great chance for me to learn and get the long-awaited feedback on the approach I've been developing.
It was not a workshop on practicing coaching skills, no. Some people thought this would be one of my 6 skill-based workshops on ScrumMasters' Essential Skills. No, sorry if I confused you, guys.
This workshop was designed to let you all get introduced to and practice a thinking tool - Agile Coaching Canvas. It is to help yourself and your teams see a bigger picture behind impediments, issues, problems and little incremental improvements.
COMMON ISSUES WITH INDIRECT FEEDBACK:
Have you see this:
An employee A talks to his Team Lead to talk to the other Team Lead of an employee B because that guy breaks the work of the employee A.
Or in a "Scrum" organization:
A team member A talks to a ScrumMaster to talk to an team member B that...
And that's not good or bad by itself. Hopefully all the Team leads and the ScrumMaster do their job and pass the feedback. Hopefully also the situation improves. Until a certain moment, when A has another issue with B. Or maybe this time - B has something with A...
In the end, it may turn out that the specific issues rose are just symptoms. Of what? Perhaps, of the relationships between A and B (if there are in fact any relationships at all... but one also could say that absence of relationships is also a kind of relationship). So yes, it is safe to assume it is about their relationships.
While ScrumMasters (or whoever) are carrying feedback between As and Bs - they are not really improving the systems. In fact we are creating more systems! See what's actually happening:
As you can see, you're just creating more systems. Does it improve the initial A+B one? Likely not.
Because even if you soften their disagreement, they still don't know how to deal with their relationships. The way to teach is by doing.
RELATIONSHIP SYSTEM VIEW TO RESOLVING DISAGREEMENTS
In fact, the best thing you as a collaboration coach can do is to ... make the collaboration happen. Though, that can be harder to do than to say.
If the conflict is not in a state of a 'nuclear war', but rather in a space of a 'working disagreement', here is a way to deal with it in order to improve the system.
1. Appoint a meeting you, A and B.
Most likely you need to check beforehand if A and B are OK to be on a meeting with each other. And if not, then you know you're likely in the 'nuclear war' state and this method won't work. Sorry. Find another blog post.
But if they are OK, then:
2. Open up with sharing your observation on their relationships. And ask for their permission to open up this topic.
Start with something like:
- Guys, thanks for coming. I've noticed you had this disagreement on a topic X. The topic X is important for me as well. But what's the most important is your relationships. This is not the last issue popping up. I hope more to come as I see you as a long-playing team. And I think it is important for both of you to learn how to deal with such situations.
Check for the feedback. In 80% cases they will agree but then immediately start sharing some facts that prove them right and the other party wrong. So now you know there is a disagreement!
- Guys, this is exactly what I'm concerned with. Do I have your permission to guide this meeting today?
3. Make them agree on anything. This will serve as a basis for further agreement building.
- I know you have different views on the matter. But let me ask you, A, first. What do you want for the team | project | department | company?
Let A speak. Then talk to B:
- Now, B. What do you want for the team | project | department | company?
After B finishes, summarize and find a shared goal:
- What I hear guys is that you both want this ... for theteam | project | department | company. Would you agree?
Iterate until you find something they both agree with.
4. Now let them discuss the details of the situation with that working disagreement.
- Great guys! We now know you both want the same. Now onto this specific question...
It helps if you find an object at a table to use as a token. So that they could point at it (and not to each other).
- This is the situation (point to the object). B, how do you wish it to be different?
Let B share her ideas and let A repeat it to make sure they understand each other:
- A, to make sure you understand each other. Could you please summarize what you've just heard from B?
After A and B agree on what B wants. Do the same in the opposite direction.
5. Seek for intermediate agreements
- So guys, having heard each other, you should now have slightly better understanding of each other's needs. Right? I'm sure there is a way to satisfy you both. So how can we make sure that the interests of you both are met?
Facilitate a brainstorm and let them agree on an experiment or a trial to run.
Hey, I've decided to share my CSPO class deck to whoever can find it useful:
- other trainers
- participants of other trainers' CSPO classes
- future participants
This particular class took place in early 2016 with a group of 23 participants.
It is a two-day class with a lot of workshops and simulations - they are not described in the deck. But what you get is a main story line of the material taught along with some key theoretical concepts.
Enjoy and reuse.
Using the Agile Coaching Canvas to drive visioning for agile change.
Agile Coaching Canvas is a thinking tool to facilitate visioning of agile coaching. Simply speaking - it is a guide that helps ScrumMasters and Agile coaches find a bigger sticky picture of the future they are co-creating.
Sprint Retrospective is the only Scrum ceremony that has books written about. There is no book on how to run Daily Scrums or Sprint Plannings or Sprint Reviews. Guess why?
Yes, running Sprint Retrospective is the hardest one of all to facilitate and also to participate. Especially when it is done poorly or when the same agenda is repeated over and over again. Last year I've shared my top favourite 16 retrospective exercises as a Retrospective Cheat Sheet that is easy to use and helps to combine those activities in a lot of unique and fun retrospectives.
But now there is more to it.
While the English version of my mini-book has reached 500 readers, the book is now made available in various translations and bundles with other books on agile retrospective for a much better price.
GET THE SIX GREAT BOOKS ALTOGETHER
Starving for information on running agile retrospectives? Would eat an elephant? Well, here it is!
This bundle contains all six books on retrospectives that are out there on Leanpub. A great offer. And a great addition to your virtual book shelf. Worth sharing with your teammates and fellow ScrumMasters.
BUNDLES IN FRECH, POLISH AND RUSSIAN
There has been recently a very heated debate on the ScrumMaster Community on Facebook. It all started with a provocative question from Ben Linders on who should be solving impediments. My answer was "teams as much as they can, except when the issues are out of their power - then managers". And then the flame started.
A SAD STORY
The discussion on Facebook collided with my good friend (and a great ScrumMaster) sharing with me quite a sad story of his. Some weeks ago he was fired along with his other 15 colleagues, also ScrumMasters.
The company decided to keep just a few. Interestingly the company never decided to stop using Scrum. It was just "optimized to remove overhead". That happened the day a new CEO came in and claimed that "ScrumMasters add no value" (a literal quote I was told).
Think of this once more: in a Scrum company, ScrumMaster became an overhead role.
What have we all done wrong in the industry that it is going sideways that badly?
It starts with (mis-)understanding the dynamics of team maturity and the role of removing impediments. So let's see.
Facilitating collaborative New Year’s resolutions has also been known in the space of agile coaching for quite a while. The idea behind this is to run a collective ideating and dreaming session. The goal in to help the team see itself in a year from now and then also possible derive some actions.
So one could see collective New Year's resolutions as one of many ways of running futurespectives.
In this article I’d like to share a very practical piece of advice on how one could run such team dreaming parties in quite a structured and a result-oriented manner. Also without making it too fluffy and groundless. This is done with a help of Focused Agile Coaching.
Focused Agile Coaching (or the FOCACCIA method) is a set of thinking tools and coaching techniques that I've been designing. They are to help co-create coaching vision and then slice it into measurable and observable coaching releases.
Read the full article at http://www.infoq.com/articles/new-year-resolution-retrospective
I'm working on a new book and a package of thinking tools for ScrumMasters.
The goal is to disrupt the definition of what we call "ScrumMaster". Bring it to the next level. And return it finally back home where it belongs.
Working as a full-time ScrumMaster in three different organizations in my career I know how unfair and unappreciated it can feel at times.
So my bold goal with this work is to reset the definition for ScrumMastership. Bring it back to how it was originally thought of by the Scrum visionaries and how it is played in a very few truly agile organizations.
We need more visionaries in this role, not just low-level impediment removers and post-it secretaries.
I'm developing thinking tools. They can help drive ideation, co-creation and articulation of strong visions of the future that we - the ScrumMaster - should be leading out teams and enterprises with.
Stay tuned and support my work by showing your interest:
I've written a lot recently on the topic of retrospectives, have even published a mini-book on designing and facilitating retrospectives. That's an important skill to acquire as we Agile Coaches and ScrumMaster are the servant leaders. Facilitation is one way of serving...
But what about the leading part. That's what this work is about.
Quite a few articles, posts and tweets on this topic recently crossed my information space. I've also run a community of practice for agile coaches for a year in a company hearing many stories and whining from other ScrumMasters...
My bottom-line is that we've been born unwanted to this world.
So I ask myself: how come such a powerful concept could have such a poor implementation?
This is a chapter from my mini-book "Agile Retrospective Kickstarter".
All of the exercises I collected in the Retrospective Cheat Sheet work nicely when your team is colocated, namely is in the same physical room.
That’s the sweet spot. Not only for the retrospectives, but in general for teamwork and all-the-agile, as we value rich face-to-face collaboration.
But what if your team is dispersed and the team members are permanently work from different locations? Are you doomed? Or what if the team is colocated in an offshore location with its Product Owner who works from the head office? How can retrospectives for such a setup can be run?
Indeed there are tricks, here are the key ones on running distributed multi-site retrospectives: