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.
Just last week I spoke at two conferences on Organizational Complexity and Its Effects on Scaling.
The talks went pretty well and I ended them up presenting three most commonly seen (by me) team structures that create an "interesting" dynamics.
Here they are:
This one is seen very often in gaming companies.
There is absolutely nothing wrong with reusing an engine (platform), that's actually a great idea. What I'm talking here is about the managerial decisions on forming teams around these architectural layers.
In this case a set of consumer-facing teams will be building "their" features (products) on top of a shared platform "owned" by another team (teams). If this is your case, you often hear terms like: "engine teams" or "platform teams" or sometimes "system teams".
It is exciting (for a system thinker) to observe how unaligned those two types of teams can be. How much information needs to be handed over from the consumer teams to the platform teams to get "their" back-end part right. How much over-processing and over-production can be created on the back-end side. And how hard it is at times to get the whole thing fly to production, once all teams say "we're done!"
Beware of the system dynamics such structures create.
Cross-team coordination is decided by the teams.
Prefer decentralized and informal coordination over centralized coordination.
Needless to say, that this article is heavily inspired by the principles behind the LeSS framework.
A great talk by Eric Ries on Lean Startup and intrapreneurship.
Minimum Viable Products
A great article on six different and radical approaches on validating the key hypothesis with early MVP. Examples from well-known businesses.
Today (XING office in Hamburg, July 2015) our sprint review was different. It didn’t look like any meeting at all. If you would enter the team areas you wouldn’t see anything drastically different to our normal working mode: people are talking in small groups, several people are discussing something by looking at their mobile phones, several others are leaning over tables and looking onto screens. Nothing like a meeting.
But two weeks ago and also every two weeks for the last year or so, this event looked pretty much different. We all would sit in one of our large meeting rooms with 40-50 people attending. One person would speak on a stage for about 7 minutes and others would watch the presentation. Then someone maybe ask one or two questions. Then people would applause and switch to the next presenter.
This was our “standard” way we used to run joint sprint reviews for the 3 teams in our XING mobile cluster. Then since our review was well attended, we invited several other teams to join. In the end we began to have one of the biggest sprint reviews at XING. Huge success! Really?
But despite the high attendance of the guests including the C-level executives, the feedback we started to get from the teams was rather on the negative side: the reviews were taking too much time to prepare; it was stressful to speak in front of so many people; not all of the presentations were uniquely valuable and engaging… and so on and so forth. But the main negative signal we heard was rather strong: the teams were receiving close to zero feedback (applause won’t count)
That was a refreshening “aha” moment for me (an Agile coach) when I came to realize the fact. Especially because I was one of the people who had stood behind creation of the joint review format. As a quick history tour: two years ago when I joined XING each team had a dedicated Sprint Review. But the teams were not receiving equal attention from the stakeholders and management. Also it was quite challenging for the stakeholders to attend all teams’ review. So we decided then to merge the reviews. What we ended up having wa a gigantic Sprint Review that was well-attended by stakeholders and the top company people.
But somewhere on the way apparently we’ve lost an important piece: feedback on the product. That was definitely a learning path.
But why feedback is so important? Well. Scrum is based on the mantra “inspect-and-adapt”. And that’s for a reason. Software development is a complex process that requires empirical process control. Which in simple words mean: one can’t just simply plan software development and then go and execute the plan (that would be a defined process). Instead you need to go a small distance, then stop for a moment, look around and based on what you see decide how you adjust your route. That’s empirical.
And that’s what the Scrum teams are supposed to do when running Sprint Review (and also Sprint Retrospectives) in Scrum: stop, inspect what they did and decide how to adapt it in order to improve.
Now back to our situation. We did the stops. But we didn’t get enough of useful insights on where to go next. So why to have Sprint Review at all? In the end, I’m sure that question was on many people’s minds…
So what we did was following the advice from the Large Scale Scrum practitioners: do the Sprint Review Bazaar (we, being a German company, like the “Beer Fest” metaphor better).
So that what we did:
Benefits we gained:
There are of course things to improve, so more experiments to come. Inspect and adapt, right?
But what has become obvious is that the “Beer Fest” style of Sprint Reviews is the way to go. At least for the next few sprints until we find an even better idea.
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.
Sign up for the newsletter.
No spam. Only relevant agile news and updates from Alexey Krivitsky.
See our past newsletters to see what kind of updates you'll be receiving.
(C) 2015-2016, agiletrainings.eu