I was presenting this workshop in Vilnius on May 2017.
The main line of thoughts:
Then we review the some sample structure decisions that affect culture in different ways:
After publishing of an article Large-Scale Scrum simulation with LEGO Bricks #lego4scrum #less I got few invites to run this workshop at conferences.
Now the list includes:
The Agile Coach Competency Framework teaches us that there are four competencies in a toolset of an Agile Coach:
You might have asked yourself: where and how do I know exactly when to apply which stance to create the highest impact?
To answer this let's look into obtrusiveness of agile coaching stance (below is my personal understanding).
Despite the fact that all of the tools are handy, some can be less obtrusive and have a more natural fitting into the environment (like water flowing into water) and others that create waves and new streams (like throwing rocks in the water).
Facilitation is the most unobtrusive tool to use. The coach here doesn't have an agenda and helps the client balance the flow of collaboration. The coach is an expert in collaboration and can help clients have richer discussions on the topics they are interested in. In any new situation the coach can always rely on her facilitation skills. That's a lifesaver. It is also pretty powerful.
Professional Coaching is slightly more obtrusive than Facilitation. Here a coach still follows the client's agenda, but can decide to guide the client to explore unknowns, what-ifs and what-would-it-be-likes, that the client might not even know exist. By using this competency a coach can help the client see new unseen paths and directions. It can be also used to raise motivation and commitment.
Both facilitating and coaching the coach assumes the client has all the resources and inner wisdom to drive to needed conclusions.
If it is not the case, then teaching and mentoring are the proper tools for the task.
Teaching is far more obtrusive than Professional Coaching. The coach here wears a trainer's hat, stands by a flip-chart and raises his index finger explaining the right way of doing things. She is knowledgable in the content of the domain. She explains the fundamental theories, proves them right and shows new ways of accomplishing tasks. She is showing options. The decisions whether to apply the new knowledge and skills is still on the clients' shoulders. They are in the driver's seat, it is them who will drive themselves to the new horizons (or maybe not).
In my view Mentoring is the most obtrusive of all. It doesn't mean you need to avoid it. No! But it needs to be used with caution and deep awareness of the impact and dependency created between the mentor and the mentoree. Here the mentor (rather: an agile coach wearing a mentor's hat) is pairing with the clients. The mentor is an expert in the domain. The coach shows new practical skills, pairs up, gives exercises, provides feedback, gives pieces of advice and leads by example. Usually some kind of teaching happens in between teaching sessions (or had already happened earlier) to explain the theories behind the practices.
A great agile coach has mastered all of the Four Stances and uses them constantly and alternately.
Is ScrumMaster a full-time job? Why do we need one?
Consider these 10 things great ScrumMasters do on daily basis:
Being a Scrum Master is not a just fulfilling a role description.
It is a way to look and work with the world around us.
It is not just a full-time job.
It is a mindset.
After dozens of years of studying teams we know some things for sure: teams are dynamics, fluid and unpredictable.
A team that hit a star two days ago might be completely lost today. What was motivating and driving the team during the last project might now seem a total boredom. What the team appreciated you doing for them last week might not work out this Monday.
And vice versa.
So all the efforts of describing a function of a team coach (a team leader or any other role that is supposed to help the team to grow) without taking into account the inherited team's dynamics and variability won't be beneficial in the long-run. Because if something is stable about teams - it is how unstable there are.
Over several years of team coaching (as an in-house scrum master and a visiting agile coach) I've come to realize a model that seems to be less wrong than anything else I'd known before. I didn't invent it. This is an attempt of externalizing my personal gut feeling of "what's right" when I'm meeting and working with (agile) teams.
It is an attempt to explain (first of all to myself) what I know about working with teams and people systems.
To cut it short, whenever I work as a team coach I tend to engage in one of these at a time:
The model is not linear. So in real life I might jump several steps ahead or go back depending on team's reaction to my interventions. Still it helps to explain the "steps" as if they were sequential.
That's it. Five steps. Five coaching hats. The hardest thing of course is to know when to wear which (and when not).
Below is my current understanding of this.
This one is called Sprint Timeline helps individuals refresh their memories and build a collective story of the sprint.
Use a masking tape depicting a timeline. Couple of meters is a good size for a two-week sprint.
Then ask everyone to write silently for few minutes on post-its: I ask to think of the events that happened within the sprint and are important to be remembered. Anything goes here: parties, sick leaves, releases, meetings, conflicts, surprises. One event per a post-it.
After writing is done, ask people to come up one by one and tell their stories by sticking their post-its chronologically. You may want to limit time per person. Say to 1 or 2 minutes.
Additionally, ask people to draw smileys on the post-its represent- ing the emotional state of the events.
That also works great for longer time-slices, like for instance quarterly releases. Actually, the longer the period being retrospected, the better this tool works.
Once the collective memory is there it is so much easier to get a deeper dive into specifics of the previous sprint with activities like Sprint Perfection Game, Working Well - Needs Fixing or More-Less-Keep-Stop-Start.
See the the Retrospective Cheat Sheet for more details on these exercises.
Let's look together at the following photos.
Below you can see what's called SAFe Program Boards - an artefact (output) of a PI Planning meeting in SAFe.
I like the photos and the level of visualization. I think it is in general a great idea to visualize cross-team dependencies. And it is not a trivial job to do!
Goal: helps release a heavy emotional steam and get mentally ready for the meeting.
Being mad, sad, glad, or afraid are the essential, fundamentals emotions we all share. Our feelings can seen as cocktails made out of these four simple ingredients. So teaching your team to share their feelings by using these four emotions is a lesson of mindfulness and self-awareness.
How to run this exercise? Simply write these four emotions on a flip-chart or a white board and ask everyone share what’s on their mind using any combinations of these four elementary emotions. People share in a round-robin manner: one by one. No discussions or comments allowed at this point.
Some people will just say few words, while the others... well if you're lucky this exercise helps people speak up of something unspoken yet deeply present.
But in some occasions, when we all know something serious has happened by no one is speaking about this aloud, this activity can be a real saver. As it helps people unload their mental weight by associating with and then speaking their feelings.
Like in the situations when there is a big smelly elephant has shitted in the room, when something had happened that is on everyone’s mind, but no one speaks about, like: a very bad customer review, an co-worker has just announced she is leaving the company, our company got acquired by Microsoft (no f**ing way!), or the sprint was very special in some other unusual ways...
I do this exercise every time I sense the team got distracted from our product and teamwork. Usually by something external and uncontrolled.
This exercise, if taken seriously, creates a very deep impact on the atmosphere and opens up the space in the retrospective for deeper thoughtful conversations.
The original instructions of the protocol guides everyone to say "you're welcome" after each person's done sharing. This ritual creates a little ceremony and welcomes people, regardless of what they feel and think. If this sounds too weird for your team, leave it out or create your own little ceremony fitting the team's culture.
Once the team has "checked in" you as a retrospective facilitator can move onto the context of the recent sprint and focus on process improvements with activities like: Constellations, One Word Retrospective, Last Retro Follow-up or Sprint Timeline.
See the the Retrospective Cheat Sheet for more details on these exercises.
Below is one of the exercises I usually start a retrospective with. Why? Because it is very simple yet powerful. You have your participants joined the meeting, so physically they are present. But how mindful are they? It usually takes a while to "arrive" mentally to a meeting after your body takes a seat.
So this activity is designed to help participants start building a connection of how they feel about the last sprint. That's the main purpose of this activity. And it is a called a "one word" because you're asking for a quick association - ideally just one word by asking "which was the weather like for you in the sprint?"
A secondary and less obvious purpose of this activity is to give everyone a chance to speak. The earlier you do this on a meeting (any meeting not just a retrospective), the more engagement you can expect from your participants to be. Asking everyone to say one word at the very beginning of a meetings sends a very strong message to everyone: you are invited here to talk and share what's on your mind, you opinion is very important, active participation is what we are looking for here.
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.
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:
A great talk by Eric Ries on Lean Startup and intrapreneurship.
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).
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.
"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:
"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.
Sign up for the newsletter.
No spam. Only relevant agile news and updates from Alexey Krivitsky.
(C) 2015-2016, agiletrainings.eu