A project manager walks into a bar. The bar is called “organizational design”.
He tries to order beer but can't figure out how. Then disappointed he is about to exit the bar, but can't locate the exit.
Apparently he looks around and notices a lot of other managers around in there. "That’s a trap." - he thinks. "It is a complex system" - echo the others.
This week I spoke at Agile Tour Vilnius 2016 and PM Day Kyiv 2016. In November I'm visiting Lean Kanban France 2016.
This is my third increment of this talk and now I'm happy how it goes: spaghetti, Japanese poetry and complexity seems to be a good combination for any talk.
Below are some photos and selected slides. Down below are a full slide deck. Video is in post-production. Enjoy.
I've re-brushed my CSPO class. Yey.
And I'm currently validating it being on a trip to Tallinn, Riga, Helsinki and Vilnius.
The class has lots of flip-charts, simulations and table discussions, which makes it really hard to share the full experience of it.
Here are some slides to give a little taste:
Few years ago I formulated what I call the "manifesto for offshore agility": five values and eight principles.
Maybe this is a too big name for several statements. But I still find these ideas very important to understand, remember and take to heart when building and running nearshore, offshore, and outsourcing product development initiatives.
I've also spoken about this topic for several years: see one my talks on Offshore and Outsourcing with Scrum.
The key message behind these five values and eight principles is: focus on relationships and the rest will follow. Because as we all know without the basis of stable human connections no process, framework or methodology will last.
So no matter which approach we use to run the product development, we need to be constantly investing in the essentials - people around us and their relationships with us and each other. That's the best methodology I know.
This also implies long-term thinking.
1. Choose people you can easily reach: both mentally and physically.
Prefer nearshore locations, familiar cultures and nearby time-zones.
2. Treat nearshore and onsite employees equally.
With no exceptions.
3. Don't expect to cut operational costs.
Go out to acquire talents.
4. Build the teams with long-term cooperation in mind.
This is your investment.
5. Keep focus on high-collaboration and inter-team cooperation.
Outcomes shall follow inevitably.
"You should do more jenkins than jira"
Below are the slides from a lightning talk I made recently at #agile2016 and #ale16. 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.
And again one historical video. Probably the best recording from a talk I was travelling with in 2012-2013.
The talk answers several key questions to understand why most companies have project managers and project management offices (PMOs).
Back in 2011 and 2012 I was actively speaking about the problematism of offshore and outsource product development and how the agile methods could help. I think still they do. I see it all around.
Surprisingly, this year (2016) several people have mentioned to me that they still remember the "blah blah blah manifesto" I used to present.
Suddenly remembered it too! Here it is:
The message I was trying to convey was that the first value of the Agile Manifesto "Individuals and Interactions" is the key one. And the rest would follow if this one is done right.
And vice versa: if this one is not there - good luck with getting to the working software, adaptive planning and customer negotiation.
Relationships is the key.
"Two out of five members of a development team are constantly failing to finish their stories. A sprint after a sprint. Which impediment is Scrum making visible?
This is a card from my impediment exercise I ran at a CSM class. The right answers of course are:
Sadly, in 8 out 10 times I hear from my ScrumMaster-candidates the following: "the estimates of the two guys are constantly wrong".
This makes me sad. And hopeless.
And I've just found a talk I did at #agileee2013 on the fallacy of estimates. I think it is still quite relevant as our brain hasn't evolved that much since then.
Estimations are always wrong, that's why we call them estimates in the first place. So of course we can justify almost any project issue to wrong estimates. But it won't change a thing. It is like blaming a weatherman for your poor life choices.
I've been dreaming of speaking at the world agile conference since I first attended it in 2009. In those early days event thinking of speaking there sounded incredible and very unrealistic... Almost like a dream.
And it is very surprising that the topic I've presented at Agile2016 is about dreaming. The Agile Coaching Canvas is a coaching technique that helps us reconnect to our big dreams. I use it a lot when coaching/mentoring ScrumMasters, agile leaders and when working with agile teams. I use it every time I feel like my clients are disconnected from the vision of their success.
Articulating a dream is a very important step in letting it happen, so in the heart of the Agile Coaching Canvas is a coaching trick that makes us step into the future of your organizations, see and feel it. This is usually a very strong and positive emotional experience that raises motivation. It helps us connects the dots from the present to the dreamed future. And because the future state has already been experienced during a coaching session, it is usually much easier to find ways reaching it. Or at least it is far easier to think of good first steps we can take next Monday to get closer to our big dream.
So here is my dream coming true - some photos from my workshop:
See me later this year running this workshop later this year at ALE2016 and SGMun.
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 ...
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'.
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.
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.
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.