In Why Agile Estimates Don’t Work – Part 1 I’ve explained why estimates don’t work if someone sees them primarily as a commitment to timing. And, just as I expected, some aficionados rushed to educate me on the subject of estimates in agile, that they are not a commitment but, in short, a discussion of chances and odds of how the development will go, considering the challenges of this particular production environment. Probably, some of those aficionados have accused me of the gravest sin ever, and namely, not reading Mike Cohn’s “Agile Estimating and Planning”. Relax, guys. I studied Cohn’s book long ago, and time after time I would flip its pages to refresh things in my memories, not to mention other books, articles and from-the-trenches stories. My most reliable source for making conclusions, however, is my work. If someone stays out-of-the trenches and theoretizes about estimates, this is just theory. My view on estimates lies in the practical, pragmatic context: if they don’t work as commitment to timing, but as a discussion of chances and odds, why most companies continue to play this game? What makes them go on with it? Why spending lots of time on discussing chances is valued more than action itself?
What Is an Estimate? (take 2)
I’ve cited two options to answer this question in Part 1. Some people, who are, likely, not educated in agile theory, look at agile as a next best silver bullet to complete projects on time and they might wrongly view estimates as a promise of that. They genuinely believe that agile estimates will give them so much sought after reliable reference point about the time of completion. The second group of believers consciously accepts that estimating is a discussion of chances, a probability forecast. The burndown chart provides such forecast based on velocity. Let’s refresh the classical definition of velocity in our memory, quoting from here: “The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed“. Does it ring any bells now? If we never build the same feature twice, just as you can’t step twice into the same river, then why velocity-based forecast should be relied on? In general, this stands true for all the forecast techniques based on past performance, including forecast models. Yes, there are cases when a team’s work is monotonous, iteration in, iteration out, but from what I’ve been able to observe, it happens very rarely. Mostly, in any company and team, the tasks to be done and challenges to be resolved are unique, for each iteration, and for each release. You never know when something pops up and kicks this neat forecast in the butt.
The Devil Is In…
.. not only in the details. The second most common habitat of the said devil, which goes after the details, is human nature itself. Nothing else explains this better than the good old Parkinson’s Law:
Yes, indeed. Having all the time in the world is loose. It’s either you have time, or you don’t have it. It’s either you have the guts and sixth sense to define what should be included to the minimal viable product, for instance, or not. Let’s don’t forget that no one cares about software development for its own sake, except the software developers who view their work as craft. We do things for the market. For customers, and they don’t care about the development kitchen constraints, challenges and brilliant solutions. Same stands true for UX.
Now, how this reasoning fits into the subject of estimates, someone might ask? Here’s the astounding truth. Teams and companies start playing around and messing with estimate rituals when they have some extra fat to burn. There’s no room for activities that are waste in a bootstrapped, mission-oriented, do-or-die start-up squad of several people. If you are in such a team, and tempted to start a planning poker session, don’t do this. Rather than waste your time on playing with probabilities, get some real work done. Write code, do a UI sketch, instill clarity to the work of your team. Some mathematical forecast model surely has it that a brick will fell on your head one day. But you’d hardly be wasting your time to estimate how many more bottles of champagne are likely to slip out of a torn plastic bag, when one of those bottles has already hit the concrete, and there are 3 more in the bag. You’d rush to catch the rest of the bottles, not to let them slip, right? Or will you freeze and estimate the probability of all of the bottles being shattered? This reminds me of the fact, that some business people who are skeptical about shamanism, astrology and other such things, devotedly indulge into what is, in essence, shaman rituals with estimates. Come on, the estimate of completion based on burndown or a planning poker session, is as valid as an astrological forecast. There’s no big difference. It’s either you’re “fat” enough as an organization to afford wasteful rituals or not. In fact, even in large companies that seem to be so safe and secure there’s always the bottomline point of “do or die”. That’s what a recent story with massive job cut by Microsoft proves. Ritual is a waste. If there’s time for rituals left, this is a sign of unhealthy fat. Burn it. If a workgroup discusses development, there’s no need to wrap it in the ritual of estimating, because when a discussion turns into a draining debate of “how probable” this timeframe is, the work suffers. Someone said, there’s a limited number of brains to do the job, and they should be used efficiently. One can suffice with a draft estimated timeframe, there’s no use trying to gauge on the likelihood of this happening, when there’s real work to be done.
Worship the Idol: How Do I Tell My Higher-Ups ..?
As life has it, however, most of us have to cope with the fallacy around estimates being employees in fat organizations, and, hard as you might, a mere human being can not move a mountain. There’s no way to persuade a higher-up non-developer manager, or a client, or a stakeholder in the vanity of estimates. That’s why people go on playing games, as they attend to those who expect a feature or a project to be done on time, as derived from estimate-related shamanic rituals. And, that’s where another interesting booster for evolution is hiding. Luckily — and, yes, I mean it, luckily — there are more non-developers in the position of authority than developers. There’s always a point of litmus test, when someone with a developer background (a project manager, team leader, or someone in middle management) meets the non-developer stakeholder. Why I call it a booster for evolution? If every stakeholder were a developer, they would have probably ended up whining on each other’s shoulder about how difficult life is, and how impossible it is to commit to any timeframe. Having to deal with a non-developer stakeholder about a deadline is stimulating. If you’ve been thinking that something has changed from the hunter-gatherer times, I have bad news for you. The seeming “comfort” guises the basic instinct to act. You either act, or you rot. There’s no other option. No one cares for reactive rants. It’s your actions that define you. It’s your choice to agree to play the estimate game by the rules and accept this as a given, or to quit and find a job where they will not f…k your brain with estimates. If you choose to deal with ruthless stakeholders that are oh-so-not-understanding of how hard a life of a true software craftsman is, move the conversation from the level of rant to the level of action. Use every opportunity to spread the awareness of the challenges that software development portends, and why this domain is un-deadline-ifiable by nature. Amazingly, there are so many people in this world who sincerely believe that an estimate is a credible measure for completion date. Write articles, speak on conferences, join the “no estimates” movement. Fix the gap between what you know, and what they now. If everyone has their say, this world will become a better place, with less projects and software screwed. And, even if you’d still have to deal with the waste of estimates, you’d feel better inside, because you’d be doing your all to change things, instead of ranting.
Enough of thought boosters (or busters?). In Part 3 of the series I will give an outline of some techniques, commonly regarded as techniques for estimates, that might work as a tool for workgroup discussions in some teams. Keep in mind the waste-value balance, though.
Why Agile Estimates Don’t Work – Part 1
As you read this headline, many things came to your mind, probably. You might have recalled those many hours of meetings as you tried to come up with a time estimate for a project or for a product release. Or, you might have remembered the planning poker sessions, which were intended as a spot-on pragmatic business activity, but in the long run proved to be nothing else than a child’s game, because the estimates attained as a result of planning poker sessions differed 2 or 3 times from what the actual work really took. The sharp question that I want to ask is: how many times did you feel deep inside that when they make you do an estimate (them being managers, or clients, or anyone else in charge), you end up with nothing else but a waste of time, because later in the project you still face the need to explain why your initial estimate proved to be that different from how things actually turned out, and feeling guilty in the process, though probably nothing of it was actually your fault?
Don’t get me wrong. My initial intent was pure and well-behaved. I humbly wanted to write an article to sum up techniques for estimation used in agile, describe their pros and cons, and provide people with a single-point reference for all those techniques. However, as I went deeper into the research, I was astounded. It turned out that there are many more articles and write-ups out there in orthodox agile circles on “How to estimate?” as opposed to “Why estimate at all?” In those few cases, where I saw some attempts at explaining “why?”, they stroke me as incongruent and built on some very loose logic. This very fact of the looseness of “why?” puts a big question mark on the validity of the “hows”, because the “how” is a product of “why?” or “what?’ I’ve cited this in one of my previous articles, and I’ll repeat it one more time, because this axiom is universal, and works for all things life and project management alike: The hows will appear if the what becomes clear.
Let’s take the scalpel of pragmatism and dissect the faulty logic behind all things agile estimates.
What is an estimate?
Is it a measure of commitment? Or is it a lazy talk? I tried to find some stats on the actual usefulness of the estimates in story points, and how they’ve proven themselves valid in the bottomline world of business. I found none. From my own experience, I know that estimates never work. I’ve seen this in project-by-project software development and in product development. A slightly modified quote from here:
It’s impossible to estimate something that is being built for the first time.
We never build the same feature twice.
The only viable example of valid use of estimates that comes to my mind goes as far back as to the early 2000′s, when people wanted simple e-commerce web-sites, or dating sites, or something of that kind. Having built a handful of such web-sites, software vendors were more likely to give their clients a realistic estimate of completion, because these web-sites didn’t have a heavy baggage of residual debris, such as technical debt, bulky databases, or an octopus-like architecture, which just spreads, rendering futile any attempts to commit to the bottomline “get the sh..t done on time” stuff.
Next, if any attempts at estimating are futile, then why do most companies continue to play this game, which resembles courting, but unlike courting promises no pleasure ahead, only the ever increasing snowball of mess, feeling guilty, unproductive and unaligned with the only goal that matters: get the job done well and on time?
Stay tuned for the answers and even sharper disclosures in the upcoming part 2 of this article.
5 Reasons Why You Should Stop Estimating User Stories
Joy Spring and Estimated Deadlines
2 Meta-Principles for User Interface Writing
UX: Why User Vision Design Matters
Why Agile Estimates Don’t Work – Part 2
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.
Top 5 Non-Office Brain Killers
Cognitive Endurance Basics for Software Developers
Continuous Problem-Solving Is No Accident
5 Things We Need For Sustainable Performance At Work
I’m subscribed to a newsletter from Buffer, a startup softdev company that develops an app to manage multiple social accounts. It’s quite an unusual thing for a social media-related company to share sensible advice in their newsletter, and that’s the reason I wanted to learn more about that company. So, I googled all things Buffer. The more I researched, the more I admired them. They are a startup, and they do well, generating over $3 mln in annual revenue, with only 23 people. What is the reason for such an amazing performance? How have they been able to grow from zero to a revenue-generating company, in 3 years, with a lean squad of people, and still bootstrapped? How do they keep up their productivity?
The answer came with a little bit more of research. Buffer don’t wrap their rules of operation in the toga of productivity, or agile, or development process lingo, which is very unusual, and which might explain why this company performs way better compared to the others that do. What’s more, Buffer keeps their people happy and emotionally fulfilled. They don’t think of their company as a racing car that has to be ramped up on speed. They, actually, are not concerned with productivity, or speed, for that matter, at all. The point is: Buffer spotted this one bottomline thing that powers productivity. They refer to their rules of operation not as to policy, but as to culture. And, the way I see it, the ultimate key to their performance is one simple thing called clarity. Check this snip from Buffer’s culture statement.
It might be hard to believe at first, but with a little bit of thinking, we will see that clarity is the key to productivity for any team’s work. Thinking logically, a team’s performance is a sum of smooth individual flows and actions. Developers write code, QA engineers do testing, someone is in charge of automated tests, designers do all things UX. Now, when productivity suffers? As with cars and highways, stops occur when there’s a roadblock or a speed bump of something not being clear. What happens if bumps accumulate for weeks, even years? Production team lose track of priorities and incentives, if a day’s work is filled with un-clarity every step along the way. What should I do in this case? Who do I contact? Who has a clue to this problem that I have? If people in the team fill most of their days with these questions, it’s time to put up a huge red flag and “beware bumps” sign. In this sad case, the team is deprived of the very chance to perform, even if they want, because, individually, they lack clarity. They need to have a clear knowing of those “who, what, why, when, how”-s related to their work, or, at least, they need a fast and smooth way to get the answers. If finding an answer for a repeated daily task becomes an ad hoc improvised quest, R.I.P. productivity. The things covered under the umbrella term of “efficient development process”, are rooted in crystal clarity.
Clarity is also crucial when it goes about motives for the actions of others. Second guessing, or a misunderstanding about someone doing things the way they do them, is another severe case of un-clarity. Generally, we are supposed to assume that everyone is doing their job as best as they can, but, with lack of clarity, the thing that I call “assuming dumbness” rears its ugly head. When it happens, instead of having it clear why someone in a team has done a code, or a test, or a copy, or a design in exactly that way, others make a default assumption that this person is “dumb”, not competent and not knowledgeable. This isn’t a productivity killer, per se, but it is a dangerous team spirit killer, and I hope you haven’t spotted this in your team.
As we can see, there’s no need to go any further and re-invent the wheel. If you’re concerned about bad productivity, or if you see that people look exhausted, unhappy or loose, seemingly giving up on their work, they crave for someone to champion clarity. That’s what Buffer calls “Default to transparency“, which is a sibling of clarity.
So, ask yourself, do you always have this clarity? In your team? Is your day made up of roadblocks, or is it filled with gratifying work which goes in a seamless flow? If no, take action. Go for clarity. Demand it from your managers. Clarity is this so much wanted silver bullet for productivity in a software development team. If you find ways to instill the culture of clarity in your team, every step along the way, the Holy Grail is yours.
Non-Violent Communication for Agile Teams
Are You Dumb?
How Communication Factors In To Production
Non-Judgmental Communication for Agile Teams
Why Fast Is Slow
Uselink: Organizational Culture and Development Process
Project Manager or Tech Leader?
The Dangers of Small Talk
Why Self-Organization Is a Luxury
Why Is It Right to Write?
What’s Wrong With Your Questions?
When Intensity Pays Off
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.
How Visualize: Board, List or Timeline?
Visual Management Software
How Timelines Help Project Managers Track Progress
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.
5 Things We Need for Sustainable Performance at Work
Cognitive Endurance Basics for Software Development
Continuous Problem-Solving Is No Accident
Top 5 Non-Office Brain Killers
The Perils of Facebook-ization
Do You Need an Open Office?
Software development companies have been using real-time online communication tools for about 10-15 years by now, and it’s hard to imagine how they could possibly do without such tools at all. Online collaboration started out first as instant messaging, back in the late 90′s – early 2000′s. With distributed teams and with work outsourced to other parts of the world, instant messaging became indispensable. Be it a development team located thousands miles away from an executive team, or from a customer support team, or whether an organization needs an online hub where the remote workers can get together, no one questions the need for such tools and the value they bring to the workflow. However, online messaging has always been a subject to productivity-related concerns, and for a reason. I want to look into how the real-time online communications at work evolved over the last 15 years, how it was early on, what has changed now, and what we need to do about those changes, as stakeholders, or as employees if we want to be productive and feel good about our work.
Instant messaging at work in the early-mid 2000′s: Block and Spy
In early 2000′s workplace culture was more restrictive and prohibitive, in general, than nowadays. Some companies used the punish-and-fear practices with regard of instant messaging at work: they would log ICQ chats, banning any chatter unrelated to work altogether, or they would go as far as to totally block instant messengers. A point to note: there was no Facebook in the early-mid 2000′s. Instant messaging just started out, and I’m old enough to remember how it seemed to be one of those technological miracles. People were soo eager to chat online with their friends when at work. The employers, naturally, wanted to keep their employees working and working. The practices of material production were implanted to software development back then. They assumed, mostly, that knowledge workers should work by the same token as machines in the manufacturing: 9-5 and non-stop. Back at those times, the issue of productivity with instant messaging at work was about not letting people get distracted. To get an idea of how it was back then (or to refresh the memories), we can refer to this 10-year old article in Wall Street Journal. Someone would probably smile, as they read this, quoting from the article: “Being overly casual with colleagues and superiors is one of the biggest pitfalls of using instant messaging.”
The rise and decline of Facebook in the mid 2000′s – early 2010′s
By mid 2000′s this dynamics was replaced by a new one. Enter Facebook, going mainstream in about ’07-08. No doubt, Facebook has influenced the way we live our lives, let alone our communications with friends and co-workers. Some employers sensed trouble as early as then and blocked access to Facebook in their companies. But these attempts were futile, because the general public opinion tended to regard such actions as the Draconian culture-of-fear measures. 5-7 years later, one can observe yet another change. Now numerous studies and research prove that Facebook makes people unhappy, and they give a detailed account of how exactly this happens. I reckon the recent notorious psychological experiment conducted by Facebook is a clear proof that they sense trouble and look for the clues on how to keep people hanging out there. Otherwise, the Facebook’s game might be over. Anyway, back to to my story.
The Facebook-ization of workspace
Facebook, as outstanding a phenomenon in public life as it is, has certainly influenced the way companies arrange their online communications. Before Facebook, it was about instant messaging. In the age of Facebook, real-time communication at work has got more and more Facebook-ized. Now these tools are not “instant messengers”, they are referred to as the tools for “team collaboration, file sharing, document sharing, social sharing”. Can you feel the difference? Now, let’s think logically: if research proves that Facebook makes people unhappy, and given that real-time collaboration tools have acquired many Facebook-ish traits, it is safe to assume that teams might be subjected to this same unhappiness and feeling low as they use such tools, similarly to how it happens with Facebook users! So, which Facebook-like peculiarities of online team collaboration tools do we need to keep an eye on? Where’s the potential danger of unhappiness and unproductiveness?
Miserable observer vs. energetic doer
As the research has it, one of the most insidious traps associated with Facebook, on a psychological level, is spending more time in passive than in active mode. The more time we spend browsing photos and passively checking updates, the worse it feels. Same with the real-time team collaboration tools. Once we spend a lot of time passively checking status updates of our co-workers, on how something worked great or sucked in an area of work which is beyond our control, a certain cognitive bias of being let out of the real action is slowly formed. It might feel that our work doesn’t matter at all. There’s a nagging voice that says: “All my efforts are in vain, no one needs them.” In a bounceback fashion, these people will want to stand out and make a difference. But their work is not related to any major achievements. They just do their job, as a tech support engineer, or as a QA engineer, or as a software developer. Still, they feel alienated, under the influence of this bias, and they will act Facebook-ishly to remind the rest of the world that their work matters. They’d post an update that — in their mind influenced by the bias — would make their work appear meaningful. But this update wouldn’t add value to the work of others in the team. Or, they might tend to be overcritical as to how things work, or how something is eternally wrong. I do not mean the exchanges where the team collaborate online to resolve an urgent issue real-time. My point is that these channels of communication have to be arranged thoughtfully, and engage those employees that can be the doers in such situations, rather than passive observers. I’ve given just some examples of the distortions produced by those biases. Let alone that this vicious “feeling low+the need to compensate” circle creates a swirl of alienation, its contribution to the team’s productivity is zero. If an employee is preoccupied with this unhealthy virtual environment, and tends to act in a Facebook-ish fashion, they do not do the work. They blow their productive focus and their mental energy on coping with such psychological biases.
What to do about Facebook-ish biases?
If something like that happens in your team, fingerpointing and spotting individual point of failures will not help. People are people, we have emotions and visceral reactions. The only way to go forward and to keep us productive, energetic and healthy at work is to sit down, think and come up with the strategic setup for internal communications. Who in the team needs to collaborate real-time to do their job? For whom online collaboration is more of a waste, loaded with potential biases? If someone needs some information, could there be such a setup, where they’d get this info async? If this info is available, how do we make sure that everyone knows where to get it? These are just some questions that one needs to answer. If you’re a a stakeholder, or a person in charge of the mechanics by which your company runs, there’s a compelling evidence that calls to de-Facebook-ize work-related communications. If we think more about it, the real-time messaging is usually required for customer-related issues. It could be, a tech support team urgently needs help from developers or from the dev ops. But do they need to include other people from QA and dev to these firefighter talks? Gee, if the production team see that customers always come complaining, they might get a bad cognitive bias that no matter how hard they work, customers still have issues. The rule of a thumb is: think who needs which information to do their work, rather than “why don’t we keep everyone informed real-time?” Biases developed from spending time in passive-observer mode come with a price tag: dissatisfaction with work, loss of productivity, and a whole array of other such bad things, which no sensible person, be it an employee or a business owner, would want to have in their organization. If you are an employee, think if you want to stay on top of all the updates real-time. Beware passive browsing. It’s the most dangerous thing ever about anything online. If your management has no policy for real-time collab tools, invent it for yourself. When you start feeling bad being a passive observer, and catch yourself posting notes with negative or sarcastic messages, run away. Shut down those channels, and focus on your own work.
Slack, an online team collaboration tool, displays some cheerful messages for its users. One of these messages is particularly wise and well-intentioned. Here’s how it goes: “Enjoy Slack responsibly“. Also, Slack has a slogan on their web-site: “Be less busy”, which I would like to extend: “Be less busy. Be more focused instead“.
Getting Closer with Remote
Skype Is (not) The Limit
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.
Visual Management Software
How Timelines Help Project Managers Track Progress
How Visualize: Board, List or Timeline?
Take 5 Visual Reports for Kanban
We’ve been raised in the belief that all humans are social animals, as the theory of evolution has it. If you’re wondering how the evolution and being a social animal is ever related to work in software development, or, more precisely, how it slows down personal and organizational productivity, that’s exactly what my today’s article is about.
Social Animal ≠ Productive Performer
What strikes me most is that we keep on going with the axiom that humans are social animals. Seemingly, we forgot that evolution never stops. With the advances in technology and life infrastructure that happened in the last 30-40 years, the “social animal” concept has suffered some severe cracks. If we look at animals, why are they social? Why they stick together? It helps them feel secure in their natural environment (a flock of deer will sense the danger of the wolves approaching better than one deer), and it helps them get the food easier than on their own (lions, or wolves, hunt in families and then share the meal). Now, do we humans have to gather into a herd, like those animals do in the wild, to secure ourselves or to escape starvation? Obviously, no. But, for some reason, organizations still stick to this thinking as they arrange open-space office layouts for knowledge workers.
Even evolution-wise, the purpose of humans working in an office, to maintain their living, deep down, is no longer to be just fed or to seek shelter. If a contemporary human wants to stay secure and keep “being fed”, the evolution dictates the need to find the optimal ways to perform well at work. “Optimal” stands for “achieve best results with least personal energy consumed”. Staying in physical proximity in one room at work no longer helps our natural evolution, but rather presents a big obstacle to it. With knowledge work, it’s counter-evolutionary and self-sabotaging to expose oneself to the environments that drain us. Numerous research reports prove what people intuitively feel inside: to keep good health and to perform well, we need to arrange for a space that helps personal productivity, rather than blocks it.
The law of personal energy conservation in the office
Think about it. If you were to count the cases when staying in one room with your co-workers really contributed to your individual performance, and hence to your own well-being and to the well-being of the whole organization vs. how often it was an annoying distraction that sucked your energy that could have been invested into doing the real work? Our co-roomers’ activities have the same effect on us as many apps running in the background have on smartphones. It seems that the phone is doing nothing and just idles, but the battery charge gets lower. The energy is gone. If you’d need to make an urgent call in the middle of nowhere, with no option to charge it, your smartphone will not be able to accomplish this vital task.
It’s about the same with staying in an open-office space. If we throw in to the mixture the other stresses that people have in their lives, things get even worse.
If not an open office, then which one?
How to go about designing office spaces, then? The answer is: it depends on the unique setup and production/development process in your organization. Sometimes sharing a room might work better for a small workgroup, if they rely heavily on a real-communication inside the group. Like, for a feature team of software developers and QA who call on each other, as they have to verify commits, or if QA’s need help from developers to reproduce a bug, etc. Or, for customer service employees in technical support and in accounts. It makes sense for them to stay in a shared open-space for their evolution and well-being (read, for their ability to do their work better). However, an open space would be a productivity killer for a strategizer, or for someone who comes up with creative concepts or designs that development teams will then carve in the digital rocks of software. Can you imagine Winston Churchill or Steve Jobs working in an open space office, let me ask? Hardly anyone would doubt that privacy is a must for the highly creative work.
There’s another erroneous consideration that stakeholders might have in mind about open-space offices. They assume that physical proximity will cement people’s belonging to a cohesive team of individuals who share company goals and values the more, the more time they spend together. Wrong. Belonging to a group can be promoted by other means, such as sharing a company’s philosophy through the space itself, or, what’s most important, by doing some good job together. We wouldn’t think that a family of 4 would have a better sense of a family if they are forced to live in a 200 sq feet apartment, would we? The same is true here. Creating an organizational ethos and having employees light up with it does not happen simply by stowing people in one room. It takes more foresight, thinking and attention to detail. For starters, the team spirit is best promoted by a successful release or by another important milestone achieved together.
This is all about how the specifics of work correlates with the space. While some companies simply do not feel that they can (or should) allocate larger budgets to fine-tune their offices, some people can do just fine working at home, if their home is better conditioned for work than an open-space office. Alternatively, for someone with kids, or with the A/C at home not working, an office would be a better place to work. What and how works better will also depend on the office demographics. Millenials, the Gen Y-ers, for example, are more likely to put up with the distractions merely due to the fact that they appreciate their office as a space where they can socialize (some say it might be the root cause of why this generation seems to be underpeforming in general). Disclaimer: I’m a Gen X’er :) Not sure if it’s solely for that reason, but I value focused concentration at work more than socializing. This is just another example that shows how deep stakeholders need to think as they approach the job of designing an office. There are so many factors to consider and to write about, that it would take a huge article just to list them all. For each and every company, there will be a unique solution.
5 Things We Need for Sustainable Performance At Work
Continuous Problem-Solving Is No Accident
Getting Closer With Remote
Cognitive Endurance Basics for Software Developers
Top 5 Non-Office Brain Killers
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.