In June-July 2015 we conducted a Customer Survey in order to understand our customers’ perspective on the key differentiators of Targetprocess as a tool to manage Agile projects. It was gratifying to hear that one of the key factors why the customers love Targetprocess is its visualization capabilities, i.e. the functionality it has for managing projects and various processes visually.
It was gratifying for us because it sounded like one big dream came true: we did want to enable people to see and to change things that are not visible on the surface or at the data level, but can be visualized for insights and actionable conclusions. That’s actually the motto of Targetprocess: “See. Change”.
Taucharts is still a young library but can be already used as a foundation for custom graphical reports. Check it out at http://blog.taucharts.com/taucharts-data-focused-charting-library/, try to visualize your data and get a bit closer to the bar set by Targetprocess for visual, more effective project management! ;-)
If you haven’t yet used Targetprocess, jazz up your project management, get a free trial account!
In physics there is an interesting fundamental principle: a system moves from one state to another using the minimal path, i.e. a path that demands the minimum energy.
When I read this, I immediately think about user interface design. Can we apply this principle to UI? It seems yes, since it is quite fundamental. I have never heard of attempts to use energy to evaluate efficiency of UI. This is the first try.
Let’s say, we have several interfaces that can transfer a user from state A to state B. Which one is the best? The Minimal Action Energy Principle in User Interface states:
From all available interfaces that transfer a user from state A to state B we should select the one with the minimum action energy.
So what is energy? That is a very tricky question, even in physics. But humans are more simple, so we can define all processes where we loose energy: clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc. A more complex thing is to unify these actions and have the same units for them to come up with a single energy number. After that we can compare energy of user interfaces and find the one with the minimal energy required to complete some action.
We can start with a simple model that will be good enough for the tests. We should introduce a unit to measure User Interface Action Energy. It can be yellow frogs, but let’s call it Action Units (au). All actions can be expressed via this unit:
1 click / tap = 1 au
1 scroll movement / wheel rotation = 2 au
1 second of thinking / looking = 3 au (thinking is hard)
1 second of cursor movement = 1 au
1 second of waiting = 0.5 au
1 second of typing = 2 au
1 second of asking for help = we fucked up
If I missed some interaction patterns let me know. Now we have a model to measure User Interface Action Energy. Note that energy is not equal to time. It means the user can actually spend more time with a system, but apply less energy to complete the tasks.
Let’s calculate User Interface Action Energy for a simple login action:
||Looking at the form: 1
Click the email input field: 1
Recall your email: 1
Type the email: 3
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn’t highlight the login button: 6
Click the login button: 1
Wait 20 seconds to log in: 10
Total: 29 au
This decomposition makes it clear where we have energy leaks! Let’t fix it to spend less energy:
Looking at the form: 1
Click the email input field: 1 (This field should have the focus by default).
Recall your email: 1
Type the email: 3 (autocompletion can save some au)
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn’t highlight the login button: 6 (Tab navigation should work and highlight the button. Note that confusion causes a significant increase in the energy required to complete the scenario).
Push Enter to log in: 0.5
Wait 20 seconds to actually log in: 10 (Warm-up the application to reduce this time to 6 seconds that equals to 3 au)
Total: 13.5 au
This design is two times more efficient since it takes two times less energy to complete the task. Can we do even better? Yes, implement the Login scenario using the Facebook auto-fill button. This solution eliminates thinking completely.
||Looking at the form: 1
Click the Facebook button: 1
Total 5 au
The absolute nirvana of UI is zero energy. You do nothing and authenticate. Is it possible? Yes, but it will compromise security. Is it possible to do that securely? For example, you navigate to an application, the device takes your picture, recognizes your live face (the photo should not work) and logs you in. You do nothing, but still wait for some seconds most likely. So total the Action Energy will be around 2 au.
Time != Energy
Usability testing is not new and clicks counting is not new. Usually we just measure the time to complete a task, observe bottlenecks and try to fix them. However, time should not be the ultimate measure of a user interface. Most likely, thinking is the most energy-heavy activity, so the best thing a designer can do is to remove thinking from the user interface as much as possible. Steve Krug was right. Some extra clicks might be OK if they reduce thinking about UI.
Moreover, a usability test doesn’t give you a breakthrough. You can find some leaks, confusions, etc., but to radically improve a solution you should think hard. When testing a basic login form you will not find a solution with the Facebook button. This solution evolves from other activities, like brainstorming, taking a shower, walking, etc.
The designer’s job is to think. The user’s job is to use the tool with ease.
Ideally, the designer should create several solutions, select the ones with a lower action energy and test them with real users to find the solution with the minimum action energy.
I think we can automate action energy measurements. Now we have quite advanced equipment to measure the eye movement, the heart rate, clicks, cursor movements, etc. In theory it is possible to create a software that will calculate User Interface Action Energy for every scenario automatically during live usability tests.
For remote usability tests where we have a limited access to a real person’s data we can measure action energy with a good approximation. Still it will be a more objective metric than just empirical observation.
- Estimate UI efficiency with User Interface Action Energy, not time or some empirical observations.
- Action energy includes all processes where the user looses energy like clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc.
- Create several solutions and test the most promising ones to calculate Action Energy. Find the solution with the minimal UIAE and it will be the most efficient one.
- Confusion, thinking and dead end routes are the main causes of energy leaks in UI.
The concept of Minimal Viable Feature (MVF) is a significant milestone in product development. Release something that you think solve a problem and listen for the feedback. While the concept itself is great, the devil is in the details. In general, it is quite hard to learn how to define MVF. It is an art, not a science. In this article I will share my experience and some patterns I learned.
#1 Cut. The. Scope.
The most common mistake in MVF definition is bloated scope. There is always a desire to put one more thing into the feature and make it more useful and more appealing to the end user. No Product Owner can resist this intention and in almost every single feature I lead I added some unplanned user stories. In fact there is nothing bad with this approach, you discover new information and change plans. However, there is a real danger to push feature beyond MVF and delay its release. 9 months feature? We had it in our company.
Now we have a 3-months rule for every MVF. There should be serious reasons to spend more than 3 months on MVF implementation. MVF goal is to prove concepts and discover “unknowns”, don’t blow it to MMF.
#2 Feature kick start
Everybody should understand why we add this feature into a product. There is only one reason to add a new feature — it solves some important problem that quite many users face quite often. In the simplest case you have hundreds of requests that picture problem in bright colors and all you have to do is invent a solution. In a more complex case users don’t fully understand the problem and throw out various solutions that in fact don’t solve this particular problem. Only experience and system-level thinking can help to spot such cases. In the worst case you have no feedback and rely on your intuition to define the problem. This is a dangerous practice that can lead to extreme results: genius insights or total fuck-ups.
On a Feature Kick Start meetings we have people from marketing, development, testing, design and sales. All bring valuable information about various facets of the problem.
These meetings have several goals:
- Clearly define the problem we solve.
- Define a scope of MVF.
- Decide what we don’t know and what feedback we will accumulate now and after MVF release.
- Bring development team and sales people to a common understanding about the feature.
#3 Huge upfront UX is bad
We tend to have UX and Development as a completely separate activities. Sometimes we spent months on a feature UX, built prototypes, tested them and then boom… priorities changed and feature is no longer needed so much. Almost all the time we spent was just a waste. Let’s say we get back to the feature next year, but now we have new information and UX we did a year ago is obsolete now, so we have to start over again.
Now we start UX when feature is actually starts. It means Feature Team almost completed previous feature, so it has some spare time to dig into the new feature and discuss its design, flows, etc. It may happen that developers don’t do much for some time, since UX is not ready. However, there are often many things they can do: fix some old bugs in background, prototype new feature, try some technical and architectural ideas, implement something we 100% certain about. So while in theory it looks like you are not “utilising 100% of resources capacity”, in practice single-feature flow for a Feature Team shortens cycle time and reduced waste activities.
#4 MMF is inevitable
Usually MVF solves a part of a problem and some cases are missing. Usually the solution itself is not the best. In most cases MVF is not a “complete” feature and you should finalize it. We call this finalization Minimal Marketable Feature (MMF). At this point feature provides a complete solution to a problem, the solution itself is beautifully designed, it is on par or outperform similar solutions in competitive products.
It may happen that new feedback will reveal that MMF is still not enough, so then you can iterate and release as many improved features as you need. This process is not formalized in our company.
#5 Real feedback is slow
We hoped to have 2-3 weeks delay between MVF and MMF and we thought it will be enough to accumulate enough feedback. We wanted to have process like that:
However, in most cases it takes 2-4 months to generate good amount of relevant feedback. It takes time to accumulate and reveal common patterns. For example, we re-designed navigation and allowed users to create their own Groups and Views inside these Groups (BTW, it was the case when we throw out UX done 9 months before feature start). It took us 5 months to actually understand what mistakes were made and what problems most companies have with this new flexible navigation. It appeared, the navigation was too flexible, so now we are reducing this flexibility and add some restrictions.
We changed the process and now we plan for 3 months delay between MVF and MMF. This gap is used by another MVF, so on a high level we release first minimal feature, that release second minimal feature and then based on generated feedback we complete both features.
#6 Real feedback comes from real usage
Don’t get me wrong, I’m not against prototypes, wireframes sharing, surveys, etc. However, my experience showed that the only way to get a really relevant feedback is to release something in a product. All other ways of feedback generation are flawed. Real users bring so many unexpected and interesting insights.
When we started UX process adoption on our company 6 years ago, we tried almost any possible way of feedback gathering. We created several solutions to a single problem and run usability tests, ran surveys, interviewed customers, ran UX groups and shared concepts and ideas. We still use most of the methods from time to time, but our current approach is extremely lightweight and balanced. In general, we build light prototypes only when we just can’t select a solution from two options (50/50 votes inside our team). We never build full interactive prototypes that replicates future system behavior, but just share sketches and main concepts. With right questions asked this simple method allow us to get a very nice preliminary feedback.
- Set clear MVF goal and cut MVF scope that beyond this goal.
- Bring sales, marketing, development and design people together to define MVF.
- Huge UX phase upfront is bad and usually leads to waste.
- MVF is not a full feature. Embrace it and don’t rush.
- Real feedback comes from a delivered feature only.
- It takes several months to accumulate information to reveal patterns and decide how to improve feature.
I’m 35 and only recently I truly nailed what drives my life — it’s “creation”. When I create something meaningful I feel really great. My creations are not tangible in most cases, like poems, songs, design solutions, new product features, articles, books and blog posts. In general I think creation of anything that lasts is a good way to spend your life.
Source: 25 ‘Minecraft’ Creations That Will Blow Your Flippin’ Mind
Deep immersion into a working process turns off everything around. You suddenly ignore all external sounds, you don’t feel how minutes and even hours passing by, you don’t notice poor lighting and reject timid body requests. Then you wake up and check the result. Maybe it’s not perfect, maybe it’s just a start of something significant, maybe you will throw it away in several days after critical examination, but nevertheless you have a sense of achievement. You’ve just completed a thing that may be a part of your legacy.
Can you write? Can you invent a software that changes people lives? Can you build a house? You never know till you try. Your life passion is not “programmed”, it should be “discovered” via experiments and achievements. Moreover, public recognition in many cases is not a good indicator of your achievements. Your personal feelings do matter. When you achieve something and enjoy the process, it is a good signal that your experiment was successful and you should keep going. When you spent quite a lot of time on, let’s say, quantum physics with no clear results and theoretical constructions bored you to death, maybe you should try something else (or maybe you just have a depression, but it’s curable).
Any startup and any ambitious mature company should hire as many creators as it can. These people are enthusiastic, active and relentless. They are the engine of a company. They keep learning, experiment a lot and failures are just a part of their working process. Every team desperately needs at least one creator, otherwise it will be mediocre at best.
How to discover a creator? It is relatively easy to do. Usually they can have something from the list below:
- Side products (frameworks, apps, whatever)
- Blog, articles, books, whatever
- Hobbies related to creation (painting, robots construction, fancywork)
- They usually like LEGO and Minecraft (this option alone is not 100% proof that a person is a creator)
Consumers are all around. We all consume books, movies, TV shows, cars, food, etc. How many of us transform all these consumed information, experiences and skills into something meaningful? Surprisingly, creators are quite rare. It’s incredibly hard to find one and align his goals with company goals. Sometimes they are not polite and hate everything that blocks or slow downs acts of creation. They will not tolerate political games and bureaucracy. Most attempts to cheat them and exploit them will fail in the long run.
We need to build companies that promote honesty, creation and learning. I’m here to create. You?
How diversity helps us in problem solving, creativity and overall intelligence? It helps a lot. Diverse groups of people can produce better results and radiate more creativity. But what about your own, personal diversity? Is it a good idea to accumulate knowledge from wide range of disciplines? Does knowledge of music theory help to write better code? Does knowledge from biology make you a better user experience designer? I believe yes, and here is why.
Douglas Hofstadter and Emmanuel Sander wrote a very controversial book Surfaces and Essences. It is not an easy read, but it is time spent well. Authors unfold thinking process from language to high level constructs. They show how analogy-making helps us think, generate new ideas and fuel our creativity, including scientific insights.
This book deeply resonated with me. In general I agree that analogy-making is a core of our creativity. I even tried to apply knowledge from Running domain to Software Development domain and generated some quite interesting ideas like Interval development. Sure these ideas can’t be proved easily, since analogy doesn’t mean the idea is great. But still it is relatively easy to take knowledge from one domain and apply it to another domain.
How can it help me?
All that brought me to the idea to increase my personal diversity and expand my knowledge beyond typical areas like system thinking, software architecture, groups dynamic, innovation models, user experience and other stuff every CEO learns. I read books and took courses about quite diverse topics already, but I did that in a chaotic way.
Suddenly it became obvious to me how all these new domains can help me to be more creative and solve problems better.
What domains should I explore?
I think you should try anything you always wanted to learn, but didn’t have time to. It is quite hard to predict what analogies can be generated from unknown domains. For example, you always wanted to know how people paint, how art evolved and how Michelangelo painted a fresco of The Last Judgement on the altar wall of the Sistine Chapel. Dig into the art domain and learn as much as you can in a single year. Will it help you to be a better software developer? Why not? If you try to paint something you can train patience and learn how to sketch (everybody should sketch, you know). Michelangelo’s approaches may give you some ideas how to structure your work. As I said, it is hard to predict exact ideas that you’ll generate in the end, but I promise you will generate some.
I personally want to study biology, music theory, architecture, education, medicine, go and swimming. If a simple running domain gave me new insights, I believe larger and more complex domains will bring even more value.
Why one year?
A year is a good timeframe to focus on something. It will be your new hobby for a full year. You can read 20+ books, take 1-3 online courses, maybe take offline courses, try to apply your new knowledge constantly. Small domains demand less time, but larger domains are hard to grasp in 2-3 months.
I don’t believe in quick solutions. You can read a book or two about a subject and have some fresh air in your head, but it is not enough to just scratch the surface. In 10 years you will have a decent knowledge in 10 domains. That sounds cool to me.
Did you try that?
Nope. I started to dig into music theory recently. So far I’m just sharing the idea with a hope that there is always a chance you’ll like it and give it a try.
And maybe, just maybe, you’ll even find your new passion. Who knows?
This is my personal humble feedback on Agile Conference. I do make broad conclusions though, so feel free to provide your vision in comments.
I haven’t visited Agile conferences for like 5 years, the last one was in Chicago. It was pretty good. The main innovations were Kanban and UX+Agile. Many sessions were still quite boring to any experienced agile practitioner. Now I’m in Orlando. Conference becomes huge. There are so many people around. But what about sessions? In 3 days I visited exactly one session that was really interesting and useful, it was about Netflix culture at DevOps track. All the others I visited were not useful, boring, kinda OK, way too abstract or completely trivial. Maybe I was just unlucky and missed all the good talks. Maybe, but I picked carefully, to be honest. I talked to some people and received mixed feedback, but in general it looks like conference content is not great. DevOps track looks very good, BTW, and I heard many good words about it.
How do I feel about all these things you ask me? I personally see a serious stagnation and the lack of innovations in agile community. Don’t get me wrong. There are bright people with brilliant ideas, but it seems they are in opposition to the main trends. How’s that happened?
Agile is about helping businesses to kick ass. To do that, there should be innovations in various directions. We, as an agile community, should invent new ways to help business understand what is valuable and what is not. Invent new development practices and try them in various contexts. Inspect organizations as a whole and invent new ways to detect problems and solve them on a system level. But what we have at the moment?
There are many topics about Scaled Agile frameworks. I visited several sessions and I have an opinion that speakers have no clue how to really scale agility. Proposed frameworks are kinda prescriptive and heavy. They reminded me RUP-days. You really can create a good framework based on RUP, but there were few successful cases.
SAFe looks complicated and it does not address root problems on my opinion. We need real structural transformations, while SAFe implies specific receipts and says that it will work in almost any context. How is that possible? Everything is context-dependent, and that is why many agile transformation initiatives failed and will fail. People just apply a recipe without deep thinking, ignoring context-specific things and expect it to work. It won’t work in many cases, and you can’t fix it without context-awareness.
SAFe has many good practices inside. It can help companies initially and you will see some tactical success, but I also think that in the long run SAFe is a strategic disaster. It may take 5+ years to feel that, but I don’t believe that company will inject a true agile mindset starting with SAFe. It can happen, but it will be exceptional cases mostly. The really bad thing is that companies will not notice the problem. With waterfall the problem is (now) obvious, while with SAFe they will have an illusion that they are truly agile, while they are not.
So at the end of the day I have a perception that majority of speakers present some abstract theoretical frameworks with extremely poor argumentation. Why this might work? In which context? No clue.
I also wonder why we have no talks about Kanban here? Is Kanban agile or not? Agile community have personal troubles with Kanban approaches? C’mon, folks, this separation is childish.
All that sounds like rants without solutions so far. So I have some actionable proposals for the next Agile Conference. Here is my feedback:
- Add a decent mix of various disciplines. We can learn from complexity science, biology, sociology, sport, physics and other disciplines. Try to intrigue people from these disciplines to really mix their practices with our practices and invent something new finally. At least invite them to speak about things they know to stimulate our imagination and analogy thinking. Invite Dave Snowden, finally, to see his controversial view on scaling. There should be more perspectives. We need greater diversity.
- Have more real-life experience reports with real practices that work in some contextes. It will help to learn from each other and spread good practices. I know many good discussions are firing up between people, but why don’t do that on sessions as well?
- There should be more science. People over the world do great research about group dynamic, development practices, cooperative games, etc. Invite them to share their researches.
- Invite bright business people to talk about marketing, agile workspace, new hiring practices, strategy, etc. It will finally help merge Agile and business together. Nothing is separate. We should see high-level pictures and learn from them.
- 75 minutes talks? Are you kidding me? Nobody can control attention for more than 45 minutes. Split these talks and make workshops longer, since 75 minutes are not enough for a decent workshop. I’d like to see more TED-like talks, short and precise. Experiment with that at least. Inspect and adapt.
In short, Agile Conference demands more inventions, real-life reports, more science and different format. Conference organization is just perfect, it really is. I can’t imagine better. Content, however, is below average, and that is embarrassing for agile-minded community. We can do better.
The final thing is the slogan I saw yesterday. It is just unbearable to me: “Allow agile and waterfall work together” WTF?
I thought we were working on replacing waterfall and change the ways organizations work. Do we, as a community, still think it is a good idea? Or are we starting to agree with a status quo? I believe we are fucking not. There is no limit to perfection.
“Pirates are bold not safe” — These guys are doing something good
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.
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