The IOWA-Number - a tool for team building

Not every person contributes equal amounts on the team, and that's often okay. But there are some cases, where a conversation is needed. I devised the IOWA Number as a tool to identify these cases.

Applying the tool

The IOWA Number can be used in the "Gather Data" stage of a Retrospective with the question: "How do you feel about your team members?" This does require a certain level of trust within the team to work properly, and be clear that the tool isn't meant to highlight people as problems, but much rather to help the team find itself properly. There is no score that's inherently good or bad, just some scores that will lead to further conversation down the road.
Most importantly, only apply the tool when you have a feeling that there are some outliers, as the tool is merely intended to open up a conversation on becoming better at collaborating!

Extremely low scores

In some, rare cases the team will feel that a person's absence will actually have a positive effect on outcome.
The most notable case of this happening is usually when said person is lacking so much knowledge that their questions disrupt the others' flow of work. A good way to strengthen the team would be to put delivery work a bit on the backburner and work intensely to bring the person back to speed.
Another common case would be that said person doesn't really understand the impact of their own way of working on the team, often due to being unfamiliar with others' self-organized ways of working.

In any case, team members with extremely low IOWA score need the team's support to rise to higher levels and the team should have an open conversation which behaviours are reducing IOWA score and which behaviours would increase it.

Moderate scores

Anything between 3 and 7 is usual. There's not much to discuss, unless there are tendencies towards an extreme. But since IOWA numbers are nothing more than a snapshot in time, it would be better to use the extreme value right away, as it doesn't make sense to defer a conversation.

Extremely high scores

There's no way to sugar-coat it, high IOWA scores are a risk, potentially even a threat to the team's sustainability!
People typically do not choose to have high IOWA score, they receive that score because they have superior understanding of a subject matter and a strong drive for action. Usually, they feel they are helping the team and the organization by working this way, and in fact - when it comes to getting stuff done, they help a lot.
Unfortunately, all of their help us unsustainable, as the team immediately falters when they aren't available and if for some reason, they should be out (e.g. sickness, family issues etc.) their absence could bring the entire team and whatever the team was working on to a standstill or collapse.

As I wrote in my book, "Extreme Agility", my suggested course of action would be to relieve the person from the responsibility of doing whatever they do so well and instead coach and support the rest of the team in this. It should be exceedingly clear that they aren't taken out of the delivering function because anything is wrong with them, but because they are needed as multiplicators in order to grow the team.

Conclusion

IOWA Numbers are a conversation starter when the team is on uneven footing. It's not intended to judge or condemn the work or contribution of any individual, much rather it is intended to bring people to a more equal footing in order to increase the team's sustainability.

In some cases, it may even be worthwhile to create IOWA Numbers for people in the team's close vicintity, such as traditional line managers. If this is done, be sure to include them in the Retrospective (which is rather unusual).

Continuous Deployment - more than a toolchain

A while ago, a prospective client approached me, "We've purchased a Continuous Deployment Toolchain, now we need someone to do the training." I was invited to meet the Head of Administration and an Admin team lead. 

Story Time.

Paying for vaporware

"Here is the toolchain we bought. We paid a six-figure amount for the strategy and a five-digit sum for the implementation. Now we need someone to train our Admins so that we can roll out the new process for all of our 500+ projects in the next Quarter."

I glanced at the Powerpoint slide.

If you think this is worth $100k, well ... I have a bridge to sell.

It's about culture!

I started asking: "Why the Admins? Wouldn't you much rather want to train the developers?"
I learned that this project was spearheaded by the Head of Administration and they didn't want the Head of Development to take credit for their idea. Plus, the introduction of Continuous Deployment (CD) was mainly supposed to relieve the efforts of the Admins.
Taking note, I asked: "So how did you come about this project in the first place?" In painstaking detail, the Admin team lead explained that the process of getting a release through the door often took months - and CD, automating the entire ordeal, would cut it down to minutes and free their time for much more important things.
Nodding, I probed: "So, the developers will check the code into git?" - "At the moment, they either send us the code via email or put it onto a Shared Folder." Remember - this was a good decade into the 21st century! "And then?" - "We manually compile the sources. In some cases, we've created some scripts to ease the job, but those scripts are brittle and fail with every new release." - "Have you considered giving the job of creating maven builds to the developers?" - "That's not their responsibility. We can't guarantee for the correct installation of the software any more if we let them do it."

Next icon. "What's Sonar supposed to do in this construct?" - "Check the code quality." - "Do you have code conventions or unit tests?" - "Neither." - "And who is going to do that job?" - "That would be the Offshore Testing Department."

This was getting more intriguing by the minute. "Are the Developers trained in the use of Ansible and Docker?" Shaking heads, "We will provide standard scripts and containers for others to use." Probing deeper, "How do you know which Ansible Configurations and Docker Images will be needed?" - "We will just create those which replicate our current environments." - "Are your Admins trained with either tool?". A smile, they figured that finally, I was coming to understand them: "That's why we need you."

