The Ultimate Patch


Recently a company called Blue Prism and their product were brought to my attention. You can’t easily tell it from their website, but what they offer is basically an intelligent integration of systems… through their UIs. In other words, their software links systems by interacting with them as a human user would – clicking icons, typing commands & screen scraping the output then pasting it into another system (maybe after some internal processing). They say they noticed, that companies frequently use people (probably for the most part people in “offshoring centers” in poor countries) to link systems together into business processes, because… changing those systems and linking them properly is too hard, takes too much time and is too costly.

Not to criticize the clever guys at Blue Prism, but this is how the failure of our profession looks like. The Blue Prism product it the ultimate patch, the ultimate hack on business systems that are overdesigned, poorly built, laden with technical debt and maintained by dysfunctional, badly managed IT departments. It is sold to frustrated business that wants changes to react to the market and other changing requirements, but can’t them through so uses manual labor to get the job done. Blue Prism automates that labour – and I am pretty sure it will soon get competitors offering essentially the same solution, but this does not solve the original problem.

We know what it is and we know how to solve it, but even 16 years after the Agile Manifesto the impact we have on the profession and the way we work with business is clearly not sufficient. Apparently, “Agile Transformations” etc. are not achieving the goal of delivering what we call “business agility” – at least not in large, established companies and not on a large scale or fast enough. We need to work harder with our clients & students to help make products like this one a niche proposition.

Also published on my Medium account.

St. Maximilian – patron saint for startupers and entrepreneurs


I invite you to join me in supporting an interesting initiative – a petition to the Pope to declare St. Maximilian Kolbe a patron saint for startupers and entrepreneurs. You may have heard of St. Maximilian death – he offered to die himself instead of another prisoner in the German concentration camp in Auschwitz during the 2nd World War –  and you may be wondering what does a heroic Polish monk have to do with startups and entrepreneurship? This is exactly the question I asked myself when I first heard of this project. Then I read more about St. Maximilian and now I can hardly think of a better patron for us.

You see, before he died St. Maximilian lived for 47 years and boy, was he active during that time. Between 1918 (end of WW1 – and of his studies) and 1939 (start of WW2):

  • he founded a new convent in Niepokalanów – starting with just few other monks, no funds and no house under his leadership it became the largest Catholic convent in Europe at the time with 700 monks housed in a number of buildings on a multi-acre site,
  • he started a newspaper (the main mass medium of his time was print media) again, starting from nothing it reached a circulation of 750k copies, along the way he started ten other publications and newspapers as well as built one of the most modern printing houses in pre-war Poland,
  • he got interested in radio pretty early and was thinking of creating a network of Catholic radio stations covering the whole country and broadcasting to the world, before the war broke out he was already well underway to realize this too having set up a radio station in Niepokalanów (and – just BTW – he was already thinking of television as soon as technology becomes more available),
  • he was thinking beyond Poland – in 1931 he went to Japan – again, having almost no funds, not knowing Japanese and having just few brothers as companions he moved on to start a convent on the outskirts of Nagasaki that remains prominent in the Catholic church of Japan to this day, of course he also started a newspaper there which also continues to be published,
  • having started a mission in Japan as well as China and India he planned to build an airport in Niepokalanow and sent two monks to… pilot training as the first step in that direction (can you imagine a fleet of transport aircrafts piloted by monks crisscrossing the skies bringing supplies and passengers to missions in India, Africa etc? That was St. Maximilian’s vision.),
  • he was even thinking about… space travel – he described a concept for a space vehicle he called “Ethereoplane”.

That is quite a lot for just 20 years of activity – and those are just the highlights. On top of all that he managed to be a priest – he was saying Mass every day, heard confessions and wrote articles, homilies and other works. Considering all that he achieved way more than most entrepreneurs achieve in comparable time – save those most successful in the world. IfSt. Maximilian had not been called into priesthood I am sure he would have been one of the most successful businessmen of his era.

His life reveals entrepreneurial zest – a constant drive to start and build new things, new endeavors, new ventures – and scale them up, prefect them, bring them to full bloom. This is the essence of the entrepreneurial spirit. That makes him indeed an ideal patron for all of us who share it.

If I convinced you too please sign the petition and spread the word. Thank you!

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

By doing this 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. This 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 be 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, go for a coffee or a drive in your car – whatever helps you reflect & think. And when you will need to have a word with someone in private you can also use meetings room for this – no need to keep a ‘private office’ just 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 resource to be acquired, used according to its characteristics and discarded once it is no longer needed or damaged. What kind of relationships are being built by seeing other people like this? Do 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 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 groups 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 harm 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 be 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.

The Triangle of Self-Organization


One of the key aspects of contemporary management is the emphasis on self-organizing, empowered teams. In this article I discuss self-organization more in depth.

First, the name itself is slightly misleading. Self-organization is not something that happens spontaneously – it emerges only if certain conditions are present. I call them the “Triangle of Self-organization”.

First and foremost there must be a clear goal that everyone knows and wants to achieve. This goal can be stated openly or just implied, but it must be present and known to the group. The goal will shape how the group will organize itself – different goals require different sets of skills applied in different sequences.

