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 not 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 the 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 know. 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.
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.
We use Slack as a team collaboration tool, and it displays cheering messages on load screens. Such as, “What good shall I do today?” or “You got in, and day just got better”. One such message from Slack inspired me to write this post. The message goes like this: “Remember to get up and stretch once in a while”.
There’s no doubt, that with the bulk of our days spent at our desks, we do need some sort of stretching. It’s hardly that any IT worker, or knowledge worker, will question the need to exercise and to keep fit. Media advertise lifestyles where some sort of physical training is a must. So, if we don’t want to be labelled as “couch potatoes”, or if we lack movement, we naturally want to compensate for that. Many years spent studying, and then working, and sitting all the while, require some sort of compensation. At one point or another, any sedentary worker will want to step on the path of exercising. It seems, what can be wrong about it? Everyone is doing this, and it feels so great to exercise! The devil is in the details, as usual, and I want to outline the trend that I currently observe with some of my colleagues, and which, actually, I observed earlier in my own life. This is not a wellness blog, and this article is not about wellness and keeping fit. It is about keeping ourselves sustainable for doing our work in software development. It might sound as a bummer, but if we put too much of our personal energy into exercising, this will not only be of any good, but it will, in fact, sabotage our productivity.
It’s quite hard nowadays to resist following the lifestyle that media impose. We are told to go jogging, or to ride a bike, or to be a triathlete, or to run a marathon. I’m 100% certain that everyone who will read this article is either doing these activities themselves, or has some friends that do. Now, here’s what the trick is. As I was able to observe, people usually start out with their athletic pursuits after they lack physical movement for many years. It’s as if they are let loose from a leash, and it’s a euphoric experience, to feel yourself moving, exercising, pursuing, being an athlete. Until there comes a time when you realize that this euphoria is not endless, and investing too much effort in exercising backfires, and backfires hard. That was the case with me. In my late 20′s I felt some sort of itching to exercise, and I started out with jogging in a nearby park (on concrete, and jogging on concrete is a knee joints killer, no matter how hype your sports shoes are, but that’s a whole other story). Then, I really got into tennis and passionately devoted myself to mastering this sport. I’m a stubborn and persevering girl, and if you’re serious about doing tennis, you need to keep yourself in good physical shape. So, apart from my tennis practice, several days per week, I did jogging, went to the gym, did some tennis-specific workouts, and I used to have 2 or even 3 training sessions per day (!), and I was doing this in parallel with my day job. Everyone cheered me, because it’s a commonplace belief that it’s such a great thing for knowledge workers to exercise. I managed to maintain this regimen for about 7 years, until at one point of time I realized that I can’t do this anymore. Instead of being a joy, playing tennis — this most beautiful, graceful, smart and elegant sport ever — turned into a dull burdensome chore for me. Besides, my health deteriorated, and this prevented me from doing my best at work. I realized that I need to make a choice, and since I had no intention of becoming a professional athlete, I terminated my tennis practice for an indefinite time. Someone might say, come on, you can just play leisurely, once or twice in a week! The point is that with this fatigue from overexercising that has accumulated over those years, I’m happy and comfortable with this indefinite break. Now I exercise as I swim in lakes (no chlorine for me, thanks), or go on walks, and my favourite way to exercise at the moment is to walk barefoot in a park, on a grass lawn.
Why I’m telling this story? Ironically, I see that some of my colleagues in their late 20′s experience the same curve of being fatally drawn to exercising. They suffer from injuries, but still exercise, as if butterflies drawn to a fire. Everyone lives their own life, and it’s their journey. But I can clearly see, and I can tell from my experience that overdoing with exercises is not only harmful for health. It switches focus from work to exercising. If you have friends who show these symptoms, try to talk them out of the exercising madness, if they agree, and help them look at their life from the perspective of holistic personal energy management. There’s a great book that can help with that. We don’t need the overstrain and depression from exercising ourselves to death. This is not a war, and there’s no way that someone will put up a monument on our grave for that. We need some sort of light activity, and it’s a matter of personal preference. As for me, I’d rather prefer not to expose my spine and joints to unnecessary physical load. Sitting in a chair, no matter how ergonomic it is, is bad for our spines, so I’m particularly sensitive about all things spine, and I’d rather do some soft exercises, such as yoga postures, or stretching (I’ve got the whole baggage of cool tennis stretches from the years of my practice :), or use a fitness ball. Or, walk and swim. Skipping, biking, or, God forbid, jogging on a concrete are my least preferred kinds of physical activities. Another bottomline thing is that the healthcare bills are not ethereal. They are real. So, if we do not want to end up being healthcare bankrupts by our 50′s, it’s better to use caution about exercising as early as in the 20′s, or at least 30′s.
Last week-end I had a flashback to this do-or-die exercise mindset. I was walking barefoot in Delaware Park, enjoying the feel of grass and fresh air after the rain, the landscape was so serene, and there were not too many people in the park. Then, I saw a massive guy, who was obviously doing some sort of plyometric training, running uphill in sprints. He was huffing and puffing, and, as I sat nearby, I could hear some hard-and-push music from his earphones. Well, his huffing and puffing was actually breaking the serenity of the moment, but I could definitely empathize with this guy, because he reminded me of those days when I used to be like that myself. Then, after a while, the guy was done with his training and, as if sensing my discomfort, said to me as he passed by: “Now you can have it all to yourself”. I laughed and said: “I hope your workout was good!” He didn’t answer and looking at him one could say that he was rather exhausted than happy and filled with energy after this workout. Then, I proceeded walking barefoot around the loop of the Hoyt Lake, and spotted a beautiful piece of street art as I went:
Now, tell me, who do you think felt recharged and re-energized on Monday? Me or that guy? The answer looks obvious.
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.
Any information in the world falls into one of the 2 categories: it requires some action on our part, or it wants to be consumed (or browsed). The job of a UX designer or an infoviz/dataviz specialist, then, is to create UIs or pages with one of these goals in mind. If we want to subtly nudge users to browsing more pages in a passive mode, the design logic needs to be built just for that. If we want to help users act and save their time, rather than make them hang out on a web page, then the page layout or user interface has to take that into account. I will show the difference between these two kinds of logic based on the list and grid infoviz patterns from a news hub and from a project management tool.
It’s quite common nowadays to display news as a grid of tagline+image sets, maybe with a mouseover text. Here’s one such grid:
If we think about it, this image+headline+mouseover layout is used with one major goal: engage users. Make them spend more time browsing the news, move mouse over images, check a few headlines, click on an image. Once a mouseover text is displayed, it’s an easy-lazy thing to get to the full view of the news, with advertisements, videos and social comments. The grid layout, thus, appears to eat more of users’s time, luring them with this ease to click and to browse. In general, if we lay this whole “engagement” thing aside, reading news is a passive online activity, and it can be completed rather quickly. So, if someone wants to scan the news, rather than get stuck in them, they wouldn’t want to hover mouse over those pieces, checking for the clues. The grid layout in the news appears to be more “engaging”, as they call it, but it loses in terms of time spent vs. value gained. I mean, what if I don’t have time to move mouse over those snapshots to find out what’s behind a headline? Busy readers will likely want to just scan the news and headlines. They don’t even need those large image thumbnails. That’s why a list layout scores higher on the time spent/value gained scale. Check this out:
This layout allows to scan many headlines+summaries in one look. Readers are able to decide faster, if they want to click on some news or not, without mouseovers. Apparently, I would want to read more about the cleanup from storms, which left three dead, and I don’t have to hover mouse over an image, as in a kid’s game, to find out what the cleanup from storms entails. That’s why I like the list layout better: it is more respectful of my time. I must give credit to the UX designers of this news portal, though. They have provided users with an option to choose between a list and a grid.
That was the case with passive browsing. A few “active” things available to users on a news web-site would be clicking on an ad (the more time they spent there, the more likely they are to do that), posting a comment and/or sharing news in social networks. That’s the logic behind the grid design in case you were wondering why such a draining layout — that’s how it looks to me — should ever be used in the news. Another handy example of grid slowing us down is… our desktop. Often I just save stuff to my desktop, files, snips or images, and when I want to find something, it takes more time and effort to move eyes between thumbs, as compared to using a list or search.
Let’s now consider the logic behind the list and grid/board layouts in a project management tool. The UI of such a tool must encourage users to spend time productively. It might seem a stretched parallel, but in some ways board/grid is less efficient for project management as well. Lists will work better when it gets to managing bugs, for example:
If someone in charge, a QA manager, or anyone else, will want to create a living display of bugs, tailored for hands-on work, it would be such a list. Apart from the compact layout, the list has inline edit for most of the fields, and it’s like with processing fish: bug details can be updated faster than in a grid view. Besides, the very columns in this list are customizable; one can choose which column they want to see and which not. Now, what if this person in charge were to work with bugs displayed as a grid? Check this out:
As with the news portal grid, one has to move mouse over bugs for more details, e.g. to check on a bug’s severity. This grid layout would be a plus if I had time to leisurely contemplate which card might mean what, but if I want to change a bug’s status, assign people, or update tags, I need to dive further in *sigh*, click on the bug card and work there. The grid layout does not allow for quick scanning of the bugs and quick editing/updating. But it would be optimal for changing states as they do on a Kanban board. Thankfully, this project management tool allows users to switch between views when they want to do whatever they want :)
I hope these examples helped reveal some logic behind designing information layouts for various purposes.
Success in software development business depends on an intricate fusion of optimized individual performances, be it for a C-level executive, or for a junior software developer, QA engineer or UX designer. Naturally, stakeholders want to drive business results to the optimum, using the leverages they can control, as they are looking for the ways to foster productivity of teams and individuals. In the end, it’s people who take decisions, come up with creative ideas and make working software. That’s why it’s so important to design a harmonious workspace that helps people feel good and deliver their best work. Enough has been said on how stressful environments strangle performance. A stressful environment, the way I see it, covers not only work, but lifestyle-related stresses, such as tedious commutes, being a parent to a newborn or overspending energy on a pursuit unrelated to work. Employers pretty much have no control over such things. A sensible employer will surely be aware of the impact they make on productivity, but these are life choices that people make, when it goes about babies and hobbies; it’s a matter of personal responsibility. Commutes can be controlled, partially, either by setting up an office in a favorable location with decent standards of living and reasonable population density, or by allowing remote work. What stakeholders can control completely is workspace. Rather than brooding over utopian surroundings, it makes sense to focus on the things that can be improved in your office.
That’s exactly what we do in our company, Targetprocess. We are in product development, and this implies that enhanced creativity and optimized individual performance are essential for the company’s success. In this business the price is too high if people are coming up with faulty solutions, on all levels. We simply cannot afford being downtrodden by a dull office environment.
A well-thought-out workspace can help a lot with these 4 things (or activities):
#1. Informal exchanges
Very often, if not always, discussions on work-related issues occur anywhere but at a scheduled meeting. Such conversations can bring along some good ideas, from our experience. That’s why Targetprocess office has been specifically designed to encourage these informal exchanges. The office is made up of 3 round towers, and we have a lounge dining area in one of the towers, the Green one, where we carry free buffet lunches. There’s also an espresso machine with a counter, and this lunch space has snacks and supplies. This environment encourages people to talk and share ideas. Here’s a map view of our Green tower (we also have the Blue tower, and the Orange tower, the space takes about 11,000 sq feet in total):
The other two towers have coffee counters in the center, with bar stools and a cooler/heater nearby. Everyone is welcome to stop by, sit down and discuss something.
Another thing that we have in place to facilitate informal exchanges is a no-cubicle setup. Some of us had previously worked at companies with huge open spaces, which would be another extreme. Of course, people can talk freely when they sit in one large room, but the noise and distractions are horrible. So, we’ve arranged something in the middle and remodeled the original space in the towers as “slices of a pie”. Check the snapshot of the Blue tower:
These pie-slice rooms hold comfortable workspace for our feature teams. Each feature team is cross-functional, and includes software developers as well as QA engineers. They usually develop one piece of our product’s functionality. This workspace arrangement is more favorable for our development process than a maze of 50 cubicles in one open-space, looks like. And, of course, it fosters informal exchanges in feature teams.
#2. Focused solo work
This kind of work can also be facilitated by office space. We have silent rooms, with a lounge chair or a couch, available to anyone who needs some time alone. One of these rooms is located in our office library. A UX designer, or a software developer, or a company stakeholder, or anybody else can walk in to the library (we have 300+ books and counting), pick a book from a shelf, flip through the pages, sit down in an armchair nearby and get some insight. Actually, a library is not only a part of an office space. It is a part of our continuous learning culture, which is mega-important to us as a software product company. Here’s a picture of some bookshelves in the library:
#3. Visual aids
We believe in the power of all things visual. Nothing facilitates creative thinking and problem-solving more than having a problem sketched, visualized, diagrammed and dissected. Also, nothing can give a work status report faster than a crisp visual dashboard. That’s why our office sometimes reminds a school with many classrooms. We have whiteboards in every pie-slice room, and we’ve also used IdeaPaint to turn some of the walls into the renewable sheets for jotting down ideas, software architecture maps and what not. That’s how we visualized our production roadmap on an IdeaPaint wall a few years ago:
A large digital screen is another tool that helps a lot with visualizations. Just one example, that’s how we feed the status of our production builds to a screen:
This whole visualization philosophy is very strong with us, and since our product is a visual management tool, we have many screens with boards in the office.
#4. The sweet things and “feel good” stuff
These are the small things that do not directly contribute to productivity, but help brighten up the environment and make it happiness-oriented. Imagine, after a dull commute in a rainy day, or after a night of bad sleep you walk in to your office… and this charming cat greets you :)
This cat is a very influential guy, by the way. We use it as a token to identify who is in charge of automated test runs. The cat obviously feels some affinity with deer (this picture was taken at Christmas time).
It somehow happens that our employees care about the space around them. Such small things do not appear in the office by an executive rule. People use their own creativity to make their workspace vibrant. Take a look at this custom artistic installation at a QA engineer’s desk:
I believe each and every office can come up with things like that. Such DIY craftworks create a cozy environment at work, helping people feel relaxed rather than stressed out. When everyone is focused and still relaxed, that’s when the real good work happens.
There’s yet another dimension to office environments. Workspace can be improved not only with furniture, or artefacts, but emotionally. Harmonious emotional spaces facilitate improved individual and group performance as much as harmonious room spaces, if not more. But this would be a subject for another article.
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“.
If you’re using Kanban board as a process tool in software development, you must know that Kanban is mainly about letting the work flow through the production states.
Pull some work from backlog, get it through the pipeline and on it goes.
Kanban is great, but it desperately lacks one thing which matters a lot in this world plagued by time constraints. This thing is called a sense of time. If a team does some cross-project work, as they pull smaller items from a support requests backlog, they will likely want to be informed not only of a current state of a work item. They will want to know when it is safe to assume that this work item will be done, or passed over to another department, etc. Trying a workaround to include this sense of time to a physical Kanban board on a wall might be a cumbersome task. Take a look:
This board has a mention of a milestone, Nov 9. The stickers are to-do items. This workaround just informs of a fixed milestone, and doesn’t take the production dynamics into account. There’s no way to give a forecast from this board, if the team will complete whatever their work is by November 9, judging by the pace with which they progress. Not to mention that there’s no way to see at which pace are they progressing. There are some Kanban reports that can help predict that, but they will not be available in a whiteboard, obviously. This might work for this team, but some other hypothetical team will want their Kanban board tailored to their time-sensitive objectives in a different way. And they would need to sweat and invent specific workarounds, if they need more than just a date written on a board.
We’ve always wanted to help our brothers sweat less at work :) .. and we’ve been well aware of this need, that timelines should be somehow intertwined with Kanban boards. The project management tool that we develop supports Kanban along with other dev processes, and our on-going goal is to make the tool still more convenient. That’s why we’ve implemented timelines that can now be used in combination with a digital Kanban board. We used to have a paper timeline on the wall, too, but this visual roadmap is more of a thing that creates the spirit of common purpose, than a hands-on tool. The Kanban+timelines combination can be used to see how teams are doing with their work, and in what time they expect to complete it. That’s how this Kanban+timeline board might look (click to enlarge):
There are two projects on this board, and there’s a backlog for each of them. Alternatively, there can be a shared backlog (our tool supports that as well). What goes next are work items laid over a stretch of time. Where the strips end is the current forecast for “Done”. The timeline can accompany the traditional Open-In Progress states on a Kanban board as well, if that’s what someone needs. Again, no sweat here, one can quickly set up a custom timeline+Kanban combination in our tool.
Having a timeline available as another option on top, or instead of a Kanban board, helps make sense of what’s going on with the projects in less time, pun intended. Besides, timelines keep the sense of time always present with a team (which they might be missing if they only look at a plain Kanban board). It surely is less hassle to maintain the digital Kanban+timeline board, and any stakeholder who is not immediately involved with the team’s work will quickly get an idea of what’s going on with the projects. There’s no limit to this digital timeline, and as to how it can be fit into a screen. Just make sure your screen is big enough for it :) For smaller screens, the scroller — at the bottom right on the screen above — will navigate you through unlimited sands of time.
It looks to me that adding a timeline to Kanban board is more of a burning need, than a luxury. If you want to try timelines combined with the Kanban board, click on the circle on the right.
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.
Today I want to tell more about our *relationship* with bugs, fixes and smaller work. The way a software development company prioritizes their backlog depends on a number of things, and I will give an example of how we’ve explored various solutions to address the changing priorities. There’s never one single “How to prioritize backlog” recipe, and I want to caution everyone against blindly following a practice that worked for someone else. In each particular case, everything depends on the current context in which company finds itself at any given moment: how many developers are there in the company, how many customers, which strategic priorities does a company have. In short, smart pragmatism is the only universal tool that would help tackle a specific business challenge, not a ready-made “how to”.
The Product Backlog: New Things and Fixes
Speaking from our experience, product backlog usually includes the following 2 groups of work items:
-new features (or some fundamental re-work for the existing features) which require at least 3-4 months work for 5-6 developers and QAs
-fixes and reworks to existing product features (based on feedback from leads/customers, and from the team)
In Targetprocess’ 10 year history there was a time when one product owner prioritized backlog both for the new features and for fixes and reworks. When we were a relatively young company, the product owner’s main focus was on the new features, and the smaller fixes and re-works for existing functionality used to be tucked under the rug. The limit of items allowed in the Planned state on our Kanban board was 20, and the clean-ups were triggered by the following logic: “Hey, we’ve got a lot more than 20 items in the Planned state! Hmm… we actually got 50 bugs there! All of them are small bug fixes and enhancements, so let’s just pull them from the backlog and fix, whatever whoever wants”. So, developers would pull the bugs, fix them and a new build would be out. This practice worked well, but there was one link missing.
The Imbalance in Controlling a Backlog
With time, we’ve had more customers and more functionality in the product, which meant more areas where fixes and re-works begged to be done. Some people in the company who interface with customers and absorb their requests (or complaints) started feeling the pressure, and they wanted to do the fixes that a product owner wouldn’t consider that important. It’s not only about the pressure, of course. Customers’ needs must be taken into account, because they want the product to work better for them. And product owner wouldn’t get a clear idea of how crucial each small request was, from where he was sitting. The disconnect between “request points of entry” and “control over backlog” became too obvious at one point. We still had one product owner controlling the backlog, and he prioritized it as per his vision. He did have an idea of which things are most requested by customers, of course, but the new functionality would still get a higher priority. The ultimate clean-up days, where developers would pick and fix bugs at random, without knowing what customers want, were not of help any more.
We then understood that we needed a new approach to handle those smaller bugs and reworks. The backlog now had to be prioritized not only by what product owner had in mind, for the new features, but based on the priorities that were defined essentially by our customers and leads, in their exchanges with the product specialists and with our support team. Besides, the new functionality also needed some re-works, and we had split opinions on what’s more important and what should be done next. Something had to be changed in terms of backlog ownership. A person (or the people) who would control the backlog needed to be up-to-date with the priorities as identified by multiple contributors: product specialists, support team and product owner (or, later, the product board).
Who Will Do the Bug Fixes and Smaller Re-work? The Emergency Team
On the other hand, we realized that we need a dedicated task force for those re-works, not just clean-up days. That’s when we formed an Emergency Team. At first we used the rotation principle for it. Each of our Feature Teams would act as an emergency team for 2 weeks. Then, at one point, it became clear that a simple rotation is not a good idea. It takes time for teams to fully get settled in the context of their work, and as the team is formed it idles at first, just like an engine, and then gains speed. The rotation assumed that exactly by that time the team had to be switched. It appeared that mere time-boxed rotation ignored this important nuance, so we decided to have a permanent emergency team. The emergency team, in our understanding, was supposed to work as a point of entry for new developers, so they could know the codebase better. However, we didn’t get into account that newcomers needed to check on some things with the “old” developers. That hindered the work, and we eventually switched back to ~1 month rotation principle. One month seems to be a sensible time for the emergency team to gain and sustain the optimal productivity momentum.
The backlog for this Emergency Team was at first prioritized by product owners who would rotate weekly. One week that would be one of product specialists, then someone from a support team, then a product owner or one of UX designers. Then we realized that one rotating product owner is not working well. This person is not able to keep in mind all the priorities. Now the backlog is formed from 3 queues: Support, Product Specialists and Product Owner AND this work is prioritized at a meeting with emergency team lead developer, product owner, product specialists and support. Roughly, each of the sources has 25% share in the Emergency Team backlog. Currently this team is doing small things to improve the product on-boarding experience for potential customers, and they did the print cards functionality in the recent 3.2.4 release. For comparison, features teams are working on large features such as timelines or lists.
We write a lot in the Edge of Chaos blog about visualization, and how helpful it is for project management, problem-solving, strategic thinking and learning. No matter if you’re an executive who wants to contemplate a business challenge from various perspectives, a software developer, or a strategizer, nothing can be as handy a tool as a pen and paper (or, in some cases, a digital screen) to hone your ideas and give them a finished touch. Visualizing ideas helps to drive the point home not only with yourself, but with the others, if you want to make sure that they understand what you mean.
Let me share some of my favourite ways to visualize ideas.
#1. An XYZ Coordinate System
I like this way of visualizing as it helps to build mental models that show how 3 factors might influence one another. Yes, they have 2D coordinate systems, X and Y, and I do use them, too, but in the complexity of today’s world where more than two factors often have to be taken into account, 3 D visualization might work out better. Here’s the image that I used in one of my articles to explain how backlog management can be done with 3D thinking, as opposed to 2D (backlog and work in progress). X-axis is work, Y-axis is progress, the X-Y plane is any work in progress AND Z-axis is any other 3d dimension, or a lens, through which one can filter the backlog or work in progress. The red lines in the Z-plane against the X-Y plane represent those various influences, or filtering criteria. The artistic execution might be far from perfect, but this image did help me express my idea better and pass it on to the readers:
#2. 4 Quadrants
I used this visualization to explain a decision-making technique. While the XYZ coordinate system provides some kind of 3D space to a concept, making it concrete, the 4 quadrants can be used to break abstract concepts into pieces. It might be helpful, for example, to write out 4 major areas of concern about a problem or a challenge, look at them and drill them down to smaller resolvable issues. This technique helps to think clearly.
#3. Overlapping Circles
I somehow feel that this pattern have been overused to visualize a very simple overlap of 2 concepts, e.g. one circle stands for “good”, the other stands for “bad”, and the overlapping area is the mixture of good and bad, which is kind of obvious without using circles. So, I’m not very fond of this practice, because it looks a bit trite, but I did use it several times, e.g. to show that business meetings are made up of 3 essential components mixed as in a bowl:
#4. Mind Maps
They work well to connect the idea nodes and summarize the concepts that someone already knows well. I’ve written the Mind Maps in Cognition article which suggests some points on when it makes sense to use mind maps, and when not. Here’s the mind map that I sketched as a summary of knowledge that software product owners need to have:
#5. Custom Spatial Objects
That’s the visualization that I used to explain the idea of a new paradigm for project management tools. I had a sketch of this idea on paper, but this time someone helped me with a nice image:
This molecule glues the core paradigm to the other paradigms, rotating and gaining various momentums, depending on where they find themselves in space at any given point of rotation. The rotation is a symbol for changing goals and organizational environments, and the way they influence project management tools.
#6. Sketches in Moleskine notebooks (no grid lines)
I find this especially inviting when a sheet of paper has no grids. This freedom of paper space somehow encourages the freedom of thinking. An A4 sheet of paper does not do this trick for me, because a Moleskine notebook has pages, that can be flipped, and they can be kept for future use as a collection. Also, for some reason I like to start sketching on the right side of the double-page spread, and then continue on the left one, same way they do when they write in Arabic. I do idea sketches for my articles this way sometimes. Here’s the idea sketch for my recent article Visualization: Why the Fusion of Arts and Tech Matters:
Any UX designer wants to create a software tool or an app that would appeal to users. Designers employ various techniques and practices to emulate users’ behavior or to define user behavior flows, and it’s a common belief that these techniques are all they need to design a successful product. However, there’s one cornerstone to all the things UX that often remains neglected, as I was able to observe. It’s hardly that the techniques alone would take UX designers to where they want without this essential base. I’ll try to shed some light on what that is.
It seems that UX design practices can be roughly broken down into the following:
- Designer toys
- User mirrors
- A mix of both the above
Let me explain. What I call “designer toys” are the techniques that designers commonly use to better define their own vision of how users will behave inside an interface. What I call “user mirrors” are the techniques used to gather evidence, factual or intuitive, of how users want to behave in the context of a user interface. These mirroring techniques include all kinds of A/B testing, surveys, etc., and it is assumed that designers exercise empathy with users.
With the mix of designer toys and user mirror techniques, the outcomes of A/B testing and feedback from users are taken into account for new design versions. Having received certain signals from users, designers then use wireframing, personas, storyboarding, Design Studio methodology, a pinboard for design ideas, sketching, paper prototypes, etc. This mixed approach will be mostly required to improve an existing product or an app.
However, those many techniques fall short in the face of one ultimate deal breaker (or deal closer). Interaction design, or user interface design for that matter, is supposed to facilitate interaction between a user and an interface in a context shared both by a user and a software product. A friend of mine puts it that way:
The hows will appear if the what becomes clear
No sketching or wireframing technique will ever help communicate the strengths of a product or an app. If users act in the context that differs from what is implied by designers, or by the whole product dev team, it’s likely that subtle UI perks and niceties will hit the barren ground. A very drastic example: can you imagine a pre-historic human using an iPad? It took millions of years to bring this living being to the context in which an iPad gives a clear “what”.
On a softer level, Facebook was able to hitchhike along with users because everyone wanted to stay connected to their friends online. It’s a whole other story that now, after about 10 years, we’re witnessing the opposite trend, and Facebook is in decline.
So, the ultimate thing that makes for a success of a product would not be a user interaction design, or UX design. This whole user+product=love thing can only happen if users and product makers share one vision. It’s very *cool* when one only needs to analyze the needs of users who act within one established paradigm of thinking. Things get a lot more exciting when the vision that a product team brings into the world is innovative, and users are not yet fully aware of what this product can do for them. In this case, playing with designer toys will resemble shooting at a target randomly in sheer effort to hit the bull-eye. It won’t work. User vision design comes first, UX design goes next. UX design is more of a technician activity, because once a shared vision of something exists, people usually do not make any big difference with their designs, they mostly borrow tricks from each other and follow each other’s steps.
Designing user vision is a whole other story. It involves having a clear product vision in place with the insiders (product dev team/executive/designers), and their ability to communicate this vision to the outsiders. Insiders need to come up with compelling proofs of how their product helps people do things better/easier, from a totally new perspective. Social sharing apps capitalize on the designed user vision that social sharing is hippish. Another case of user vision design is promoting Big Data as a panacea for organizational problems. Agile software development methodology has produced a vision for users as well. I can go on with more examples, but you get the idea.
UX designers need to keep in mind that successful design goes far beyond graphical or interaction design. For innovative products, it also includes user vision design.
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?
How to deliver more value faster? I’m constantly thinking about speed in software development. This article is a result of my thoughts. I built a model that describes all obvious and complex dependencies between software development practices and briefly analysed this model. I hope you will find something new and enjoy the read.
“Every single CEO of any IT company wants to build software faster. Time is the most expensive and valuable resource. You can’t waste it on re-work, refactoring, meetings, physical activities. Right? It depends…”
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.
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.
A simple tale of how we created Targetprocess, the visual project management software.
It all started back in 2004. In those days only a few people in Belarus had heard about agile and almost no one actually used it for their work. Iterative development, what the heck is that? Pair programming? TDD? However, at one local software development company where Eugene and I worked, we had a chance to try Extreme Programming for one of our internal projects. As a side effect we needed a software tool to manage such a project. During that time there were several horrible free tools and a few paid ones that were ridiculously expensive. We thought to ourselves: “Why don’t we make our own XP project management tool?” as many programmers at that time must have. For us, this single question turned into the concept of Targetprocess (the very first name was SWIPE — Sprint Web Integrated Process Environment).
A lifecycle of a software product looks similar to that of a human. In the beginning, products are like toddlers as they can do very few things. Then they learn to walk and to talk, then adolescence comes and then maturity. Who is a parent to this child, then? Who helps it stand up and walk, who provides the support? Which environment is needed by a software product to thrive and to grow from a toddler to a teen, at least? There’s one answer to these questions: a vision that the product’s masterminds share with the rest of the world. No doubt, parents are supportive of their child. But the rest of the world might be completely at odds with the product’s idea, and no matter how great it is, they will not appreciate it fully if they’re not able to comprehend how it helps them.
A striking example of such a gap — though unrelated to software products— is the story of rocket science and its founder, Konstantin Tsiolkovsky. This man had a vision of cosmic aircrafts flying into the outer space as early as at the end of the 19th century. Back then, hardly anyone could have believed that it’s possible at all. It took a better half of the 20th century for the rocket science to get a sufficient pool of followers, as space missions turned into a fascinating reality.
Something similar stands true for software products. If they are born and grow up in a soil fertilized by a mainstream vision, they are lucky. I’ve written before that Targetprocess, the project management software that we develop, was planted in the agile methodology that has been on the rise in the mid-2000′s and continues to live now. However, with time the vision behind Targetprocess has been transformed. We were restless, and sticking with agile forever didn’t seem a rewarding thing, so we forged ahead and now our product has another vision behind it. It still fits into the Procrustean bed of Scrum, XP, Kanban and other agile methods, as we’re paying our dues to the school where the product has spent it’s infant and adolescent years. However, now Targetprocess has graduated and became Targetprocess 3, the visual management software. This baby has moved so far away from the shores, that it finds itself solitary in the challenging waters of the raw ocean now. Agile is a more familiar vision, and most vessels stick to familiar shores, while we are out in the ocean largely by ourselves. Now we are trying to bring the rest of the world up-to-date with our vision of how amazingly helpful and simple the visual management can be for any project-based work in software development or in any other domain.
Now, as with any sailing in dangerous waters, there can be risks, or, if we continue to compare products with humans, there can be diseases. It appears that the gravest disease that can be acquired by a mature product is called featuritis (akin to arthritis, a disease that immobilizes). This disease might befell an innovative product or a device if its creators forget that the rest of the world haven’t yet fully grasped how cool their baby is. Pasting their subjective creative reality on potential users is a common cognitive bias with products’ parents. I wish we lived in a world where new visions and concepts could be shared telepathically, but this reality is a bit different. If users do not see this awesome vision, this awesome new way of doing that thing they need to do, they’d stay alienated. Here’s the diagram (source) that illustrates this phenomenon:
It’s easy to fall prey to the insidious featuritis. Just as with individuals, who carry their vision about themselves inside and don’t bother (or don’t have enough time) to share it with others, the unspoken vision behind a product could be a potential source of insecurity for products’ creators. The relentless inner pursuit is not enough, another essential piece is to share the vision. Look at how people live. More often than not, instead of being confident about their unique purpose in life and sharing this vision with others, they think that something is innately wrong with them, so they want to add more “features” to themselves, especially if everyone else seems to have these features. It’s not the features that others would buy into, though, neither in fellow humans, nor in software products. People pick up and stick to a shared vision and purpose. On the graph above, the part that goes prior to Happy User Peak is in line with the vision that a user has. The descending part of the curve shows how users fall behind with the vision of a featuritis-stricken product.
There’s no better cure than prevention. For featuritis that might befell an innovative product, this prevention consists in building new islands, or even continents of the shared vision, where users would find their safe harbor, just like the Pilgrims, and stay for good. Another reason why it’s so easy to catch featuritis is that the development team is eager to deliver more new features, as they tend to mirror a product’s image on themselves. It’s not about features and the development team, however. It’s about those inhabitants of the old continents that need to be guided to the new lands. This whole process of other people picking up on the new vision can be quite lengthy, as was the case with Tsiolkovsky and the rocket science. Fortunately, things seem to happen faster with software products. Slow or fast, what matters most is bringing people up-to-date with the vision and letting them see that it works.
When we speak of visualizations or visual management in technical or project management domain, visual arts hardly come to our mind. Information visualization, or data visualization is one thing, and visual arts is quite the other one. However, there’s a certain point where those two intersect, and in this write-up I will show how visually appealing displays of data or information differ from dull graphs, tables or reports.
There are two basic environments where any visual display can possibly exist: time and space. For visual arts, space is the environment. Arts come into the picture (no pun intended) as we look to portray a physical object or a group of objects on a painting, or as a sculpture, which is also a visual, albeit tangible. This might sound like a paradox, but ethereal visual arts are more down-to-earth than they appear as they can’t live if there’s no tangible 3D object that has to be rendered into a visual. This powerful painting depicts a very dramatic event happening in the physical world, as people try to save their lives and face the ruthless ocean and skies which however bring a tinge of hope with warmer colors.
The emotions that this painting evokes help it leave a certain footprint in our minds and hearts. Like, even in the hardest times the hope is always there. The painter uses art to make this very important message go home with us.
How is then a visualization different from a painting? Visualizations deal with abstract concepts as opposed to physical objects. Ironically, the dry technical reports are supposed to bring the ethereal and non-tangible things to being tangible. Timelines, as a method for visualization, represent a time-oriented display of concepts or data. Other ways of visualizing concepts and how they connect with each other include mindmaps, lists and boards (or dashboards). Think of to-do’s and to-do lists and various ways that we have to visualize them. A to-do, a task or a project is an abstract concept as well.
Why should this matter at all? John Dewey has something to say on that in his essay “Art as Experience”:
Art appeals directly to sense and the sensuous imagination, and many aesthetic and religious experiences occur as the result of energy and material used to expand and intensify the experience of life.
Of course, we are not talking about religious experiences here. But all of us are looking for the ways to make our intuition and creative abilities work at their best as we are search for a solution to a technical or an organizational problem. The cutting edge of brilliant performance with data insights and analysis is so elusive and so sought after that we hopelessly give up, thinking that it’s not us, but someone else who has this ability to take a brilliant decision backed by intuition. Look into this quote from the John Dewey’s essay closer. The key is: appeals directly to sense and sensuous imagination. If a timeline, or a list, or a dashboard is visually appealing, then an analyst or a stakeholder will not simply spend less time on grasping the overview, but will be more likely to generate a crucial insight or take a well-rounded decision as the visual nicety will contribute to that by itself. I’m sure there is some scientific research nowadays that backs up this argument in terms of neuroscience. The bottomline is: there’s more pragmatism in art than one can imagine. If we surround ourselves with artful things, be it in our office space, or in our digital space, we’re more likely to perform better as decision-makers, stakeholders, or analysts, or as developers and QAs, or anyone else who uses visualizations in their work.
Most software development companies measure productivity of teams and individuals. Those measurements are then used to rate the individual or group performance. Numbers are so nice, cozy and familiar. They make things simpler; and if someone’s productivity can be objectively rated with numbers, lucky is this person and lucky are the managers of this person. This person is lucky because the clarity of numbers backs the clarity of expectations, and if someone knows that they may get a raise if they hit a certain number of whatever, that’s great. Managers are lucky because they are spared the need of figuring out how the heck to rate people, so they can be given or refused a raise, or a promotion, or a reward. However, in some cases mapping the actual value of an individual’s productivity and contribution to numbers might be challenging, if not at all unattainable.
Let’s look into the reasons why individual productivity is measured by counting things. This habit can be traced back to material production, or to any activity to product tangible things. If a farmer picks 100 vs. 50 cabbage heads per day, just an abstract example, this is surely good. One can not let a cabbage that is ready to be harvested sit for too long out in the field; it may fall prey to some pests, etc. With cabbages it surely makes sense to move fast, if we’re concerned with harvesting solely. By the same token, a baker who runs a bakery on a busy street is more productive if she bakes more croissants. The logic is flawless: more croissants, more customers served, more profit.
With this measurement model looking so clear and simple, it’s very tempting to copy-paste this practice of “more is better” to knowledge work. The non-material production. They used to measure productivity of developers by lines of source code produced per certain amount of time. I wonder if someone still uses this metric. One smart person has something to say about it.
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
Other equally poor attempts to measure productivity include: count of bugs discovered by a QA (what if this person tests the heck out of a feature, making sure it’s clean, and finds no bugs?); the count of words in a written piece, or the count of graphic icons designed per day. These are abstract examples, and, thank God, it looks like most of the software development companies moved away from those naive metrics. The less is more adage is grasped better now, when we seem to live in the age of super-abundance of everything (which doesn’t save us from the chronic shortage of value).
That’s the word. Value. How much shippable, valuable, finished work has this person done? Working many hours is far from being equal to super productivity and, after a certain point, indicates inefficiency. What I call “productive” is when one uses time in the office wisely, rather than works around the clock. Then, which contribution is this person making to the group? What does he or she do to improve the workflow, or to keep the integrity of the team? Naturally, being a group contributor means that this person is biting some bits off of their individual contribution. What if this person contributes at a larger scope, beyond their core skill? Then, how to factor in the subtracted individual performance when measuring productivity?
With these intricate nuances, I wonder if someone is ever able to quantify them and use it as a numerical measure of productivity. Surely, the kingdom of tests and grades has its doors always open, as it attends to the needs of busy managers looking for fast and clear ways to rate a person’s performance. But, as often is the case, the flip side of fast is slow. Individuals concerned with the team’s success are the keepers, and if a numerical grade fails to code the value of this person correctly, they might be demotivated. We all are human, and managers are human as well (in case someone ever doubted that). They want to rate the performance of teams and individuals faster, especially if a company is large. Better safe than sorry, stakeholders better make sure they can trust the scoring methods. Otherwise, it would make more sense to stick to the old-school ways: observe people, what they do, and see if this brings value to the company. We know that it sometimes takes years for judges to be ready with their rulings. It might take what appears to be an eternity for a snail to figure out what’s inside this bubble. A rainbow or gas stains? But the time spent on deciding is well worth it.
Image credits: Vyacheslav Mischenko