In Why Agile Estimates Don’t Work – Part 1 I’ve explained why estimates don’t work if someone sees them primarily as a commitment to timing. And, just as I expected, some aficionados rushed to educate me on the subject of estimates in agile, that they are not a commitment but, in short, a discussion of chances and odds of how the development will go, considering the challenges of this particular production environment. Probably, some of those aficionados have accused me of the gravest sin ever, and namely, not reading Mike Cohn’s “Agile Estimating and Planning”. Relax, guys. I studied Cohn’s book long ago, and time after time I would flip its pages to refresh things in my memories, not to mention other books, articles and from-the-trenches stories. My most reliable source for making conclusions, however, is my work. If someone stays out-of-the trenches and theoretizes about estimates, this is just theory. My view on estimates lies in the practical, pragmatic context: if they don’t work as commitment to timing, but as a discussion of chances and odds, why most companies continue to play this game? What makes them go on with it? Why spending lots of time on discussing chances is valued more than action itself?
What Is an Estimate? (take 2)
I’ve cited two options to answer this question in Part 1. Some people, who are, likely, not educated in agile theory, look at agile as a next best silver bullet to complete projects on time and they might wrongly view estimates as a promise of that. They genuinely believe that agile estimates will give them so much sought after reliable reference point about the time of completion. The second group of believers consciously accepts that estimating is a discussion of chances, a probability forecast. The burndown chart provides such forecast based on velocity. Let’s refresh the classical definition of velocity in our memory, quoting from here: “The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed“. Does it ring any bells now? If we never build the same feature twice, just as you can’t step twice into the same river, then why velocity-based forecast should be relied on? In general, this stands true for all the forecast techniques based on past performance, including forecast models. Yes, there are cases when a team’s work is monotonous, iteration in, iteration out, but from what I’ve been able to observe, it happens very rarely. Mostly, in any company and team, the tasks to be done and challenges to be resolved are unique, for each iteration, and for each release. You never know when something pops up and kicks this neat forecast in the butt.
The Devil Is In…
.. not only in the details. The second most common habitat of the said devil, which goes after the details, is human nature itself. Nothing else explains this better than the good old Parkinson’s Law:
Yes, indeed. Having all the time in the world is loose. It’s either you have time, or you don’t have it. It’s either you have the guts and sixth sense to define what should be included to the minimal viable product, for instance, or not. Let’s don’t forget that no one cares about software development for its own sake, except the software developers who view their work as craft. We do things for the market. For customers, and they don’t care about the development kitchen constraints, challenges and brilliant solutions. Same stands true for UX.
Now, how this reasoning fits into the subject of estimates, someone might ask? Here’s the astounding truth. Teams and companies start playing around and messing with estimate rituals when they have some extra fat to burn. There’s no room for activities that are waste in a bootstrapped, mission-oriented, do-or-die start-up squad of several people. If you are in such a team, and tempted to start a planning poker session, don’t do this. Rather than waste your time on playing with probabilities, get some real work done. Write code, do a UI sketch, instill clarity to the work of your team. Some mathematical forecast model surely has it that a brick will fell on your head one day. But you’d hardly be wasting your time to estimate how many more bottles of champagne are likely to slip out of a torn plastic bag, when one of those bottles has already hit the concrete, and there are 3 more in the bag. You’d rush to catch the rest of the bottles, not to let them slip, right? Or will you freeze and estimate the probability of all of the bottles being shattered? This reminds me of the fact, that some business people who are skeptical about shamanism, astrology and other such things, devotedly indulge into what is, in essence, shaman rituals with estimates. Come on, the estimate of completion based on burndown or a planning poker session, is as valid as an astrological forecast. There’s no big difference. It’s either you’re “fat” enough as an organization to afford wasteful rituals or not. In fact, even in large companies that seem to be so safe and secure there’s always the bottomline point of “do or die”. That’s what a recent story with massive job cut by Microsoft proves. Ritual is a waste. If there’s time for rituals left, this is a sign of unhealthy fat. Burn it. If a workgroup discusses development, there’s no need to wrap it in the ritual of estimating, because when a discussion turns into a draining debate of “how probable” this timeframe is, the work suffers. Someone said, there’s a limited number of brains to do the job, and they should be used efficiently. One can suffice with a draft estimated timeframe, there’s no use trying to gauge on the likelihood of this happening, when there’s real work to be done.
Worship the Idol: How Do I Tell My Higher-Ups ..?
As life has it, however, most of us have to cope with the fallacy around estimates being employees in fat organizations, and, hard as you might, a mere human being can not move a mountain. There’s no way to persuade a higher-up non-developer manager, or a client, or a stakeholder in the vanity of estimates. That’s why people go on playing games, as they attend to those who expect a feature or a project to be done on time, as derived from estimate-related shamanic rituals. And, that’s where another interesting booster for evolution is hiding. Luckily — and, yes, I mean it, luckily — there are more non-developers in the position of authority than developers. There’s always a point of litmus test, when someone with a developer background (a project manager, team leader, or someone in middle management) meets the non-developer stakeholder. Why I call it a booster for evolution? If every stakeholder were a developer, they would have probably ended up whining on each other’s shoulder about how difficult life is, and how impossible it is to commit to any timeframe. Having to deal with a non-developer stakeholder about a deadline is stimulating. If you’ve been thinking that something has changed from the hunter-gatherer times, I have bad news for you. The seeming “comfort” guises the basic instinct to act. You either act, or you rot. There’s no other option. No one cares for reactive rants. It’s your actions that define you. It’s your choice to agree to play the estimate game by the rules and accept this as a given, or to quit and find a job where they will not f…k your brain with estimates. If you choose to deal with ruthless stakeholders that are oh-so-not-understanding of how hard a life of a true software craftsman is, move the conversation from the level of rant to the level of action. Use every opportunity to spread the awareness of the challenges that software development portends, and why this domain is un-deadline-ifiable by nature. Amazingly, there are so many people in this world who sincerely believe that an estimate is a credible measure for completion date. Write articles, speak on conferences, join the “no estimates” movement. Fix the gap between what you know, and what they now. If everyone has their say, this world will become a better place, with less projects and software screwed. And, even if you’d still have to deal with the waste of estimates, you’d feel better inside, because you’d be doing your all to change things, instead of ranting.
Enough of thought boosters (or busters?). In Part 3 of the series I will give an outline of some techniques, commonly regarded as techniques for estimates, that might work as a tool for workgroup discussions in some teams. Keep in mind the waste-value balance, though.
Why Agile Estimates Don’t Work – Part 1
As you read this headline, many things came to your mind, probably. You might have recalled those many hours of meetings as you tried to come up with a time estimate for a project or for a product release. Or, you might have remembered the planning poker sessions, which were intended as a spot-on pragmatic business activity, but in the long run proved to be nothing else than a child’s game, because the estimates attained as a result of planning poker sessions differed 2 or 3 times from what the actual work really took. The sharp question that I want to ask is: how many times did you feel deep inside that when they make you do an estimate (them being managers, or clients, or anyone else in charge), you end up with nothing else but a waste of time, because later in the project you still face the need to explain why your initial estimate proved to be that different from how things actually turned out, and feeling guilty in the process, though probably nothing of it was actually your fault?
Don’t get me wrong. My initial intent was pure and well-behaved. I humbly wanted to write an article to sum up techniques for estimation used in agile, describe their pros and cons, and provide people with a single-point reference for all those techniques. However, as I went deeper into the research, I was astounded. It turned out that there are many more articles and write-ups out there in orthodox agile circles on “How to estimate?” as opposed to “Why estimate at all?” In those few cases, where I saw some attempts at explaining “why?”, they stroke me as incongruent and built on some very loose logic. This very fact of the looseness of “why?” puts a big question mark on the validity of the “hows”, because the “how” is a product of “why?” or “what?’ I’ve cited this in one of my previous articles, and I’ll repeat it one more time, because this axiom is universal, and works for all things life and project management alike: The hows will appear if the what becomes clear.
Let’s take the scalpel of pragmatism and dissect the faulty logic behind all things agile estimates.
What is an estimate?
Is it a measure of commitment? Or is it a lazy talk? I tried to find some stats on the actual usefulness of the estimates in story points, and how they’ve proven themselves valid in the bottomline world of business. I found none. From my own experience, I know that estimates never work. I’ve seen this in project-by-project software development and in product development. A slightly modified quote from here:
It’s impossible to estimate something that is being built for the first time.
We never build the same feature twice.
The only viable example of valid use of estimates that comes to my mind goes as far back as to the early 2000′s, when people wanted simple e-commerce web-sites, or dating sites, or something of that kind. Having built a handful of such web-sites, software vendors were more likely to give their clients a realistic estimate of completion, because these web-sites didn’t have a heavy baggage of residual debris, such as technical debt, bulky databases, or an octopus-like architecture, which just spreads, rendering futile any attempts to commit to the bottomline “get the sh..t done on time” stuff.
Next, if any attempts at estimating are futile, then why do most companies continue to play this game, which resembles courting, but unlike courting promises no pleasure ahead, only the ever increasing snowball of mess, feeling guilty, unproductive and unaligned with the only goal that matters: get the job done well and on time?
Stay tuned for the answers and even sharper disclosures in the upcoming part 2 of this article.
5 Reasons Why You Should Stop Estimating User Stories
Joy Spring and Estimated Deadlines
2 Meta-Principles for User Interface Writing
UX: Why User Vision Design Matters
Why Agile Estimates Don’t Work – Part 2
I’m subscribed to a newsletter from Buffer, a startup softdev company that develops an app to manage multiple social accounts. It’s quite an unusual thing for a social media-related company to share sensible advice in their newsletter, and that’s the reason I wanted to learn more about that company. So, I googled all things Buffer. The more I researched, the more I admired them. They are a startup, and they do well, generating over $3 mln in annual revenue, with only 23 people. What is the reason for such an amazing performance? How have they been able to grow from zero to a revenue-generating company, in 3 years, with a lean squad of people, and still bootstrapped? How do they keep up their productivity?
The answer came with a little bit more of research. Buffer don’t wrap their rules of operation in the toga of productivity, or agile, or development process lingo, which is very unusual, and which might explain why this company performs way better compared to the others that do. What’s more, Buffer keeps their people happy and emotionally fulfilled. They don’t think of their company as a racing car that has to be ramped up on speed. They, actually, are not concerned with productivity, or speed, for that matter, at all. The point is: Buffer spotted this one bottomline thing that powers productivity. They refer to their rules of operation not as to policy, but as to culture. And, the way I see it, the ultimate key to their performance is one simple thing called clarity. Check this snip from Buffer’s culture statement.
It might be hard to believe at first, but with a little bit of thinking, we will see that clarity is the key to productivity for any team’s work. Thinking logically, a team’s performance is a sum of smooth individual flows and actions. Developers write code, QA engineers do testing, someone is in charge of automated tests, designers do all things UX. Now, when productivity suffers? As with cars and highways, stops occur when there’s a roadblock or a speed bump of something not being clear. What happens if bumps accumulate for weeks, even years? Production team lose track of priorities and incentives, if a day’s work is filled with un-clarity every step along the way. What should I do in this case? Who do I contact? Who has a clue to this problem that I have? If people in the team fill most of their days with these questions, it’s time to put up a huge red flag and “beware bumps” sign. In this sad case, the team is deprived of the very chance to perform, even if they want, because, individually, they lack clarity. They need to have a clear knowing of those “who, what, why, when, how”-s related to their work, or, at least, they need a fast and smooth way to get the answers. If finding an answer for a repeated daily task becomes an ad hoc improvised quest, R.I.P. productivity. The things covered under the umbrella term of “efficient development process”, are rooted in crystal clarity.
Clarity is also crucial when it goes about motives for the actions of others. Second guessing, or a misunderstanding about someone doing things the way they do them, is another severe case of un-clarity. Generally, we are supposed to assume that everyone is doing their job as best as they can, but, with lack of clarity, the thing that I call “assuming dumbness” rears its ugly head. When it happens, instead of having it clear why someone in a team has done a code, or a test, or a copy, or a design in exactly that way, others make a default assumption that this person is “dumb”, not competent and not knowledgeable. This isn’t a productivity killer, per se, but it is a dangerous team spirit killer, and I hope you haven’t spotted this in your team.
As we can see, there’s no need to go any further and re-invent the wheel. If you’re concerned about bad productivity, or if you see that people look exhausted, unhappy or loose, seemingly giving up on their work, they crave for someone to champion clarity. That’s what Buffer calls “Default to transparency“, which is a sibling of clarity.
So, ask yourself, do you always have this clarity? In your team? Is your day made up of roadblocks, or is it filled with gratifying work which goes in a seamless flow? If no, take action. Go for clarity. Demand it from your managers. Clarity is this so much wanted silver bullet for productivity in a software development team. If you find ways to instill the culture of clarity in your team, every step along the way, the Holy Grail is yours.
Non-Violent Communication for Agile Teams
Are You Dumb?
How Communication Factors In To Production
Non-Judgmental Communication for Agile Teams
Why Fast Is Slow
Uselink: Organizational Culture and Development Process
Project Manager or Tech Leader?
The Dangers of Small Talk
Why Self-Organization Is a Luxury
Why Is It Right to Write?
What’s Wrong With Your Questions?
When Intensity Pays Off
Software development companies have been using real-time online communication tools for about 10-15 years by now, and it’s hard to imagine how they could possibly do without such tools at all. Online collaboration started out first as instant messaging, back in the late 90′s – early 2000′s. With distributed teams and with work outsourced to other parts of the world, instant messaging became indispensable. Be it a development team located thousands miles away from an executive team, or from a customer support team, or whether an organization needs an online hub where the remote workers can get together, no one questions the need for such tools and the value they bring to the workflow. However, online messaging has always been a subject to productivity-related concerns, and for a reason. I want to look into how the real-time online communications at work evolved over the last 15 years, how it was early on, what has changed now, and what we need to do about those changes, as stakeholders, or as employees if we want to be productive and feel good about our work.
Instant messaging at work in the early-mid 2000′s: Block and Spy
In early 2000′s workplace culture was more restrictive and prohibitive, in general, than nowadays. Some companies used the punish-and-fear practices with regard of instant messaging at work: they would log ICQ chats, banning any chatter unrelated to work altogether, or they would go as far as to totally block instant messengers. A point to note: there was no Facebook in the early-mid 2000′s. Instant messaging just started out, and I’m old enough to remember how it seemed to be one of those technological miracles. People were soo eager to chat online with their friends when at work. The employers, naturally, wanted to keep their employees working and working. The practices of material production were implanted to software development back then. They assumed, mostly, that knowledge workers should work by the same token as machines in the manufacturing: 9-5 and non-stop. Back at those times, the issue of productivity with instant messaging at work was about not letting people get distracted. To get an idea of how it was back then (or to refresh the memories), we can refer to this 10-year old article in Wall Street Journal. Someone would probably smile, as they read this, quoting from the article: “Being overly casual with colleagues and superiors is one of the biggest pitfalls of using instant messaging.”
The rise and decline of Facebook in the mid 2000′s – early 2010′s
By mid 2000′s this dynamics was replaced by a new one. Enter Facebook, going mainstream in about ’07-08. No doubt, Facebook has influenced the way we live our lives, let alone our communications with friends and co-workers. Some employers sensed trouble as early as then and blocked access to Facebook in their companies. But these attempts were futile, because the general public opinion tended to regard such actions as the Draconian culture-of-fear measures. 5-7 years later, one can observe yet another change. Now numerous studies and research prove that Facebook makes people unhappy, and they give a detailed account of how exactly this happens. I reckon the recent notorious psychological experiment conducted by Facebook is a clear proof that they sense trouble and look for the clues on how to keep people hanging out there. Otherwise, the Facebook’s game might be over. Anyway, back to to my story.
The Facebook-ization of workspace
Facebook, as outstanding a phenomenon in public life as it is, has certainly influenced the way companies arrange their online communications. Before Facebook, it was about instant messaging. In the age of Facebook, real-time communication at work has got more and more Facebook-ized. Now these tools are not “instant messengers”, they are referred to as the tools for “team collaboration, file sharing, document sharing, social sharing”. Can you feel the difference? Now, let’s think logically: if research proves that Facebook makes people unhappy, and given that real-time collaboration tools have acquired many Facebook-ish traits, it is safe to assume that teams might be subjected to this same unhappiness and feeling low as they use such tools, similarly to how it happens with Facebook users! So, which Facebook-like peculiarities of online team collaboration tools do we need to keep an eye on? Where’s the potential danger of unhappiness and unproductiveness?
Miserable observer vs. energetic doer
As the research has it, one of the most insidious traps associated with Facebook, on a psychological level, is spending more time in passive than in active mode. The more time we spend browsing photos and passively checking updates, the worse it feels. Same with the real-time team collaboration tools. Once we spend a lot of time passively checking status updates of our co-workers, on how something worked great or sucked in an area of work which is beyond our control, a certain cognitive bias of being let out of the real action is slowly formed. It might feel that our work doesn’t matter at all. There’s a nagging voice that says: “All my efforts are in vain, no one needs them.” In a bounceback fashion, these people will want to stand out and make a difference. But their work is not related to any major achievements. They just do their job, as a tech support engineer, or as a QA engineer, or as a software developer. Still, they feel alienated, under the influence of this bias, and they will act Facebook-ishly to remind the rest of the world that their work matters. They’d post an update that — in their mind influenced by the bias — would make their work appear meaningful. But this update wouldn’t add value to the work of others in the team. Or, they might tend to be overcritical as to how things work, or how something is eternally wrong. I do not mean the exchanges where the team collaborate online to resolve an urgent issue real-time. My point is that these channels of communication have to be arranged thoughtfully, and engage those employees that can be the doers in such situations, rather than passive observers. I’ve given just some examples of the distortions produced by those biases. Let alone that this vicious “feeling low+the need to compensate” circle creates a swirl of alienation, its contribution to the team’s productivity is zero. If an employee is preoccupied with this unhealthy virtual environment, and tends to act in a Facebook-ish fashion, they do not do the work. They blow their productive focus and their mental energy on coping with such psychological biases.
What to do about Facebook-ish biases?
If something like that happens in your team, fingerpointing and spotting individual point of failures will not help. People are people, we have emotions and visceral reactions. The only way to go forward and to keep us productive, energetic and healthy at work is to sit down, think and come up with the strategic setup for internal communications. Who in the team needs to collaborate real-time to do their job? For whom online collaboration is more of a waste, loaded with potential biases? If someone needs some information, could there be such a setup, where they’d get this info async? If this info is available, how do we make sure that everyone knows where to get it? These are just some questions that one needs to answer. If you’re a a stakeholder, or a person in charge of the mechanics by which your company runs, there’s a compelling evidence that calls to de-Facebook-ize work-related communications. If we think more about it, the real-time messaging is usually required for customer-related issues. It could be, a tech support team urgently needs help from developers or from the dev ops. But do they need to include other people from QA and dev to these firefighter talks? Gee, if the production team see that customers always come complaining, they might get a bad cognitive bias that no matter how hard they work, customers still have issues. The rule of a thumb is: think who needs which information to do their work, rather than “why don’t we keep everyone informed real-time?” Biases developed from spending time in passive-observer mode come with a price tag: dissatisfaction with work, loss of productivity, and a whole array of other such bad things, which no sensible person, be it an employee or a business owner, would want to have in their organization. If you are an employee, think if you want to stay on top of all the updates real-time. Beware passive browsing. It’s the most dangerous thing ever about anything online. If your management has no policy for real-time collab tools, invent it for yourself. When you start feeling bad being a passive observer, and catch yourself posting notes with negative or sarcastic messages, run away. Shut down those channels, and focus on your own work.
Slack, an online team collaboration tool, displays some cheerful messages for its users. One of these messages is particularly wise and well-intentioned. Here’s how it goes: “Enjoy Slack responsibly“. Also, Slack has a slogan on their web-site: “Be less busy”, which I would like to extend: “Be less busy. Be more focused instead“.
Getting Closer with Remote
Skype Is (not) The Limit
We’ve been raised in the belief that all humans are social animals, as the theory of evolution has it. If you’re wondering how the evolution and being a social animal is ever related to work in software development, or, more precisely, how it slows down personal and organizational productivity, that’s exactly what my today’s article is about.
Social Animal ≠ Productive Performer
What strikes me most is that we keep on going with the axiom that humans are social animals. Seemingly, we forgot that evolution never stops. With the advances in technology and life infrastructure that happened in the last 30-40 years, the “social animal” concept has suffered some severe cracks. If we look at animals, why are they social? Why they stick together? It helps them feel secure in their natural environment (a flock of deer will sense the danger of the wolves approaching better than one deer), and it helps them get the food easier than on their own (lions, or wolves, hunt in families and then share the meal). Now, do we humans have to gather into a herd, like those animals do in the wild, to secure ourselves or to escape starvation? Obviously, no. But, for some reason, organizations still stick to this thinking as they arrange open-space office layouts for knowledge workers.
Even evolution-wise, the purpose of humans working in an office, to maintain their living, deep down, is no longer to be just fed or to seek shelter. If a contemporary human wants to stay secure and keep “being fed”, the evolution dictates the need to find the optimal ways to perform well at work. “Optimal” stands for “achieve best results with least personal energy consumed”. Staying in physical proximity in one room at work no longer helps our natural evolution, but rather presents a big obstacle to it. With knowledge work, it’s counter-evolutionary and self-sabotaging to expose oneself to the environments that drain us. Numerous research reports prove what people intuitively feel inside: to keep good health and to perform well, we need to arrange for a space that helps personal productivity, rather than blocks it.
The law of personal energy conservation in the office
Think about it. If you were to count the cases when staying in one room with your co-workers really contributed to your individual performance, and hence to your own well-being and to the well-being of the whole organization vs. how often it was an annoying distraction that sucked your energy that could have been invested into doing the real work? Our co-roomers’ activities have the same effect on us as many apps running in the background have on smartphones. It seems that the phone is doing nothing and just idles, but the battery charge gets lower. The energy is gone. If you’d need to make an urgent call in the middle of nowhere, with no option to charge it, your smartphone will not be able to accomplish this vital task.
It’s about the same with staying in an open-office space. If we throw in to the mixture the other stresses that people have in their lives, things get even worse.
If not an open office, then which one?
How to go about designing office spaces, then? The answer is: it depends on the unique setup and production/development process in your organization. Sometimes sharing a room might work better for a small workgroup, if they rely heavily on a real-communication inside the group. Like, for a feature team of software developers and QA who call on each other, as they have to verify commits, or if QA’s need help from developers to reproduce a bug, etc. Or, for customer service employees in technical support and in accounts. It makes sense for them to stay in a shared open-space for their evolution and well-being (read, for their ability to do their work better). However, an open space would be a productivity killer for a strategizer, or for someone who comes up with creative concepts or designs that development teams will then carve in the digital rocks of software. Can you imagine Winston Churchill or Steve Jobs working in an open space office, let me ask? Hardly anyone would doubt that privacy is a must for the highly creative work.
There’s another erroneous consideration that stakeholders might have in mind about open-space offices. They assume that physical proximity will cement people’s belonging to a cohesive team of individuals who share company goals and values the more, the more time they spend together. Wrong. Belonging to a group can be promoted by other means, such as sharing a company’s philosophy through the space itself, or, what’s most important, by doing some good job together. We wouldn’t think that a family of 4 would have a better sense of a family if they are forced to live in a 200 sq feet apartment, would we? The same is true here. Creating an organizational ethos and having employees light up with it does not happen simply by stowing people in one room. It takes more foresight, thinking and attention to detail. For starters, the team spirit is best promoted by a successful release or by another important milestone achieved together.
This is all about how the specifics of work correlates with the space. While some companies simply do not feel that they can (or should) allocate larger budgets to fine-tune their offices, some people can do just fine working at home, if their home is better conditioned for work than an open-space office. Alternatively, for someone with kids, or with the A/C at home not working, an office would be a better place to work. What and how works better will also depend on the office demographics. Millenials, the Gen Y-ers, for example, are more likely to put up with the distractions merely due to the fact that they appreciate their office as a space where they can socialize (some say it might be the root cause of why this generation seems to be underpeforming in general). Disclaimer: I’m a Gen X’er :) Not sure if it’s solely for that reason, but I value focused concentration at work more than socializing. This is just another example that shows how deep stakeholders need to think as they approach the job of designing an office. There are so many factors to consider and to write about, that it would take a huge article just to list them all. For each and every company, there will be a unique solution.
5 Things We Need for Sustainable Performance At Work
Continuous Problem-Solving Is No Accident
Getting Closer With Remote
Cognitive Endurance Basics for Software Developers
Top 5 Non-Office Brain Killers
We work with other people in office environments. Software development teams represent connected pulsating nodes of energies and emotions, regardless of whether the people stay in cubicles or in open spaces. As an outsider walks in to an office of some company, they might be able to sense it right from the start, if the emotional climate is moderate and comfortably mild, as in Northwest Pacific, or if there’s a sense of hidden tornadoes and storms in the air, as in the Plains, or if there’s a scorching drought and ruthless heat as in Arizona or in California. If you’re a softdev professional who is considering a job opportunity, you might want to make sure that your “climate” preferences match that of the company you’re going to commit yourself to. Some people don’t mind staying on the verge of storms, they even like it. Some prefer to stay away from the emotional extremes, expressed outwardly or latently. These preferences do not define someone as a competent or incompetent professional. It’s just that professionals need the environments that are right for them to show their best qualities in action.
We all know how challenging the situation with natural environment is these days. They launch initiatives to reduce the carbon footprint and to dampen the impact that industries are making on the climate. The damage from tornadoes, droughts and floods is just too costly, and not only in terms of damage to properties, but in terms of the count of lives taken. It’s very evident on the scale of the planet Earth, how dangerous the consequences of careless human actions can be.
It might not seem as evident and as dramatic, if the emotional atmosphere in an office feels like an accumulation of burnouts (think drought), or like forming a tornado’s supercell, or like a hopeless swamp. But, in the long run, the consequences for companies can be quite dramatic. Naturally, these emotional climates are created by people. If you’ve worked in several companies, you must have sensed that, and you must have felt if this particular environment lets you thrive, or if you want to get out from there.
Every sensible human being needs to take care of herself, first of all. On planes, the in-flight security regulations tell us: “Put on your oxygen mask first, then help the others.” Indeed, we can only deliver our best performance in an environment that suits us most. Some people do not want to make a difference in their career, and they want to work in a swampy company, in some monotonous many-year project, doing their 9-5 work, collecting their paycheck, and then going home. There’s nothing wrong with it, if they do their job well in this environment, and if the environment lets them live this way. Probably such people invest their energies into things that are unrelated to their work, e.g. their family or their hobby. They do not perform well under duress. If you’re the one who wants to stay away from burnouts, and if “work is the highest priority” is not your motto, then wanting to be hired by Google, for example, wouldn’t look like a sensible decision, considering accounts of Google’s employees working crazy 60-80 hrs per week. You’d need to pick a company with a more conservative structure and well-defined job boundaries and responsibilities. Well, drought-stricken companies might offer a better pay, but being lured with more $$$ only to lose your sleep and health wouldn’t be a wise personal strategy in the long run.
Then, if you’re the kind of person who truly wants to make a difference and contribute to some remarkable software product or service, you either need to start your own company or a start-up, or join a team of aficionados. You will hate to stay in a swampy boring environment if you’re a person like that. You would probably want to contribute to your company on many levels, beyond your initial responsibilities, if that’s the way you are, and you wouldn’t be happy in an environment that blocks your vigor and candor. In that case, you’d welcome this drought of drive and passion.
Some companies keep the climate somewhere in the middle between super-drought and super-swamp. In fact, those two might even co-exist, right by each other’s side, in one and the same organization. Some employees don’t feel that what they do makes a huge difference, and they don’t know what “passion for work” stands for. They just work. The others, however, might be staying in the drought climate zone, exposed to stresses, tensions and passions. Some risky decision-making might be involved, or meeting an important deadline, or winning over an important client. The problem then — and that’s when tornadoes are born — is when the drought-stricken individuals are passing on their second-hand stress to those peaceful “farmers”. Being a peaceful farmer in a software development company is not a bad thing per se, and you can be proud if you’re the one. Such farmers are usually the rainmakers, and drama is the last thing they need to do their work well. Burned out, impatient aficionados crave the rain in the form of a successful release, or meeting a deadline, but the rainmakers might be scared away by the aficionados’ stressed out behaviors. It might even make sense to put on some sort of blends on the farmers and intentionally guard them from the tense vibes. Catching a second-hand burnout does no good to organizational productivity; that’s why keeping the harmonious environment for the rainmakers should be high in the list of priorities for someone in a position of power. Balancing between a swamp and a heat is vital for such a company to avoid devastating tornadoes. In fact, the real tornadoes are formed when the areas of high pressure and low pressure in the air collide. The second-hand panic and anxiety is poignant, and emotions are not just emotions. They transform into productivity, fueling it or blocking it. So, the more anxious someone is to whip the horse, the more this horse would refuse to draw the cart. There’s a certain slight boundary where too much passion turns into restless anxiety,which burns out everything and everyone around.
I wonder, if it’s a coincidence that the company run by Bill Gates, the well-tempered, balanced person who stays healthy in his late 50′s, is headquartered in the gentle moderate climate of Northwest Pacific?
Who’s The Rainmaker?
5 Things We Need For Sustainable Performance At Work
Gates or Jobs?
Why Fast Is Slow?
How Communication Factors In To Production?
Measuring Productivity In Software Development Teams
People We Like
A Christmas Tale of a Software Developer and Santa
Non-Judgmental Communication For Agile Teams
When Intensity Pays Off
If you’ve been to Asian countries, or to Chinese quarters in a large city, you probably know that they eat bugs in Asia. Well, they also eat snakes, caterpillars, ants, worms and what not, but for the sake of my today’s discourse I’ll focus on bugs. Cooking and serving bugs properly is a high art. If something in the cooking process is messed up, bugs will not taste as a deli, but as something mmm… extremely un-delicious. I don’t think I will ever want to eat any of those many-legged sources of protein, unless under very compelling circumstances. However, there are folks who have to deal with bugs every day. In office. At work. You guessed it right. Today I will sum up a few tips on how bugs should be cooked and served for QA engineers, or for anyone else in your team who wants to digest them and to get rid of them as efficiently as they can.
I’ve borrowed these tips from our QA team. Actually, I need decent bug reports in my work as a publishing editor of Targetprocess product blog release notes as well. These release notes include a short summary of fixed bugs, and at times it’s been quite a pain for our blog publishing team to understand what those bugs are about from their names. For the release notes, we want bugs to have concise names, because our customers need to know what we actually fixed. Likewise, developers might experience the same kind of trouble, trying to retrieve the nuggets of meaning from a lousy bug report in their daily assignments. Or, support engineers need to check quickly if a bug they’re reporting is known, or not.
Why do we need informative bug reports?
a) We waste no time asking myriad questions trying to figure what a bug description implies. Yes, in agile teams people are supposed to talk. However, when a team gets bigger, approaching someone and talking might not be as simple as in a pizza-sized team.
b) We can quickly refresh in our memory what exactly has been done about that bug.
c) We are able to follow the thinking behind a bug fix solution, and we stay informed of any possible trade offs, if any, and why they have been made. At times, the steps to reproduce a bug, or a bug fix might seem weird, unless one knows from which pantry this bug comes from, so to say.
d) To stay in the loop of what’s going on around and make mental notes of the bugs processed by other teams.
Now, can anyone, except the person who wrote this, figure what the following is supposed to mean: “This thing is not working correctly” ??? To make some sense of it, one has to check probably tons of info searching for a clue of what “working correctly” implies for “this thing”.
On top of that, if this bug lacks a screenshot and a clear how-should-it-work summary, the person who posted it looks like a perfect nominee for the “Bug Chef Dunce” award.
Which bug is a well-served bug?
We will call bugs well-served if all of the following is true:
1. Their Name is a concise, well-written sentence that renders the problem. Not that this bug just exists, not where it exists, but the problem that it causes to users.
Compare: “Quick Add for users is not working correctly” and “Quick Add many users: only the first user from the batch is assigned to selected Projects”.
2. A good bug Summary should allow a developer to understand in as little time as possible which behavior should be reproduced and the steps to reproduce it.
Bugs with a summary such as this one — “When I see “remove” button, I see performance degradation” — get straight to hell along with the “wordsmiths” who write them. One might want to use the “What? Where? When?” technique to write a bug summary. What goes wrong, where this wrong behavior is observed, and when, at which actions.
3. Actual behavior vs. Expected behavior. A few sentences or screenshots describing these are the best friends of productivity for a fix. They simply leave no chance for your bug report to be misunderstood and fixed improperly.
I hope this quick tips will help QAs, developers and tech support teams ensure that their bugs are served properly, ready to be digested by stomachs of whichever omnivores who need to process them.
Why I Love Our QA’s
Development Practice: The Ultimate Clean-Up Day
Zero Defects? Are You Kidding Me?
The more I explore how IT organizations work, the more I see how strikingly diverse they are. They are as unique as human beings. Each organization has its unique process, unique culture and unique service or product that they deliver. On the surface, it might seem that businesses can be broken down into categories, e.g. a small or a large, a production or a service company, and there’s indeed a certain similarity. The big “but” comes into play when an organization wants to achieve some outstanding goal, e.g. increase sales by 300%, or cut down the time to production by 50%. There’s no such thing as similarity then. Small things in which companies differ then gain the last-drop power for a breakthrough to happen. The uniqueness lies in custom mixes of organizational culture and production process. Unique goals require unique ways to achieve them. I will use software development industry as an example to illustrate one striking phenomenon that holds they key, the Holy Grail to getting things done efficiently in unique organizational contexts.
Solve a Unique Problem by Copy-Pasting a Solution? No way.
At various phases of their lifecycles, organizations have to address their unique challenges. What do stakeholders usually do first as they encounter a problem? One disturbing commonplace trend that I’ve noticed is to replace addressing the root of a problem with a trendy buzzword model or management technique, and rely on it thinking: “Once we implement this super thing in our company, all our problems will be resolved.” Or, if the Super A..buzzword technique is implemented, and brings no results, stakeholders keep staying in the limited stalls of prescribed buzzwords, and then that’s what they think: “Hmm, the Super A.. thing is not working. How about we try a Super K… thing?” I’ve written about that in my previous articles on agile, Kanban and Big Data, as I looked at their origin, and on how they play out in the long run. It could all be very well if this approach with sticking, or switching, to one coined technique or another helped in 100% of cases. That’s not true, however. It seems that most organizations have slid from the ruthless clarity of a simple “why?” to juggling boxes filled with loud labels for what some time worked for someone. Thinking is the hardest job, and with the amount of cognitive loads that we, Homo Sapiens, experience these days, organizational stakeholders are tempted to use shortcuts and grab the leash of what a mega-guru has said should be done. *Totally forgetting that the mega guru probably used this technique or a tip for an organization that is completely different from yours*.
Which consequences does this habit have on a larger scale? Trying to fit a unique context of an organizational challenge to a limited set of Super A.. or Super K… techniques is an attempt in futility. If there’s some fat on the belly, that is, if this organization can afford paying for such abstract things as “measuring agility” (???), then the stakeholders would hire a consultant to translate the language of how things work in their organization to a lingo of a Super A.. technique, and/or will send their employees to be certified in this new religion, and/or introduce some ridiculous measurements that would serve it. Such reality shows are ubiquitous, and the following lame syllogism crowns them: “We are going Super A.. now, so we need a tool to call ourselves truly Super A…” or ” Hmmm… Super A.. does not work for us. The sales are not higher, and we do not have faster turnaround times, and Super A… is not helping us find out if what we are doing is actually right or wrong for our organization if we want to hit this target. Hmm. They now say a lot about the Super K.. technique. Yes! Let’s try it. Let’s switch to Super K.. and, of course, we want to be truly Super K.. so we need a tool for that!”
The Health Check: 5 Why’s and 6 W’s
The quickest health check is to ask the 5 Why’s. Why are we doing this? If the name of the Super A.. will still linger in the answer to your very last 5th “why”, you can probably throw the super A.. to the trash bin. Your organization needs to deal with real things. Not with the labels in a toy store. The other health check is the 6 W questions technique (What? Why? Where? Who? When? Which?) applied to what you have in plan for projects and processes. As a side note, I don’t care from which buzz management Super XYZ lingo the 6 W’s and 5 Why’s originate (and, yes, I do know of Six Sigma). These are the simplest bulls..it detectors to verify the actual worth of an approach to management.
It breaks my heart to read articles and blogs on software development written exactly with the Super Whatever shallow mindset. I can’t stand looking at how limited thinking prevents people from grasping the uniqueness of their challenges and addressing them effectively. I can’t stand looking at how the loud name of “methodology” is haphazardly glued to the how-to techniques and practices that worked only for certain organizations. And, I’ve explored the reasons for that thing happening in one of my previous articles. The education that IT professionals receive is too narrow. It doesn’t allow them to look beyond how-to’s too much, as they are not even trained to look beyond the how-to’s. The how-to approach works for coding, or for dealing with mechanisms, but it doesn’t work for organization/product/project management. I’m humbly hoping that my articles help to provide broader and deeper perspective, a perspective that someone might need to fix things gone wrong in their organizations.
Back to my intolerance to the evil reign of how-to’s and to the habit of their copy-pasting. This habit is even more dangerous than smoking or drinking, because with these everyone knows they are bad habits, while with the how-to’s abuse, people keep thinking that if everyone else does it, then that’s OK.
Pragmatism is Dead, Long Live Pragmatism!
It’s time to regain justice and call things their true names. Let’s retrieve one precious treasure from the chest of eternal wisdom and blow the dust off of it. The treasure that lies there abandoned has this written on its plate:
A methodology is a school of thought, and a method is a way of doing something.
In other words, practice is the only criterion for truth. On the meta-level, this reasoning is backed up by the philosophy of pragmatism. However, there can be a shallow pragmatism and a smart pragmatism. A shallow pragmatism, briefly, is a short-sighted plan and course of actions, while smart pragmatism is something that I’ve written about in the article Visualization: Why the Fusion of Arts and Tech Matters.
The smart pragmatism, for software development, occurs when the blind sages touching various parts of an elephant recover their sight and realize that all of its parts function as a whole. Often organizations held their internal mini-wars, especially as they grow, between marketing teams and production teams, as they divide the spheres of responsibility between many decision-making groups, and when those parts have to merge, it feels like flying through the rough air. The head does not know what legs and arms are doing, something of that nature.
I want to make null and void any methodologies except “use your guts”. There’s no such thing as a success of a one part. Success comes as a whole, and for that success to happen, unfortunately (or fortunately), there’s no other way as to think outside-the-box, sometimes even forcefully blocking the trendy how-to’s. One can read tons of books, or follow gurus, or “best practices”, but these activities are secondary as compared to independent thinking. Sometimes, it’s a surprising and a pleasant side-effect to discover that you have arrived to the same conclusion as some renowned guru did, but by yourself, in your practical context. And this is a lot more precious and effective than copy-pasting a technique with no deeper understanding. That’s why, if you have no guts — grow them. If you have guts, but you’re too tired, get some rest and restore your ability to think independently and clearly.
No Need for Ninjas, but Let’s Call This Thing Somehow
The use-your-guts pragmatic methodology does require a method (a way of doing). I’ve checked on most of the methods used in software development. Some of them have common sense in-mixed with limiting prescribed practices (see my article Stuck with Kanban? Consider Multiban). As you might have guessed, I have invented a method that is based on Kanban, but differentiates from it in the core “way of doing “. And, although I’m quite skeptical about using new names for what appears to be clear, I still have a name for that method: Multiban. This word is a Japanese-English mixture, and means something along the lines of many boards, many views and many perspectives. This name will stick in the memory, as it implies connection with Kanban method, with one important update. While Kanban uses cards as static signs for work items only, Multiban uses cards as dynamic signs for any abstract or concrete entity. Multiban is a visual management method (see and use your guts) that has no prescribed practices. All Multiban wants are custom visual representations, multiple 2D views of crossed rows and columns, that support whichever perspective to power your thinking. Why I deemed Kanban a good method to build on further? It’s because of the “visualize” part. That’s about the only thing that is unquestionable about the Kanban method: visualization. Nothing else supports the pragmatic, use-your-guts thinking better than visualizing. Indeed, when things are brought from heads to paper (or to screens), that’s a huge aide. Pragmatic stakeholders need more ways to look at what happens with their projects and processes, than with static Kanban cards that signify work items.
Now, as I’ve identified this method, for free-thinkers who want unlimited help and unlimited freedom with their unique ways of thinking, let’s see which digital tools might support this. Most of the Kanban tools are limiting. They lack versatile visualizations. Here’s a write-up about one such pretty decent Kanban tool that, however, fails to deliver many views and many perspectives. Quite predictable, I found out that so far only Targetprocess 3, our visual management software, supports the unlimited thinking and free-from-the-leash no-nonsense work — and the Multiban method — as it brings to the table unlimited 2D views for any dataset. No strings attached, the tool also allows to exercise agile, Scrum, Kanban and other SUPER ABC things. But the most important part about Targetprocess 3 is that it supports your own unique way of thinking and decision-making, be it on micro-level with bug fixing, or work items management, or on macro-level with managing portfolios of projects, or with roadmaps, in ERP or wherever.
I’m probably trying to squeeze too many things in one article. Each of the aspects I’ve touched upon deserves an article by itself. I’m certain that what this world lacks most is insightful out-of-the-box thinking. People are stuck in prescribed patterns on many levels in their lives, their work in software development, or organization/product/project management being one of them. I want to tackle this, and that’s why I will persistently champion the smart pragmatism and the Multiban method in my writings.
If you want to learn more about how Multiban stands out as a method and as a technique for visual management, check the related articles.
Kanban as Multiban
Stuck with Kanban? Consider Multiban
Our Evolution of Visual Process Management
What’s Wrong With My Kanban Board?
I’ve explored once how software products appeal to our emotions, and how this emotional imprint affects our willingness to spend time with a software product or an app. Why should this utterly non-technical stuff matter at all to those of us who create software? Emotions and personal perceptions play a far larger role that one can imagine when people decide to go with a product or not. A software may seem a perfect fit to the rational side if it does what we need, but in the world where many products come with about the same set of features, it’s those several tiny grains of sand that could make the scales tip towards the very final “yes” or “no”.
Let me give a very personal example. Recently we released Targetprocess 3.0 (that’s the project management software that we develop). The new Targetprocess is so visual, customizable and flexible; it caters to each and every need in project management with any development process. Things that we bring to the table with Targeprocess 3 are awesome. But — I have a confession to make — I still continue to use Targetprocess v. 2.0 for my own tasks. The reason is simple: I really don’t like grey as the background color. Compare this, as in version 2.0 (click to enlarge):
and this, as in Targetprocess v.3:
I was worried if something’s wrong with me and researched on how colors influence our productivity. The difference that proved to be heart-wrenching is in the background color. It turned out that I’m used to having white as a background more than I was able to realize consciously. In Targetprocess 3, the background color is grey-ish, and the appearance of cards can be customized, with mashups, but by default a card is white against the grey background (and we often have the cards colored into a darker shade of grey against a lighter grey background). It’s too much of grey to me. Grey is a neutral color, and it appears that if this neutrality is in the background all the time, then I don’t feel comfortable inside this UI, because the neutrality has no drive, and it doesn’t encourage me to stay in the board view (or a timeline view, or a list view) for too long. I feel safer and more comfortable in the familiar reality of the white background with greyish cards for some reason. It could be linked to the fact that when we start something new, and we are particularly inspired about something, we’re talking about the color “white”. We have whiteboards on the walls. We have white sheets of paper, not grey. The whiteness is encouraging, it says — go ahead, play with this thing, change it! At least, that’s what comes to my mind as I try to dissect these feelings.
Grey and various shades of grey are trending. This color is generally unobtrusive and just neutral, as a smile of a stranger. I have nothing against a tinge of grey in a menu, but solid grey background makes me strain myself more than needed for the work. I want my favourite tool to encourage me and energize me with the freshness and newness of the white. Grey, however, seems to be draining the productive energy from me, not sustaining it. I’m not sure if this is only me, perhaps someone else would have a different perception of this color. I’m certain, though, that if I’m supposed to be mentally sharp, as opposed to spending time leisurely, the solid grey background is taxing. A piece of grey ingrained into white once in a while would be OK. But not solid grey.
Do You Speak Human, Software?
Imperatives in User Experience Design
The Paradigm of Project Management Tools
Best practices. What is that thing? If you ever wanted to make your IT organization run efficiently, like well-lubricated clockwork, then you must have hunted for best practices that other org’s have successfully used to resolve the bottleneck which looks exactly the same as the one that causes this itchy sensation inside your brain…
Let’s refer to a definition of best practice:
A best practice is a method or a technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark…. Best practice is considered by some as a business buzzword, used to describe the process of developing and following a standard way of doing things that multiple organizations can use.
Take a yet closer look. Does anything strike your eye as incongruent here? To me, there’s a mismatch at the bottomline level of formal logic. This definition mentions some abstract “multiple organizations” and is lacking the most essential foundation for trying any practice, be it a best practice, or a humble custom practice that works very well for your particular organization, in your particular business and production environment, and in that part of the world where you happen to be located.
How can we logically assume, that if we copy-paste a best practice from company A to company B, where company A is Google, or Facebook, or Yahoo, and company B is any software product company, then this practice will work 100% as actually “best”?
I’ve written about best practices before, and on how one has to be careful with them. Recently, in reviewing the Remote book, I tried to highlight how crucial well-tuned async exchanges are for a a company that wants to delve into a remote mode of work. In line with the analogy from agriculture used in the review, farmers somehow know that if they mimic a best practice, it has to be used for a certain kind of soil, under certain climate conditions, or for a certain yearly amount of rainfall and sunshine. Also, this best practice will vary depending on what do they grow: potatoes or corn, or wheat. No farmer would be as crazy as to to use the same fertilizers, or the same cultivation techniques for various plants. However, with organizations, although they are far more diverse than plants, and differ by many more things than climate, sunshine, and rainfall, the common trend is to ignore the subtle differences, put up the banner high and march along chanting: “This Super Mega company is using such and such as a best practice. If they are doing this, and someone has called this “best practice”, we don’t need to waste time looking and thinking. Let’s just replicate what they do”. As a side note, I must add that “waste time looking and thinking” stands either for lack of guts to look and think, or being too tired of looking and thinking, and simply wanting to try just anything that seems to work. Or, which isn’t that obvious, a quest for best practices might mean that this company has grown fat on their belly and they now have some buffer to play with new things, if this playing seems to compensate the lack of breakthroughs.
Last year, in what appeared to be a very anti-mainstream move, Marrisa Meyer of Yahoo cut an end to the remote looseness that threw out its insidious roots threatening to strangle the drive and focused work at Yahoo. They showered her with digital rotten tomatoes. However, I applaud Ms. Meyer’s insight as she’s chosen to act based on her gut feeling and pragmatic analysis of Yahoo’s pulse beat. She wasn’t preoccupied with whether or not she as a CEO had to waste her time on curtsies, just to re-affirm to the employees that the company trusts them. Probably, she knew that those who could be trusted will understand this act, and those who cannot — they’d quit. However, even with most trusted employees — and that’s what Yahoo’s case appears to be — there are times when to stand firm and to be united in reaching a crucial goal, they have to cut down on the looseness and just bring people together, because in hard and responsible times the shared energy of the team has to be concentrated in one physical space. Not scattered in residential houses, or weakened by hanging out at home in sweat pants. Have you ever heard of a company that made a breakthrough at a challenging time as they worked remotely? I haven’t. All the stories of garage start-ups, or breakthroughs, or some crucial advances have it that people, the teammates, stay close together, and exercise their concentrated will and resolve to accomplish the task at hand. The remote way of working is rather a way to go smoothly with the flow, once the breakthrough is done. Or, a company can use this as a “we do this, too” way of providing a popular perk to the employees.
I used the example of remote work as it appears to be the most common “best practice” example to show how unique contexts require unique practices. To me, there’s no such thing as best practice. I always do a health check for any practice, X-raying it with common sense and pragmatism. If someone wants to consider copy-pasting a best practice to their organization, they need to do a research checking in which context has this company they’re copying a best practice from has used it, which culture does this company have, and how close the culture in the recipient organization is to the culture of the practice-donor company. And, as with remote work, how well-thought and tuned for the remote work your processes are. Trust is good, but it’s not enough sometimes, as the case with Yahoo shows. With the intrinsic looseness, trust will be tested by swampy slackness , as people might simply lose their gusto and cutting edge for the work. Soldiers in the troops do not stay scattered. They are out in the battlefield, together, fighting for the real thing. It’s only when they have their mission completed, then they can relax and get remote from each other.
Which other best practices can be questioned?
Why Self-Organization Is a Luxury
Retrospectives, Part 2: In a Sentimental Mood
Joy Spring and Estimated Deadlines
Getting Closer with Remote