Then we need some rules of behavior. They will govern the group as it organizes to achieve the goal. Those are the shared “dos” and “donts” of the group. They will wary from case to case and they can also be stated or just assumed. In most cases the rules will come from the organizational context the group operates in, but some rules will also be added by the group itself.

And finally pressure is needed to get the group going. Motivation is something that is also pushing the group towards the goal, however the motivation is usually a long-term sentiment whilst pressure is short term. The motivation can have different sources, but the pressure usually comes from time – something has to be accomplished before something else happens or a deadline is due.


A compelling goal, a set of clear rules and a bit of pressure are what is needed to get self-organization going.

Modern management renounces traditional command&control approach. Instead it relies on indirect direction through setting the elements of the triangle to achieve self-organizing group that will work towards the desired goals. The power of this approach lies in the lack of formal structure within the group – as it works towards the goal it can re-shape itself as needed. It is also more engaging and fulfilling for the participants, because they have a large amount of freedom to apply their best abilities to the problem at hand.

In other words, modern management is not about ignoring the team in hope it will find itself something meaningful to do. It is rather about first choosing the team wisely, then showing it a goal, giving it a set of rules, applying some pressure to get it going – and then carefully, empirically controlling these parameters as the work progresses.

A good example of how the Triangle is applied is Scrum. In a Sprint (an iteration of set duration during which a version of the product must be built) there is a goal (a subset of a larger product vision applying to this sprint), there is a set of rules (some come from Scrum itself – like the prescribed daily meeting – others are developed by team itself or come from the organization’s standards) and there is a short deadline – a sprint is never longer than 30 days – that applies the necessary pressure. The team is free to work as it wants within those boundaries. This is when productive self-organization emerges.

I developed the Triangle of Self-Organization model a couple of years ago to better explain managers what is their role with agile teams. I thought it would help them  better understand what they have to provide in order to achieve the promised benefits of self-organization.

Over time I felt there is a fourth element that needs to be added – information. How the three elements of the Triangle will work in shaping a self-organizing group depends also on the information that is available to that group. People can base their actions and decisions only on what they know. It is like water or air in which the group is immersed – its behavior will depend also on what is in that air. It is in our best interest to ensure the group has all the relevant, up to date information about their work, their environment and everything that may impact their efforts to achieve the goal.

At this point I will contradict myself: self-organization indeed does occur seemingly on its own. However, in most cases it is not productive, not the self-organization that we would like to see in good companies. For the most part the spontaneous self-organization is a kind of creeping conspiracy working against the company’s goals. The root cause is in most cases the disconnect between the real, true goals&rules – and the ones that are stated officially. People very quickly discover false goals and true rules of the game and self-organize accordingly ignoring the official “company mission” or “code of ethics”.

This is why leaders should beware of lying to their teams or hiding a true agenda. It takes an artist at manipulation do pull it off – and in the long run the truth will always surface. It is much better to share the true, compelling goals and rational rules and then allow creative self-organization to occur.

You can also listen to my short talk on the subject.

Technical Debt explanation for businessmen


I was recently asked by a businessman to explain the concept of technical debt – and why it matters to him. He owns a middle-sized company that has nothing to do with IT except as a client/user. The text below was inspired by that discussion.

Software quality can be divided into two major aspects:

  • functional quality and
  • structural quality.

Functional quality means that software (system, application, game etc.) does what it is supposed to do and doesn’t do what it is not expected to do. Structural quality is how well the product is built and it is a function of many elements that can be collectively described as presence of good engineering practices or their absence.

The problem here is that functional quality can be fairly well assessed by the client / user of a software product. Functional quality deficiencies – defects – are plainly visible to the user as various forms of unexpected behavior. Those range from inability to perform functions users expected through corrupt data, incorrect calculations to unexpected error messages, hang-ups or resets etc. 

Structural quality deficiencies, however, are not directly visible to the client. They are visible only to experts – developers – once they have access to the source code and try to modify it. A code of good structural quality is relatively easily understandable and thus modifiable. Conversely, a code of poor structural quality is very hard to understand and therefore modify, sometimes to the point of it being impractical and requiring a full re-write. Structural quality also influences functional quality. When working on a product with poor structural quality it is harder for developers to capture functional defects before they are released. 

Therefore poor structural quality of a software product can be hidden from users, but only until they require further modifications and ongoing development. Then it is visible as high cost of those modifications.  If the problem is not addressed this cost is rising with time, at the same time the functional quality deteriorates.

The problem here is that most software currently operated (especially business software, SCADA systems, large scale ERP systems etc.) was developed with traditional processes where both the scope and cost/time were fixed before work started based on some initial estimates. The complex nature of software development makes such estimates highly unreliable, but the logic of the bidding process drives final bids down. As the result development teams are very frequently  put under pressure to deliver a product against unrealistic deadlines. Since both scope and date are fixed the only recourse left to them is to compromise quality. Because functional quality is visible to the end client the part that gets slashed is structural quality. 

