A letter to Scrum Masters

Dear Scrum Master!

Being a Professional Scrum Trainer, agile coach & consultant for a while I had a chance to work with around a thousand Scrum Masters across different organizations. I see recurring patterns of misunderstanding and misapplication of Scrum usually visible in how Scrum Masters act. Based on that experience I want to share a couple of important points with you in hope that you will seriously consider them in your work.

1. You are not a boss. Repeat: you are not a manager. Repeat: you are not a foreman.

Specifically you are not responsible for making sure the team delivers everything that was planned during the Sprint Planning. You are not responsible for gathering reports and coordinating work to meet deadlines. You are not responsible for ensuring everyone chimes in, so you are not responsible for checking if people are working hard enough nor handling laggards. You are not responsible for distributing work nor ensuring it is distributed fairly and in a way that makes best use of the talents and skills of your team.

Your responsibility is nurturing, creating a team that would care for most of the above and more. This is a huge difference.

A good analogy is that of a sports coach. During a match all a coach can do is watch from the bench. He is responsible for creating a team that will play the game, not directing each and every player once the game starts. In the end it is the team that is responsible for winning, not the coach.

2. None of the meetings in Scrum is for you. You are not supposed to be the center of attention on any one of them.

Specifically, the Daily Scrum is not a reporting session, if you stand in the center and everyone else looks at you as they talk you’re doing it wrong. Also, the Sprint Review is not about showing team statistics and burndown charts. It is about showing a working product to the clients. Did I mention you’re not supposed to be the center of attention? That also applies to the Sprint Review, you shouldn’t be the one doing most of the talking — at best you should be the one doing the minimal moderation (that is keeping the meeting focused and effective) while the Product Owner and the team host the stakeholders, present their work and gather feedback.

If in doubt what Daily Scrum or Sprint Reviews are for re-read the Scrum Guide or attend a training led by a qualified, experienced trainer from a reputable Scrum organization (as of now this means Scrum.org or Scrum Alliance).

3. You are also not a “Scrum secretary”.

The fact that the team “does Scrum” and you have been elected/nominated/duped into being its Scrum Master doesn’t automatically mean that you should draw burndowns, move cards around on the board and keep other “Scrum artifacts” up to date. You may choose to do some or all of those things for a while, especially with a new, inexperienced team, but never ever allow the team to think this is your job as a Scrum Master.

Doing that might give them the false idea that all those artifacts are for you — or the process, the management etc. — while in fact they are all for them, the team sprinting to reach the Sprint Goal. You are there to help them realize that.

4. You are also not a technical leader. Nor an architect.

You might be a brilliant programmer with lots of experience on the product, but being a Scrum Master doesn’t give you any authority to decide how the product is going to be designed & built. Specifically, as a Scrum Master it is not your duty to do code reviews or (worse) approve code or designs, answer technical questions or make any technical decisions. Doing so would bring you very close to becoming a traditional lead programmer or technical lead and thus would prevent the team from healthy self-organization.

Yes, Scrum allows a person to be a Scrum Master and a developer at the same time in the same team. If that is the case you will have to carefully balance those two roles and make it absolutely clear to everyone and in every interaction whether you speak & act as the team’s Scrum Master or as one of the developers. This might turn out to be trickier than it seems on the surface. It may sometimes work, but in most cases the burden is too much for one person which is why it is not the encouraged model.

Sadly, many organizations have even made it into a standard thus in most cases denying themselves full benefits well functioning Scrum teams could have given them.

5. You are not the team’s spokesperson. Nor an information relay for the team.

As it was pointed out above the Scrum Master is coaching the team, protecting the team, nurturing the team and pushing it gently towards working better and smarter — but is not replacing the team in actually doing the work. Contrary to what some may think a development team’s work does not consist of just typing code into computers while drinking caffeine-rich drinks. It also involves communicating (preferably face to face) with others — teammates, other teams, the Product Owner, stakeholders, clients, users etc. — to first understand what and how to put into code. Very often when analyzing why things went wrong we discover it was because some people didn’t talk, didn’t communicate fast and early enough opting for sending an e-mail then forgetting about it or — worse — assumed this or that was ‘obvious’ and just went ahead based on that unfounded assumption.

Because communication is so important for the art of developing software in teams as a Scrum Master you should care about it. This means you should monitor this communication to make sure there is enough of it, encourage it (in most cases just reminding developers it is better to call or walk over and have a chat rather than typing an e-mail is sufficient) at the same time ensuring that the process is not ‘leaking’ (for example no new work is being pushed into the team outside of the Product Backlog and PO’s knowledge). However, it is the team’s responsibility to communicate — it is them communicating, not you. Therefore you should never ever step in to act as a relay.

So, if everyone who wants to get some information to or out of the team comes to talk to you, the Scrum Master, you’re doing it wrong. Get out of the way before too much harm is done.


