Scaling is a hot topic. New frameworks and certifications are emerging like mushrooms. But without understanding the deep system dynamics of your organization any scaling framework would be just a patch on the skin of your organization. In this talk, we’ll review the reasons why each company tends to grow, to become slower, and more bureaucratic.

Communities of Practice (or 'CoP') is a hot term these days.

We've (a small group of agile coaches, managers and software developers) have spent three days trying to clarify for ourselves what those actually are.

The key questions we had:

• Why do things like CoP emerge in organizations?
• Why some of them are dead-born and produce close to zero value?
• While the others fructify and generate immense value?
• Do communities need leaders? What is the role of upper management in their creation?
• What are some common tips&tricks and anti-patters?
• What else does a potential community creator need to think of before creating one?

I was presenting this workshop in Vilnius on May 2017.

The main line of thoughts:

• we use the word "culture" to explain when things don't work (and work)
• when the companies are young (start-ups) culture (beliefs and habits of the founders) shape the emergent structure
• once the companies get stable, the structure starts to sustain itself
• hence in a stable company, structures are shaping the cultures
• Larman's law calls it "culture follows structure"

Then we review the some sample structure decisions that affect culture in different ways:

• component teams
• platforms teams
• lack of team skills
• product management 'divide and concur' 

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:

• Agile Latvia: 7-8 July
• Agile Prague: 11-12 Sep
• LeSS Conference London: 13-14 Sep
• Scrum Gathering Dublib: 30 Oct - 1 Nov
• XP Days Benelux: 30 Nov - 1 Dec

The Agile Coach Competency Framework teaches us that there are four competencies in a toolset of an Agile Coach:

1. facilitation
2. professional coaching
3. teaching
4. and mentoring

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:

1. Enacting Scrum Process
   Being able to know Scrum, teach Scrum, guide the teams in using Scrum and the ideas of empirical product development.
2. Facilitating Team Meetings
   ScrumMaster is not the only meeting facilitator (otherwise - a bottleneck) but a default one. Helping people to have meaningful discussions on time and enriching their collaboration styles is vital if you'd like to have a shared understanding of the work among the team members and outside.
3. Holding Retrospectives
   If there is one the most important meeting a Scrum team has - it is a Sprint Retrospective. That fact that there are books written on this meeting proves the point. And why? Because Scrum is a process that helps design a process. It is a meta-process, if you will. So without constant inspection and adaption of the existing process a team will stuck in the status quo of mediocracy. 
4. Coaching Big Picture
   It is so easy for a development team to get lost in all those Scrum ceremonies, artefacts, roles, impediments - also still hopefully finding the time to get a working product out of the door. So with a help of a ScrumMaster, the product management team with a representative as a Product Owner needs to spend time clarifying and sharing the bigger picture with everyone doing the work. Remember, that knowing the purpose of the work is one of the few intrinsic motivators we as human beings share.
5. Coaching Product Value
   "If you don't know which product to build, with Scrum you'll be doing it just faster". So a good ScrumMaster spends time coaching and mentoring the Product Owner (and the product management team) to master Lean Startup, Lean UX, Customer Development thinking tools. This requires that a ScrumMaster has actually mastered these tools herself.
6. Coaching Team Members
   Not all issues can be solved on the Daily Scrums and Retrospectives. Not all things need to be discussed in big rounds (sadly, I've learned this too late). Individual coaching (e.g the co-active coaching model) is yet another vital skill to master. Otherwise when talking to us the team will be limited just by our mental capacity, not their potential. 
7. Amplifying Learning
   Our goal is not just to create a happy team, a great product and a sustainable process. In fact we are there for something bigger - to create a learning organization. This implies working with everyone in the company. Go out of your team, your product, your room...
8. Changing Environment
   "Change the company or ... change the company" as some people say. Scrum is just a bunch of feedback cycles put wisely together so that we clearly see how inefficient we are. If we don't get this feedback serious - we are not going to make our companies better.
9. Navigating Conflicts
   Scrum makes people talk. And if you do your job right you will situations when co-workers are talking with each other for the first time ever. And what happens when they do? They share their thoughts, fears, hopes. Of course we all live on our own realities so it is expected that our thoughts will differ. Differences create tensions. And tensions if not handled in time foster conflicts. Good healthy conflicts are in fact required in a creative environment. But we don't want nuclear wars in a team. Just refreshing healthy constructive conflicts. 
10. Mirroring and Driving Growth
    We as ScrumMasters are holding a mirror for the teams and organizations to see themselves. This implies having tools that help to reflect: team health checks, miscellaneous agility assessments, etc. - are all good means here. Transparency on the current level of maturity creates awareness. Awareness creates desire to change. Growth is happening daily and on different levels. That's why we are there. To notice it, reflect on it and celebrate it with everyone.

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:

• Meeting the team where it is.
• Revealing the team to itself.
• Raising the team above the sea.
• Getting the team's targets clear.
• Letting the team lead.

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.

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.

This is the well-known check-in exercise from the Core Protocols by McCarthy's and the book Software for Your Head.

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"

Ron Jeffries.

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).

• How organizations develop?
• Why are they tend to become so complex?
• Are managers coming from Mars?
• What are the three types of managers?
• How the bands like the Beatles are managed?
• And how does it all related to the self-management concepts of Agile?