"Just one last question, how are the tests going to execute?" - "If you look closely, after a Docker Container is created, it will automatically be deployed to the Test Stage for Manual Testing."


This was going to be an interesting ordeal.

Get ready for Continuous Deployment!

I devised a strategy and proposed the following approach:

1. Basic Leadership training for beginning agile transformations
2. Process Redesign Workshop to reconsider the current build process and responsibilities
3. Start a Cross-Functional Team from across all departments to integrate the CD pipeline on one project in the next quarter.
4. Coach this team in fundamental Software Craftsmanship - including Pairing, Test Automation and CI.
5. Use the pilot team to set up meaningful quality metrics and create a working build pipeline.
6. Involve others in the learning and gradually move towards cross-functional teams with e2e responsibility.

I was informed that my offer was probably a misunderstanding. I replied, politely, "If you ever choose to look deeper into this offer, feel free to reach out." They never did.

tl;dr:
The toolchain is irrelevant until you have the culture and structure in place. CD isn't something that a single department in a silo organization can do all by themselves. Instead of architecting the entire pipeline upfront, experiment, discover what works - what helps - and what is actually being used!

If you seriously intend to move towards CD, the long journey and steep learning curve really pay off once the peak is climbed.
One disclaimer, though: There's no guarantee that you can keep any of your current processes, structures and mindset.

Five signs you've got the wrong agile coach

You've set out to begin your organization's "Agile Transformation" and, lacking the expertise, you've brought in external consultants and/or coaches to make the endeavour successful. But since you're not agile yet, how do you know whether you have the right people on board?
Here are a few pointers that will help you identify rotten eggs - i.e. you can be almost certain that after the consultants leave, the show will be over, and best case you've only wasted money for nothing.

#1 - Lack of Battle Scars

Having the seniority to assist another organization in their agile transformation, the coach should have a lot of war stories to tell. Stories of experiments, pitfalls, troubles, joyful moments and cheerful victories. Stories of what they have experienced firsthand (not hearsay!).
What people tried, what they set out and where they landed - the differences between intent and destination, the obstacles and dangers on the journey - the small nudges that made the difference and so on.

If you see that the coach either has little to say from personal experience or is only quoting others ("double-hearsay"), beware!

#2 - A shelf full of solutions

It doesn't matter what your problem is, they already have the bottled solution ready! Just follow their advice, and you will become Agile. NOT!

Especially when they promote solutions as a silver bullet, i.e. universally applicable without concerns for context - you're in for trouble.

#3 - Change without change

Following pre-concocted agendas, outlining the change on fancy slide decks without ever talking to the people doing the actual work or knowing the real struggles they have isn't going to work.
The first three questions I would expect to ask: "Why would you want to become Agile?", "What will be different in a year?" and "What have you tried so far?".
If there are no comprehensible answers to these three questions: what exactly do you expect as a result?

#4 - Not rocking the boat

Many experienced consultants have learned to avoid challenging status quo and messing with people in positions of power. This is a great approach to maximize the amount of billable hours and to please those who decide whether their contract will be renewed.
As attributed to Einstein, "Problems can not be solved with the same mindset that created them.", it's essential to rock the boat - to identify and tell people about the root cause assumptions which lead to the problems that an agile transformation is supposed to solve. And if key decision makers aren't aware how they are contributing to the problem - how would they know what they must change to solve it?

Consultants who only compliments senior management aren't going to make an impact.

#5 - We've got this!

Probably the killer criterion for spotting fake coaches: They can do it by themselves! They have so much experience and expertise that whatever is brought to them, they have the right answer. Senior management doesn't need to involve at all, because the coach knows how to handle everything. Teams don't need to worry, because the coach will teach them everything they need to know.

The coach who offers the solution without teaching you how to find your own solution - doesn't help you learn, and if you don't become a learning organization, you're not going to be agile.

Conclusion

I would like to conclude with my favorite TheraminTrees quote, "People who don't want you to think are never your friends!"

A "coach" who doesn't make you think and challenge how you think - is the wrong coach.


Sour aftertaste? 
Let's fix this: Here are ten signs you might just have found the right coach!

Eight character traits of good leaders

Many people like to be in a position of leadership - without ever considering what makes the character of a leader. In this article, I propose a list of eight character traits portraying good leaders, regardless of position, rank or role.

"Leadership" - image courtesy of @danielmassoud4 taken from twenty20.com

Earnest

We acknowledge and respect people who walk the talk, who do what they say, who have and convey a clear purpose and work towards that purpose themselves.
Nobody would waste time with a hypocrite or someone who themselves doesn't know what they want or where they are headed. Good leaders spend a great deal of time considering what they want to accomplish and why - and their very being encourages others to join in.

Diligent

We natually have a tendency to commend diligent people. Those who are pay the necessary attention to detail while still having a clear direction tend to be successful and a pattern for those around them.
It's often the small things that become the downfall of people in position in power - so great leaders take care not to get stumbled over small rocks.

Perseverant