There are of course other misunderstandings and dysfunctions, but the ones above are by far the most common. If any of the points above is not obvious for you please do rethink whether your stance as a Scrum Master — or what is considered standard in your organization — is indeed beneficial and in line with what Scrum calls for. In other words whether you are a Scrum Master — or is it just a title you have in your e-mail signature.

Your truly,
Andy Brandt

Startup development offshoring/outsourcing - a research

You may be wondering why am I interested in startup offshoring/outsourcing to CEE? Let me explain.

For the large part of my professional life so far I was involved in startups. One of those startups is Code Sprinters, a company I did start in 2007 that is now the leading provider of training, consulting and coaching in Agile, Lean and modern software development methods in Poland.

But Code Sprinters started as a software company, an outsourced software development  company. Most of our clients were startups and we have been building the core of their products for them.

We don't do it anymore - we stopped in 2010 as the training business grew and become our main focus. But there were other companies at the time in Krakow that were doing the same thing - outsourced development for startups.  Some of them exist to this day and new ones have been opened since.

Same thing is happening in other countries through CEE. And besides smaller and larger companies there are also freelancers selling their services through Odesk or Elance and others. Some of them even band together into virtual teams. Some startups decided to actually open offices and hire their own staff somewhere in Easter Europe.

Recently I have been again active in the startup industry, though in a different capacity. As I'm now meeting startup founders I find many of them consider outsourcing or offshoring their development to Poland or other CEE countries.  I sometimes give advice or even coach them on how to approach this, since I have been on the 'other side' for a couple of years. However, I do realize my experience is limited to my own point of view - projects I have been part of, startups I know personally well enough.   

So I thought it would be interesting to learn more about this specific phenomenon of startup offshoring/outsourcing to CEE. However, there are very few sources that would concentrate on this phenomenon, hence the idea to create a survey and get some more insights. 

So - if you are an owner/founder/manager of a startup that outsourced its development to CEE would you please fill in my simple survey and in this way help me to give better advice to those who now consider doing it?

Thank you in advance! 

Be careful with models

It is important to understand that a model is not the reality. It is rather - by definition - a scaled down and simplified version of the reality it represents. Models are useful, because reality is too complex for us to comprehend it directly. Simplification – limiting the number of variables and cause-effect chains – helps our understanding. But we should be aware that models – no matter how beautiful and enticing – are not reality.

Why I take your precious time to state something so obvious? Especially on a blog about leadership?

I think it is important, because all methods, practices and methodologies that you encounter are based on models. PMBOK, PRINCE-2, Scrum, ITIL etc. are all built on top of a model. It is a model of a project or a software development team or an IT organization respectively - but it is still just a model. When applying this or that framework – or just evaluating it – it is a good idea to consider how well the model it is based on applies to your reality. Chances are even if it very closely resembles your situation there are some differences – and this means in the end you will have to find your own solution, your own version and your own model. Frameworks etc. can help you, but most probably you will have to adjust them. It is therefore, I think, a good idea to look at them primarily as a source of inspiration rather than ready-to-use recipes.

Complex frameworks and methodologies are usually modular by design, as their creators understood not every element will be applicable in all real life situations. Small and simple methods don’t’ usually leave much room for adjustment, they have to be applied as a whole and then maybe will evolved into something slightly different in your particular environment.

Being aware of the above is – I think – important because in the enthusiasm following discovering ‘new, super model that solves all the problems’ this is frequently overlooked. Thinking the new paradigm or methodology leaders just rush to “implement” them in their organizations – instead of thinking first if and where a given method might be helpful.


Three things you can do today to be a better leader

You are a manager, a team lead or in other leadership position and you want to be a better leader? Here are three things you can do to improve your leadership.

Get out of your office

If by any chance your current position came with a private office get out of it. If only you can get rid of it completely. Instead, become a nomad sitting every day somewhere else in the office amongst your people.

You will achieve two major things:

  • You will know better how things really are in your group/department/company. You will be able to smell the air and hear the noise. You will see how people go about the business. You will start to know them. And they will start to know you. Your private office - as nice as it is to have one - only separates you from your people, forces you to view them through reports, spreadsheets and formal meetings. That alienates you from them.
  • People will get used to your presence. Of course, it will be some time before they get over their initial surprise. At first this will be a novelty, they may feel observed and maybe even intimidated. However, as you will keep being somewhere there in the office every day it will become the norm. And people will get used to you being part of the team in a perceptible way.

Of course, you will need some quiet time away from others. But hey - *everyone* needs it. Just remember your first job is people - not reports, not spreadsheets, not e-mail - people.

If you want to think alone and not be disturbed reserve a meeting room. Or go outside altogether, have a walk, a coffee or a drive in your car - whatever helps you reflect & think. And when you will want to have a word with someone in private you still have meetings room for this.

Vow not to call employees "resources" ever again

You surely know the term "Human Resources". You may even use it. I often meet managers who say things like "I don't have enough resources" or "I have a resource for this project". The problem with this term is that it is wrong and damaging.