If the product is developed once and then never modified the results of poor structural quality may be negligible. However, if the development is ongoing – as is usually the case – the poor structural quality impedes the teams as they continue their work on the product. If steps are not taken to address the situation, monitor and improve structural quality the teams spend more and more effort on fighting with the existing codebase rather than developing new functions. This is a fairly typical situation in many companies with older products (consisting mainly of what is known to developers as ‘legacy code’).

How that looks like from the business perspective? As time goes by for unit of time / expense spent on development the business gets less and less new functionality as more effort is expended fighting with ‘legacy code’. After certain point schedules frequently slip (scope is not delivered on time) and number of defects released to production increases. This leads to dissatisfied customers, rising maintenance costs and eroding competitive advantage. Details slightly differ depending on whether the software in question is a product sold on the market or used internally to drive business processes, but the net effect is always the same – poor structural quality of software stifles business. If situation is not addressed it may even bring it to bankruptcy. 

The term “technical debt” has been used to better describe this phenomenon to non-technical decision-makers. By not doing some work needed to maintain high structural quality (for example to meet an imposed deadline) teams take on “debt” – they appear to work faster, while in fact they just skip work that will have to be done at some point. As with financial debt there is an ongoing cost of “servicing” it (increasing difficulty to modify and extend existing code). As with financial debt if it is not kept at bay the cost of servicing it increases with time to the point where it eats all the money spent on development. This is when a complete re-write of the software is the only solution left.

To sum it all up:

  • in software there are two components of quality – functional and structural quality,
  • poor functional quality is visible to the client immediately, effects of poor structural quality take some time to become noticeable, but once they do the impact is high and rising with time,
  • the business is impacted by increasing maintenance cost and decreasing speed of developing new features – it takes longer and longer to get modifications and extensions completed,
  • if not addressed situation can get to the point where the only practical way out is a full replacement of the system/product in question.

As an interesting side-note: if teams are frequently working against unrealistic deadlines made up by management or sales and forced upon them the result is a culture of poor quality. That is – employees feel it is acceptable to produce software of poor quality even if at a given moment the pressure is not there. This is where the culture directly and demonstrably impacts the business. 


Rekindling the flame


Someone commented on one of my earlier posts that keeping the work fun and engaging is possible only with exceptional people. I don’t agree.

There are millions of people who come to work every day not because they like what they do, but because they need to earn money to keep themselves afloat in the society. However, I think our industry is different. Most people working in it have been drawn to it by a fascination with computers. It usually started at a pretty young age, when some kids went beyond just plying games and surfing the web. Those actually got interested in how these machines work – and how to get them to do what they wanted. This interest pulled them to make choices in their lives that result now in them working in as software developers (or system admins — or in many other specialized roles our industry has created). 

Very few teenagers have enough life smarts to spend hours learning fairly complex things just because it may lead to a career in a field that pays well has little or no unemployment. Most people at 15 don’t think in those terms. And even if they did there are easier ways to earn a living. You have to be pretty intelligent and work quite hard to get to a level that would make you employable in our field. This is unlike many other professions that don’t require this amount of work or where family connections are enough to get you through (like lawyers). 

In other words I believe that most people in the IT industry had this spark of fascination at some point in time. Unfortunately, many had sadly lost it. Let me share a story here.

Once I was working with a team at a client – a medium-sized company trying to pull itself from a ditch poor management practices have put it in. During a lunch break I sat with developers and one of them told me this: “When I was younger, up until I ended my studies, I thought developing software is fun. I now know it is not true.”. 

Image by Marisa Ficorella

Image by Marisa Ficorella

Those words stuck into my mind ever since as the worst thing I ever heard from a developer. Clearly, the environment he worked for (this was his first and only job after university) has killed the passion he had for software! This short statement, made dispassionately in the passing, told me more about the company, its culture and the caliber of its managers than weeks of interviews and workshops.

But I believe that his passion is not extinguished completely, that somewhere there under all the disappointment and boredom a spark remains. And it could be again turned into a flame if only the management at that unfortunate company did make an effort to create a true, attractive vision for their product and inspire their teams with it. 

I actually think this is one of the duties of leaders starting with executive managers. If they can’t get their own staff excited about the product or service they provide how can they hope to deliver excellence? If they don’t want to deliver the best product or service how can they hope to get their clients to love it? If they don’t pursue excellence why are they in their jobs, wasting everyone’s time including their own? 

It never ceases to amaze me, actually. I have seen so many teams apathetic and alienated from their work, yet each and every time the product could have been so easily “sold” to them as exciting,  interesting and important. Heck, I’ve been to a game development company where this was identified as a problem – and this is probably the easiest product to get geeks excited about. The problem is always that no one cares and no one tries to inspire anyone.

  Image by Dave Hogg

  Image by Dave Hogg

So, if you are in any kind of management position make sure you care what motivates people you work with and keep on providing it. Rekindle that spark they have inside, turn it into a flame.

Just beware that their motivations might be different – and they most likely will be different than yours. However, one thing is common: money is not enough to rekindle the flame and without it there is no  excellence. 

A good leader is not someone who works only with exceptional people but who helps those working with him to grow and become exceptional. At the very least he or she shouldn’t turn exceptional people into burnt out shells.