People who are willing to go the extra mile for what they believe in serve as positive examples. Few can shrug off a setback and march forward with unwavering zeal - so those who do will eventually rake in successes that are the result of harsh failure learning. Like this, they become exemplary even to those who never knew about the troubles along the road.

Bold

When you firmly believe in what you do, you're unashamed and unafraid to act and speak. Even when we disagree, we still notice and acknowledge those who are bold to take a step, expose themselves and their ideas to a broader audience and are willing to take the heat and fire of criticism and resistance.

Altruistic

People look for those that do something for everyone, maybe even for others. On the other hand, we disdain those who selfishly try to fill their own coffers and get out of the line of fire. Because of this, we admire those all the more who put themselves out of the center of attention and put the social benefit of their ideas and goals first.

Considerate

Everyone has different needs and different perspectives. We like to be accepted where we are and how we are. While bad leaders express ruthlessness and recklessness, good leaders spend time to accomodate those around them, making them feel welcome and cherished. Being social creatures, we tend to flock around those who make us feel comfortable.

Thoughtful

"Measure twice, cut once" - when dealing with people, we often don't get a second chance, so it's best to spend time pondering how we and our actions affect those around us. We need to be watchful what we say and do - a single careless word can burn bridges. On the other hand, a nice word creates a positive atmosphere, a little support in times of need builds bridges and by moving from basic courtesy to full acknowledgement of others' circumstances, we become people who others enjoy being around.

Progressive

"We all are where we are" - yet, that's no reason to stay put. Nobody is perfect, but we need to move on. Commendable leaders aren't only good at being who they are, they're continuously improving upon themselves. That character quirk we noticed yesterday is a great opportunity to reflect on how we want to be - and what we can do to be even better people today. By not being stuck either with themselves, their ideas or the world around them, the best leaders continuously adapt themselves, their ideas and their environment to move forward.

Summary

Leadership isn't about position. It's about who you are - and no classroom training can make you a leader. Only you yourself can do that, and you must work on your character in order to be one. This is not a one-time act, it's a lifelong process: The day you stop working on your character is the day you have stopped leading.

What is a Scrum Master?

The question, "What is a Scrum Master?" may sound easy to answer - RTFM, the Scrum Guide has a very concise section. But when looking at what a Scrum Master really does, it becomes a profound topic in and of itself.

The narrow definition

The most narrow definition is that it's the one person on a single Scrum team making sure the Scrum Guide is being followed and the team successfully delivers on their Sprint Plan. Most people work in organizations that think of this narrow definition and also behave likewise.

For people looking to move into such a role, the best starting point is reading the Scrum Guide, getting a few books (such as Geoff Watts: Scrum Mastery) and a certificate or two (PSM-I from scrum.org or CSM from Scrum Alliance come to mind) then start job hunting and learning on the job.
Sticking with the narrow definition is not a very fulfilling job, as systemic impediments never get addressed.

The broad definition

The most broad definition is that it's a person coaching an organization on becoming more agile, challenging existing paradigms and opening the way to more flexibility, and this means individuals, teams and managers on every level - from intern all the way to senior executive.

People

When it comes to being a Scrum Master in a broader sense, then Scrum is maybe 5% of the picture. In fact, Scrum itself will become less and less important and - just like the Agile Manifesto states - people and their interactions will become prevalent.

Agile Frameworks

The first thing you will need to explore is the other agile frameworks, starting with the team-level ones such as Extreme Programming and Kanban - and getting yourself familiar with the organization-level ones such as SAFe (Scaled Agile Framework), Nexus, LeSS (Large-Scale Scrum), DAD (Disciplined Agile) and S@S (Scrum at Scale). Of course, that doesn't mean you will be using all of these - but you should have a sufficient understanding to comprehend where they are useful and what their limitations are.

Management

Having a bag of agile theory under your belt, you need to move into organizational design and management by reading publications from authors like Drucker, Deming, Crosby, Taguchi, Taylor etc - and learning to compare and recognize their models.

Psychology

You will also want to explore the field of psychology to understand how and why people tick the way they do. That's a vast field, where you might want to reach into behaviouristics and conditioning (Pavlov, Skinner), emotions (Ekman), basic needs (Maslov), negotiation models (Ury), transaction models (Berne), habits (Duhigg) and many others.

Philosophy

To round this off, you may want to gain a deeper understanding of philosophy, which also has a lot to offer, with the most notable things you may want to get being logic (assumptions, fallacies, mental models), axiology and epistymology.

Economics

As the subject of how wealth works - i.e., how value is created, consumed and transferred, there's a strong correlation towards making a company successful: you have to learn how decisions are made, why agents interact the way they do, and what are the driving forces of an economy (both local and global.)

It's not very useful to do all of this upfront, but continuing to learn while you're on the job and working to continuously increase your sphere of influence within the organization.

Summary

The Scrum Master is a very deep role which, when taken with a deep, serious learning attitude, has a lot to offer and provides a tremendous field for growth. If you put your heart into it, you will reach tremendous awareness of and influence on your surroundings.
Don't let people tell you that a Scrum Master is "just a team role". Great Scrum Masters can make a massive impact on their organizations.