It is wrong on two levels. First, it is ethically wrong. It verbally reduces a fellow human being to the level of machinery or production materials. He or she is no longer a person, but rather a resources to be acquired, used according to its characteristics and discarded once no longer needed or damaged. What kind of relationships are being built by seeing other people like this? Would you like to be treated as a "resource"?

But apart from being morally wrong it is also simply untrue. People are not machines. They can't be described by a set of numerical parameters, they performance - especially in knowledge work - can't be measured with objective metrics and most certainly they don't relate to other people like machines. You can take choose a bunch of machines based on their parameters then connect them on a factory floor and you will get a working production line. You can't do the same with people. People are complex and their group are even more complex because of the added layer of relationships. To make it even more difficult people change and groups also change. If you are supposed to manage a group of people you are not helping yourself by using the "human resources" paradigm.

I believe this simple term and its widespread use has caused more damage in the world - and certainly in our industry - than most "methodologies" we are now discarding as obsolete. Some may say it is just words. Words, however, shape how we think and our thoughts are a lens through which we see the world. We should be careful not to allow our lenses to smeared with falsehoods. It is about time to discard this one.

And guess what? You can do it yourself and see how it works from you. Make a conscious decision you won't use this term for the next 30 days and then check how that influenced your thinking.

Take the "Happy at Work" test

Ever heard of "Happy at Work" twelve question test? Here it is. First, answer in your mind YES or NO as you read the questions below.

  1. Do I know what is expected of me at work?
  2. Do I have the materials and equipment I need to do my work right?
  3. At work, do I have the opportunity to do what I do best every day?
  4. In the last seven days, have I received recognition or praise for doing good work?
  5. Does my supervisor, or someone at work, seem to care about me as a person?
  6. Is there someone at work who encourages my development?
  7. At work, do my opinions seem to count?
  8. Does the mission/purpose of my company make me feel my job is important?
  9. Are my co-workers committed to doing quality work?
  10. Do I have a best friend at work?
  11. In the last six months, has someone at work talked to me about my progress?
  12. This last year, have I had opportunities at work to learn and grow?

Then think how would your employees, your team answer those questions. Doing a survey would take time - a mental exercise is something you can do right now. Write down the prevalent answers you expect.

Made popular by the "First, Break All the Rules: What the World's Greatest Managers Do Differently" book this test is based on extensive, worldwide research of employee wellbeing made by Gallup. They found that people need to be able to respond "YES" to all of the questions above to be happy at work.

Look again at your own result and what you think your people would say. Then think of ways in which you could improve. Organize a quick survey to know the actual answers (this tool is great for this). Compare the results with the results of your mental exercise. Then try to come up with at least two concrete actions you would take over the next month to improve your team's results. Rinse & repeat.

If you wonder why should you care if people you manage are happy at work or not ("they should just get a grip and do what they are paid for") then you are probably reading a wrong blog. You may have a look at this post on your way out.

Still reading this? Good.

The three things above are not quick fixes. Only applying them over time will bring results. Embracing them works because it changes the way in which you perceive your role as a leader. There is a bit more to each of them and I will probably write about them in the future.

For now I ask you to carefully consider them and try at least one starting today. Let me know how it worked for you.

The Business Manifesto

The Agile Manifesto has spawned a whole slew of methods & practices that took the IT industry by storm. We have a second wave of change coming close on agile's heels - the New Wave of Management inspired by thinkers like Jurgen Appelo and Steve Denning. Numerous trainers, coaches and "gurus" talk about such things as empiricism, psychology of motivation, employee empowerment, flat org structures etc. Seldom, however, I did see one element addressed which I think is crucial: all that is first and foremost good for business.

To re-iterate what business is all about let me propose a "business manifesto", which really boils down to one point:

"In business profit is the primary measure of success."

That is, while other things are very important in the end a business must generate profit in order to stay afloat - let alone be successful.

To be well understood: this is not to say that I endorse unbounded greed and doing anything for the money (as banks & hedge funds did recently almost killing the whole Western economy). A good company - one that I would care to work for - must have some higher goal to attract talent, clients and harbor a healthy culture. However, even in pursuit of that higher goal it must maintain a positive positive cash flow. Otherwise it won't be able to pay its bills and instead of "putting a dent in the universe" it will just create a huge hole in its owners pockets. And it must generate a profit to even call it a business (as opposed to a charity, a non-profit society, a church - or any other form of organized human activity that is not profit-oriented and hence not a business).

A good, pragmatic leader understands this and is not only about a vision, a higher goal for his company but also carefully checks financial data and makes sure his company stays afloat to realize said goal.

All of this is completely obvious for anyone who ever tried to run a business, especially one founded with his own money. Why then I think it worthy to remind my (few) readers about this obviousness? Because I feel many in the agile world seem to forget about it. Somehow it feels bad to say that besides all the great things new methods bring for the employees they first and foremost boost business.

Understanding and preaching this message is, I think, key to convincing managers (especially executives) that agile methods & new wave management are not a danger but an opportunity.