We moved to the new office about 3 months ago. With the office moves, it’s usually very uncomfortable to break away from the cozy nest in the familiar space and trade it for the uncertainty of a new office. But then it’s getting better, one good thing pulls another good thing, and you like the new environment more and more.
My starting “like” point about the new office were the circular-shaped walls. They reminded me of the medieval castles romanticism, and that was enough for a start. Then I discovered that the round walls are not only about the ethereal romanticism. They have some practical purpose, and they do hold a harmonious creative space. It feels much better working in the rounded space than in the rectangular one. Try it some day, if you get a chance, and you’ll see what I mean.
What is it about those round walls that makes them that special, anyway? In spring, when we just moved in, the sun was moving along the lower ecliptic, and the first spring rays were more welcomed, than hated, because everyone likes the warmth of the sun after cold winters. Then, closer to summer, the sun’s trajectory in the sky got higher, and the circular shape of the building made it harder for the scorching heat to get inside. I’m not sure if the architects were aware of the feng shui guiding principle that the circular wall shapes are more harmonious for the well-being and creative energy than the rectangular walls, but there’s one thing I know for sure. The architects must have had some hard times reconciling their vision with the construction team, as in terms of construction, it’s harder to build a circular-shaped high tower. Construction guys generally do not like the round shapes. They hate them. If you tell a construction engineer that he would have to deal with anything circular (I remember the sour face of the guy who did the renovations for my apartment when he saw the rounded corners :), it means you give them more headache, and they will try to avoid this headache by all means. They’re looking at construction projects not with the eyes of people who are supposed to feel good working or living in this environment. Construction engineers focus on the pains this will bring in to their work. Like, how do they implement the supports, how do they have them stabilized in place, etc.
If you’ve been involved in designing and/or implementing a software system, you might have had a similar experience. Software developers switch to this engineering-only mode as they get absorbed in their technical meetings and forget that the prerogative (at least, the high-level prerogative before even discussing the duration and costs of the implementation) is the joy of experience and uninterrupted flow when using the software.
Here’s an example: database-related decisions. It’s very annoying for users to experience the delayed load times, but there can be some intrinsic reasons that make developers ignore this inconvenience. Well, the difference is obvious. Software systems generally do not have such long lives as buildings. Stakeholders have to weigh the odds of spending more time to optimize database load times with their considerations for the future. Meaning, what if they have in mind the newer and the better version of the same system? It makes no sense then to hone the old system that would be sunset soon. But we still need to keep the awareness, as we engineer software solutions, that software systems are for people. It does take some decision-making skills to find the balance between the human-related part and the programming-related part, and it’s not even about the usual programmers vs. designers holy war.
For any system you’re developing, or designing, keep in mind the round walls of UX. Your solution needs to accommodate them, because if people like a building, or a software system, they will be delighted to spend more of their time with it (or in it). Yes, the development costs might be higher, and it might take more time. But if people like what you’ve done for them, if they feel comfortable and harmonious in the figurative round walls feng shui of your software , they’re more likely to become your devoted customers and bring along still more.
I’ve come across a very interesting discussion on LinkedIn recently. Someone posted it as a general, thought-provoking question, one of those complex questions that have no finite answers. As it often goes, such discussions receive most comments, and the question was: why engineers are good project managers? Yeah, I know how many thoughts, memories, and personal experiences whirled in your mind at this very moment :) I’ve been there, too, as the more accurate way of formulating this question would be: why *some” engineers make good project managers and *some* don’t?
In this short post, though, I’d like to focus on just one aspect. When you need project managers (or feature owners, as was the case with us) which option is preferable: to nurture them inside your organization, or to headhunt the superstars who have spent most of their professional lifetime at other companies? It depends on your company culture. If acquiring new employees is the domain of recruiters solely, then all you can do is submit a job opening to your HR department, and let them bring in the superstar candidates, luring them by high salaries, compensation benefits, etc. Usually, such job openings are posted on vacancy sites, and come with a lengthy list of technical responsibilities that a desired candidate is supposed to fulfill. It’s largely one and the same list of technical tasks, and quite often communication skills, or people skills, are mentioned only as a plus. A nice-to-have icing on a cake, sort of.
Now, consider this. How often a project or a release blows up due to the lack of technical expertise, and how often does this happen due to the lack of people skills? By people skills I mean anything related to sifting the individual’s technical competence through the grid of this particular business and company environment, in a broad sense. The challenging part about hiring someone from outside is that you never know how this person will perform in the trenches with your other folks, and how will they be able to transmit the common accumulated wisdom of your whole team to the feature or project they’re responsible for. You don’t know what this person is like, and there’s no way you can get to know him or her well enough from their CV. The trial period is of little help either. By the end of the trial period one just starts to merge into the company culture, and all seems to be going well, and you’re so eager to write filling in this vacancy off of your to-do list, thinking that everything is fine. But you cannot be sure as of how the real *people* skills of this person will manifest themselves later, at a challenging moment.
The approach that worked for us, in an agile company environment, as we needed more feature owners, was simple. First off, we called for the volunteers who felt they were apt for this work and who were ready to commit to the responsibilities of owning a feature in TargetProcess. This was the crucial first qualifying round. It must be something that a person wants to do, and be confident enough to stand up and say: yes, I can, I’m taking on this responsibility, and I’m committing to it. The next step for a CEO (or for a master product owner) would be to observe how the aspiring feature owner is actually doing about those very *feature owner* responsibilities. Given that the technical expertise of those people has already been proven in their previous work as developers or QA, and their people skills have also been tested as they’ve been a part of our team for quite a while, and their intrinsic knowledge of the product is in place, all that needed to be verified at that point was their confidence in driving the feature development and their ability to hold the steering wheel firmly.
With nurturing, the rule of a thumb is this: if you’re lucky enough to have aspiring people in your team, let them try to pursue project management. If it works — great, if no — this is less risky anyway than trusting an unverified newcomer with your projects.
A few weeks ago Michael published a post called Product Software Development Is a Marathon. The message of this post is: if you want to come up with a decent product, you’ve got to brace yourself up for a long-distance marathon run. I agree to the point of long-distance and endurance, but I’d rather compare this not to a marathon but to a triathlon race. Triathlon requires diverse skills, you not only have to run, but to swim and to bike, and, as we know, good software developers need diverse skills, too. By the way, quite a few IT guys I know, they do triathlon as a hobby, so there really must be something to it. As in triathlon, diverse skills needed to develop a software product require that you keep up your endurance with all of them, learning to alternate your activities, such as coding, researching, coming up with solutions and empathizing with others while keeping a workable race rate. Success in a faster-faster-faster race comes as a by-product of following some smart endurance tips and tricks. Our brains are our most indispensable tools, and we need to exercise a caring attitude to them… and to our colleagues’ brains, too. I’m saying this time and time again: there’s nothing ever more important to us as professionals than taking good care of our brains (well, and bodies, obviously, because brains work better after some good physical exercise, and that’s apparently what the folks that do triathlon are sensing as well :) . I’ve touched upon that subject one way or another in a number of my previous posts, and this caring attitude would ideally stem from the company’s culture in many subtle ways. It’s a paradox, but very often we’re unaware of how those small bummers at work are killing our performance and draining our cognitive powers. For quick reference, cognitive is anything related to mental processes: attention, memory, talking, listening, learning, reasoning, problem solving, and decision making. This diagram shows the interrelated network of the processes going on in our brains as we work. If you come across some bummers disrupting those processes, the performance of your brain wanes for any given day at work, and unless you do something non-mental for a change (like, hang out with your family, or do some triathlon training), your brain powers would not restore just so.
The insidious sources of cognitive bummers can be broken down into 3 groups:
- Process-related. Anything that has to do with the glitches and communication issues arising from a sloppy development process, e.g. too many meetings, unfocused online messaging as opposed to face-to-face talks, not knowing who to go to and where to report to if there’s an issue that needs to be solved. These would be purely cognitive disruptions.
- Workspace-related. That’s more about the general feeling good, although in the end it boils down to cognition, as all those kinds of workspace-related stresses would end up in the brain as well. What if someone prefers to sit with the air-conditioning off and just with the flow of fresh air? Or the lights? What if someone prefers natural light to the LED lights? The most notorious workspace-related disruption wouldn’t be the lights or air, though. It’s the noise produced either by colleagues discussing a solution to a problem, or can be some of them wants to listen to music from the speakers while a few others prefer to work just quietly. Workspace-related disruptions depend on personal sensitivity. Someone can sense them very acutely, feeling that this something is really tiring their brain. Others may be unaware of the direct impact, but they are affected all the same, regardless of the awareness or unawareness. I wish everyone could have such a plate by their desk:
- Individual. This is about personal time management skills and will power. Things like: if you start your day with Facebook, or browsing news, or reading some casual stuff, don’t be surprised if you’re drained by noon, when it occurs to you that you never got down to doing the things that would actually make you call your day a productive one.
Of those 3 kinds of disruptions, the first two are enrooted in the company’s culture, and need to be cured at a company level first. In fact, if a company nurtures the culture of keeping everyone’s flow and takes care of the good workspace, then it’s a lot easier for people to perform at their best on an individual level. I mean, not everyone is a personal productivity guru. Well, of course, it’s in one’s own power to stay away from all kinds of online time wasters, and do things successively, one after another, but it’s a company who can literally lend a helping hand and contribute a lot to cutting down on multi-tasking as much as possible. I will write more about those disruptions, and what can be done to tackle them both at a company level and at an individual level in my future posts.
There’s more and more buzz around estimates and #noestimates in software development. People like to write bold statements and go extreme about things in blogs. Usually, personal dialogues are much more balanced. Some hate estimates and believe it’s a useless activity. Some defend it with arguments of arguable truth.
I want to dig into intrinsic estimates complications, what people mean by “estimate” and what future directions we may attack → Read the article.
A couple of years ago I bought BMW 530 E39. Not that I’d been into BMWs all that much, but I just stumbled upon a good deal to replace my old car, and I went for it.
This car was excellent. I liked almost everything about it except:
- The rain sensor. Even when set on the “High” speed it functioned very slowly, which rendered it mostly useless in the field conditions.
- The front and rear windshield defogger/defroster controls. Too far to reach.
- The weird audio set controls. I had quite some trouble getting used to them.
- Setting the in-cabin temperature with up and down arrows.
Then I bought the next-generation BMW E60.
Now, what do you think?
- The rain sensor works perfectly.
- They made the defogger/defroster controls bigger and put them to the center.
- The audio set started to make sense.
- They have knobs for the in-cabin temperature, and it’s just a pleasure to use them.
The smart BMW guys resolved all the issues I’ve been uncomfortable about. But — of course — they added a couple of new issues instead:
- In the E39, cruise control was located right on the steering wheel, and it worked just OK. In the newer E60 model they did it as a lame lever on the lower left side of the steering wheel, with absolutely non-intuitive movements to switch on/off and adjust cruising speed.
- Door locks and hazard warning flasher switch were moved from beneath the driver’s right hand to the central console. For several months I’d start in the wrong direction to open the doors, until I got used to the new setup.
While the change #2 looks quite logical as it comes along with the new iDrive system, they have no mercy from me for the cruise control.
On the whole, the next-generation BMW remained the same, but better. I think that’s a very important principle for the evolution of any interface:
Same But Better
We’re getting at the good old issue of UI novelties here. What’s better, slowly and meticulously improve the current system? Or introduce new elements in radical spurts, leaving no stone unturned in the old system?
Users are quite inconsistent creatures. For one thing, they like to download updates hoping they’d finally get the features and improvements they’ve been waiting for. On the other hand, they hate getting used to new features.
Any interface develops in cycles. Someone comes up with a new interface, users start bringing in their feedback — that’s the stage of step-by-step improvements. One has to rework some parts of the functionality and mix in new features gradually, without having people learn from scratch.
Then, a critical mass of new knowledge is acquired over time, and if this knowledge is used wisely, it becomes clear how to improve the system along with the UI. That’s the time for revolutionary changes, and that’s how all interfaces develop (if they don’t die before their time):
new stuff → evolution → revolution → evolution → revolution → …
* rendered into English by Olga Kouzina.
I remember how eager I was earlier this year to hear what Phil, the prophetic groundhog, predicts about spring. There’s a special reason for that: as the name of my post suggests, it had to be published not before we felt something close to what it actually is about — joy spring! Not even that much surprising, but Phil’s prediction turned out an epic fail, as spring got delayed beyond any reasonable standards. Finally, about 2 weeks ago, spring remembered about us, the freezing folks. Even Phil, the Groundhog, screwed up with his estimate, and while the spring is already far in, it’s high time to come up with a very fitting narrative of what missed deadlines, and deadlines in general, are about.
Apart from spring itself, there’s actually one more reason for joy. We’ve finally come up with TargetProcess 2.24, the spring 2013 release. The keyword is “finally”. We were supposed to be done with it much earlier. But it appears the release wouldn’t want to venture into the outer world in any other weather than the spring one (thank you, Phil).
Enter Deadline (escorted by Estimate)
Jokes aside, I wouldn’t be mistaken if I said that many meetings in software development are supposed to dissect the reasons for missed deadlines, or delivering later than expected. I’ve been interested in studying the metaphysics of deadlines for quite a while (see my earlier post, it dates back to 2009). Now, if deadlines are in the spotlight of most meetings, which typical questions are supposed to be answered? And, what’s more important: even with answers to these questions in place, are we getting down to the roots of the real business “pain”?
Some of those questions would be: Why are we late? Why were our estimates bad? Maybe someone under-performed? The sacred holy deadline has everyone dancing before its altar like puppets on the strings. It isn’t unfamiliar for people to have this nagging feeling as they come to a meeting and expect that someone’s head is about to be cut now. Especially if there’s the rhetoric of guilt and who’s-to-blame. It’s natural (I’d say that it’s unnatural) to assume that a missed deadline means we should chase and track down the bad performers. As this subdued air of someone’s guilt or bad performance takes lead, and people focus on the “why bad estimates” part, you can throw the time that you’re spending at this meeting to a waste bin.
Usually deadlines are tied to estimates, like addicts to abusive substances. There’s no deadline without an estimate. If you’ve spent 3-5+ years as a project manager or a product owner or a Scrum master, or as anyone else who relies on the estimates of completion, you’d know that softdev work can not be measured and predicted due to its very its own nature, at times even with no acceptable leeway margin. Ron Jeffries has summarized this rarely outspoken truth very well in this post (actually though, there’s quite some talk about the delusion of estimates at this time).
Stunning. It appears one cannot rely on estimates, and can’t set a deadline, or predict a release date. With stakeholders, or marketing people, or clients wanting you to commit to a time, this seems like an extreme nonplus. How do we go about it, and how do we persuade those stakeholders that life without deadlines is not only stress-free, but it actually means a better quality software at the end?
I think that this whole concept of deadlines is built on fear and insecurity. Something very old-fashioned and 19th centiry-ish. Okay, now if we have a deadline as a whip, our horses will exhaust themselves to get the carriage out of the mud and will deliver on time. That’s a bit of an exaggerated comparison, but what else can come to mind if people are pushed to do something faster and to stretch their limits AND for no valid reason. Well, the reason appears to be very valid. His Majesty Deadline. If we miss it, then the Earth will sure stop turning, the sky will fall down on the sun, and the seas will dry out.
Deadlines have been inherited from the distorted ways of the 19-20th century fit for manual work. They’ve been dragging along like heavy but unnoticed shackles on our feet for 20-30-40 years (depends on where we start the countdown for the onset of knowledge work industries). Somehow the pedestal on which they have been sitting seemed steady like a rock, and it never or rarely occurred to people that deadlines are actually a mess. Or, a cautious tinge of a thought like “is that all a huge scam?” would have meant going so much against the mainstream of established outdated ways, that rarely did anyone dare speak up.
I’ve always been uncomfortable about the concept of chasing and being in a hurry to release. Ironically, if a release has been pushed against a deadline, and the horses have been whipped, funny thing, but it did become a sure sign for me that the harder the push, the less far off is the actual release date. That’s usually the case with what I call “subjective” deadlines.
Subjective and Objective Deadlines
Deadlines as a biological species in corporate environment can be broken into 2 subspecies: subjective and objective. The universal law that I’ve derived has it that about 90% of subjective deadlines can be turned into having no deadline at all. As for the objective deadlines, it’s harder to tame them, but there’s still a way.
A deadline is subjective:
- For a small product dev company: there’s an emotional desire to come up with a new release faster for the sake of just faster. Usually, this is something that a stakeholder wants to do because he/she believes that this release needs to be out ASAP, or the company will sink into the financial abyss, or the competitors will come up with the same thing that very day. Or — the real classics — the production guys have estimated that the release can be expected at a certain time, and marketing has made it public as the official release date.
- For a softdev service company: usually service companies deal with the 2nd tier of subjectivity in deadlines. It all very much depends on their customers, and since how long have the customers been working with this company, and the bottom line: how much trust do the service company and the customers have in each other. This same situation also occurs in huge product dev companies, when marketing stakeholders plan rigid timeframes for marketing campaigns and activities, and devs are not involved in that. That’s the case of disconnect, and every party has to balance their needs and reality.
The objective deadline is this:
- Something huge. The Russians are now busy building the infrastructure facilities for the upcoming 2014 Winter Olympics in Sochi. This IS a deadline. It can not be missed, and the Olympics construction projects can well be treated with the same intensity as the operations of the military.
- The next possible instance is a grave event threatening the lives and well-being of people. Like, to rescue people from the flood that can wipe away their homes or from other natural disasters, or any other events like that (well, we’re very much into the movie crap of being immersed into all kinds of bad things, like saving the planet just on time before the aliens launch their rocket etc. so I’d let your imagination conjure up any other instances like this).
This is it. Just think about it. The majority of deadlines are subjective man-made disasters. Someone has said that human side comes a long way before software is made, and deadlines are not about the technical side but about people’s nature mostly. What I’m doing right now is breaking into the sacred sanctuary of “this-is-technical-you-know-nothing-about it” stuff with my liberal arts/humanities white gloves on, and graciously pulling all kinds of nasty misjudgments about software project management out of their holes.
My conclusion is striking. We tend to think that problems with deadlines have to deal with the technical issues and technical competence, and meekly mumble about who’s done/not done what as we look for justifications, but that’s not true. Once you’re in the environment of professionals, good rooted into the team, with good contextual AND open personal relations, then the problems float into the realm of how people make their point to each other and how they adjust to each other’s idiosyncrasies. For example, it’s beyond my understanding how endlessly can designers mull over a tiny UI element. To me it makes no difference. In their turn, designers or developers wouldn’t understand how I’m messing around an error message in the product UI. Or a piece of micro-copy. There’s no reason to be mad about it. In a way, we’re aliens to each other, and we can’t go any different than by finding a common language to share and understand our idiosyncrasies. Let alone the idiosyncrasies about design and copy, the most unpredictable part is software. You never know when you can stumble upon an unexpected impediment, ask any developer. Sure thing, it would be stupid to rush the developers knowing that they are competent, and they are working on the problem. This observation relates mostly to emotional deadlines, and is about the silent reciprocal understanding of why we get stuck on our way to the golden release date.
It’s nothing else than the issue of relationships and unity in an organization, to have marketing adjust to the reality of fuzzy estimates and deadlines. Looking at many companies, and at their release dates, I’ve noticed an interesting trend. Major releases usually appear either in spring, or by early fall. That’s quite logical: winter is winter, with its Christmas time, the late fall is Thanksgiving, summer is the time when people go on vacation. This means, one can assume that late February-mid-March are expected release dates, but silently allow the possibility that it would really be mid-April-beginning of May. Or, for the fall releases, make it mid-August but really count on mid-September-October.
As much as I’m an opponent of “to do’s”, it appears I can finally commit to the one imperative how-to: Never push people with “when” unless it’s a matter of life and death. Only hearing this question might make them feel nervous (read, distracted from work and performing worse). It’s because of the ever-dragging legacy of the old-school insecurities, the clash of the need to give estimates and not being sure exactly of what is to be estimated, and the subsequent threat of being labelled as someone non-delivering to their expectations.
One of the things that can help with such questions and managers, though, should you encounter them in your life, is the intelligent “get done” forecasting. As in this report.
You can take these percentage probability forecasts, and show them to whoever needs an estimate of completion. If you’re curious, that’s one of the reports that we did in the recent 2.24 release. It can even work for service companies, if they have done the bulk of the enlightenment work about the fallacy of deadlines with their customers.
It might be hard to comprehend but unless we all become the beacons of the new no-deadline culture, we’d remain stuck in the outdated manual labor thinking amidst the technological progress of the 21st century. Take a look at this link. It’s a well-known Q/A resource for project managers. All of the questions tagged “deadline”, they have nothing to do with technical failures. Rather, people are not sure how should they manage communications and resolve organizational issues. Software development is more about humans as ever, since it’s getting still harder to live with no ecosystem of understanding and cooperation to replace the split reality of deadlines.
We are excited to announce a new major spring 2013 release!
TargetProcess 2.24.0 includes quite a few small and big improvements. Check what we’ve done to help you work better, faster, more comfortably.
10x faster search
We’re close to less than 1 sec search time, but this new search is not only fast. The search results look nicer now, and you can open them both in new tabs and as a pop-up.
Read more about the new fast search in our Help portal.
Relations and Relations Network Diagram
Quite often one piece of work is “informally” tied to another piece of work. For example, the core team is working on an API, and the other teams are dependent on the core team’s progress. Keeping such informal dependencies in your head can be tiresome…
Starting from 2.24 you can track such informal dependencies right in TargetProcess as Relations!
Relations Network Diagram represents a network of related entities:
Relations can be created for any entity (i.e., user story, task, bug, etc.), and they can be of great help when planning or prioritizing. Be sure to check the article about Relations in TargetProcess Help Portal. It has more screens, and explains how Relations are helpful in planning and progress tracking.
New Visual Reports:Process Control Chart and Lead and Cycle Time Distribution Report
The Process Control Chart shows cycle time distribution for completed entities (user stories, features, bugs, tasks, requests) within a certain time frame. Check the screen below. If you see user stories between the warning limit and the control limit lines, this is suspicious. If a user story goes beyond the control limit line, this is really a bad thing, and you should investigate why it took so many days to complete. These limits are calculated statistically; they depend on the overall distribution of stories in the chart.
You can find a comprehensive description of the Process Control Chart here. It includes more screenshots and some examples on how the chart can be used.
Note the new powerful filters. You’ll see more of them later. They can now be used to filter out the entities in the Relations Network Diagram and in the new visual reports.
While the Process Control Chart quickly spots the entities that took too long to get done, the Lead and Cycle Time Distribution report helps you make realistic forecasts. You can filter out any entities, just as in the Process Control Chart:
There’s a bunch of nice improvements to the views: quick convert (all the properties are kept intact for the converted entities), assign 2+ people, switch project quickly in the Info box for an assignment, auto-convert URLs to clickable links.
Besides, starting from TargetProcess 2.24 you can add up to 60 custom fields to any entity.
New History REST API
Check out the new History API in TargetProcess REST API.
The new API will track state changes for Bugs, Feature, Impediments, Requests, Tasks and User Stories.
More info on the new History API in TargetProcess Help Portal
What is a Paradigm?
While there’s been some talk and research about project management paradigms e.g. waterfall, Project Management 2.0, ALM, with the paradigm of agile prevailing at the moment, looks like no one has spoken about the paradigm of project management tools. What is a paradigm, in general? It’s a system of principles that unveils the essential qualities of a subject in their entirety. From this perspective, a paradigm of PM tools would be a spot-on framework for choosing a PM tool. To make it more clear, a paradigm is something that allows a complete 360° view on any subject or matter. I’d say it’s not about the flat 360° view as in traditional geometry, but about a multi-spherical 360° view, as in the geometry of Lobachevsky. In linguistics, a paradigm is a complete set of all the forms of one and the same word realized through declension and conjugation, esp. as in German or in Russian. A paradigm represents the system of approaches to unfolding a phenomenon. Musing about the cross-disciplinary nature of paradigms, how can we apply it to the project management tools, and how can this concept help software developers?
A multi-spherical abstraction
A Basic Paradigm: MS Project and Excel
I’m sure most of the readers have been facing the moment in their professional life, as they needed a tool for project management. Historically, most of us stem from MS Project and then Excel. MS Project served quite well as a clock ticker for the work that’s planned ahead and progresses exactly as planned. For waterfall, this narrow paradigm worked OK, assuming the project is flat and linear.
What changes in agile software development? The project management paradigm shift means that nothing is ever going as planned. The PM tools should undergo a shift as well, from routinely tracking the progress the way it’s been planned, to dynamically sensing trends and registering hands-on performance indicators. Sounds like something familiar? Very close to stock trading, that’s right… and we’re still amazed at how many teams keep using Excel for agile project management. Well, there’re some down-to-earth reasons behind this. Excel comes as a part of the MS software suite, and there’s no need to pay extra for it. One can put data to Excel, and even use it for planning, tracking and reporting. But there’s one essential flaw with Excel. It isn’t a shared collab tool, someone has to keep this Excel file, and while Excel shows statistical trends quite OK, as for stock trading, but it takes habit, skills and extra time to tune it as a decent trend-revealing tool for agile project management (and I’m not even talking about UX and visualization so far).
Excel used in stock trading
The Incomplete Paradigm: Beware Flaws in Assessment
There’re many project management tools out there. Tons of them. It’s not easy to navigate in this space, and when someone is looking to select a PM tool for their company, they use some typical research methods… and bump against the same misconceptions. Let me give a brief outline of some approaches that I consider counterproductive.
First, it’s following a direct pitch. Remember, what happens when someone throws a link at you and says “this tool is just what you need”? By “someone”, I mean people who send haphazard intrusive pitch messages either directly to your email, or in social networks, etc. Normally you’ve got work that needs to be done right now, and you don’t want to interrupt your flow and switch to studying how this tool works, although it might promise a whole new world of miracles. Next, you have no idea if the person who throws the link is aware of your needs. It’s easy to throw a link at someone, but it’s not easy to decide for another person if that’s what they need. OK, you might be tempted to open the link to take a look, and invest some time in studying what it’s about. After taking a quick look, you decide that the pains from using your old tool do not outweigh the trouble and time that you need to invest in exploring this new tool, and you stay with what you have. That’s why following a direct pitch is the least likely way to find what you need (and from the marketing standpoint, the direct pitches are rarely successful).
Second, it’s PM tool assessment sheets. I’ve worked with the leads and clients for quite some time, and what I’ve always been amazed at, that even until recently people have been using those cranky assessment sheets, that should be filled “yes/no” for random standalone aspects which would never put together the complete picture. Like, what changes if we put checks in all the boxes that say “collaboration”, “issue tracking”, “scheduling”, “portfolio”, “resource”, “document management”? Such assessment sheets are clueless. They still give no clear picture of how the tool works, and whether it will address whatever needs and pains of this very company. The feature requirements as in those sheets remind me of the flat geometry confined to the 2D surface. Somehow, they never have such bullets as “good data visualization”, “speed to change contexts and retrieve any data”. That’s an apparent disconnect, where the task of selecting the project management tool is given to an administrative employee, and the real stakeholders, the people who will be working with the tool are left out of the initial screening stage. Well, might be that their process has the stakeholders engaged later, but why not then take a step of extra care to save the stakeholder’s precious time and add a few human requirements? Like, how human-friendly the tool is? Is it easy-to-use? Still, as much as I’m a wordsmith, I have to admit that no words in no assessment sheets will replace the actual feel and sight of a project management tool in action. The complete paradigm of PM tools is supposed to cover all the facets of multi-dimensional chaotic project management, including the human aspect. How about introducing the criteria of learning curve – simplicity/complexity – user background vs. ease-of-use? One can’t make an accurate assessment of those qualities from “yes/no” sheets.
The third most common misconception is related to all the buzz around agile, agile training, agile consultants, “we-should-do-agile-coz-everyone-is-doing-it”, etc. It’s about hearing of the agile adoption, and rushing to get an agile PM tool, instead of taking care of the process first. This is the same as the phenomenon known as Gear Acquisition Syndrome among musicians, when instead of actually playing music people focus on acquiring lots and lots of music gear.
How much G.A.S. is enough?
I believe that if a company is building their agile dev process from within, they acquire their unique corporate expertise which is an asset in itself. It’s this unique expertise that finally helps them run projects with success and use the tools they need. Same with the GAS syndrome: you don’t know if you like this guitar until you play it. You can watch how a local pro makes it out with the instrument in the show room (that’s what consultants do), or you can try and play yourself to get the actual feel.
The Human Paradigm: Comfortable,Visual,Multi-Contextual
So, we’ve covered the basic paradigm of Excel, passed over the hurdles of the assessment sheets and the functional requirements – what else then do we need from a PM tool? We need it to be human-friendly.
A human-friendly data/information capture and delivery by a PM tool means two things: it’s visual, and it’s multi-contextual. I can’t think of anything that goes beyond this final layer. A parallel layer would be learning curve vs. ease-of-use, regardless of user background. That would complete our paradigm: a sophisticated PM tool needs to be pleasant to work with and simple enough so people can learn how to use it just by themselves, with no outside help.
There’s more about comfort and ease-of-use than we’d normally think. Positive emotions facilitate cognition and reduce cognitive burden. When people spend their time working with the PM tool that hinders their flow in one way or another, they get tired faster, and their higher cognitive powers “expire” faster. It’s not just a matter of pure design aesthetics or pleasant emotions. It’s about conditioning people to work more comfortably and successfully with software tools. We like nice architecture and pleasant interiors, so why should it be any different in the project workspace? The visual and omni-functional PM tool brings in a totally different quality of work for everyone involved, and I wonder why this human aspect tends to be overlooked by many. I’ve written more on the impact that software has on the human emotions (read, well-being and productivity) in the article Do You Speak Human, Software?
Disclaimer: I didn’t mean to pitch any specific tools, or provide reviews and recommendations, although it’s kind of more than obvious which agile PM tool is my favourite :) My goal was to outline the paradigm to be used in the assessment of PM tools, and challenge some established patterns of thinking. When going off the beaten track, chances are high you’ll hit the bullseye of your target board.. or process (couldn’t resist the pun :)
Most people like short things: short tasks, short emails, learn-how-to-program-java-in-24-hours books, lose-weight-in-a-month video guides. Modern society is cursed by impatience and time pressure. Information flows hit us from all sides and we just can’t resist. We spend more and more time on shorter and shorter things.
Software development demands focus. You can’t create anything significant hopping from one thing to another. That is obvious. Less obvious is that product development demands patience.
Service development is different. In most cases you have a project with a visible end. It may be a year long, or even several years long. But still project will be completed someday… Or abandoned. Most service products are sprints. Clients pay you money and they want to have something as soon as possible. They radiate the impatience. They set deadlines. They resist to invest much into good engineering practices like automated tests. Yes, you negotiate all that and sometime with a success, but still it’s quite hard to sell a great development process to the customer. So you rush, cut corners, drop some good practices to save time and argue about change requests. Agile approach helps to solve some of these problems, but you still feel the constant pressure. And rush anyway.
This strategy doesn’t work for product development. It takes a decade or more to create a truly remarkable product. Constant rework, constant improvements, constant polishing and learning. You fail, learn something new, improve things and move forward. It just can’t be done without patience.
Suddenly you understand that great thing takes time and it changes your attitude. You learn how to run with a steady pace, maintain energy level and endure the race. In a sprint you have no room for any mistake. Even a little mistake will cost you huge. In a marathon you have time to fix problems and still win.
If you are in a product development business, I can give you several advices:
- Learn how to learn. This road takes many years, you need knowledge to solve problems and invent things.
- Learn how to wait. It is so fucking hard to me. Sometime I feel enormous pressure to speed everything up and run at a full speed. But I realize that it will drain all our energy and development team will be exhausted and washed out. We’ll start to lose people. Morale will go down. That’s not a viable strategy.
- Embrace re-work. Most likely you will have to re-write some parts of the system 3-7 times in the next several years. You should be ready to do that. Re-work is good. It makes things better.
- Ship early. You may think that now I’m a 100% perfectionist who will kill for the 1px design mismatch in a latest release. That is far from true. I like to ship things as early as possible to some closed group of customers at least. For example, we are working on v.3 of our product during the last 15 months. It is still not public. However, we had first users 9 months ago. Currently around 600 people from 100 companies are using v.3, we have constant feedback and make improvements based on it.
Remember, that most people can run a 100 m distance, few people can run a marathon.
SVG background images have been praised in many-many articles I’ve come across. Chiseled SVG backgrounds seem to be an unbeatable option indeed, from several standpoints. But all the articles that I’ve read, they only briefly touched upon the performance issues of SVG rendering i.e. it’s a more memory-consuming operation since browser has to rasterize images anew every time.
So, one day I opened the web app I’m working on, and discovered that my browser is eating memory like crazy: it was about 600 MB (!) for just one tab, and even higher for a Retina screen. I went straight to investigate where this memory is leaking.
My first thought was — why don’t we give up on SVG? But it’s not that simple, you can’t just get rid of SVG and replace it with a .png, since we care about users with high-resolution screens.
I studied some articles and the specs on SVG, and decided to try em instead of px. As I expected, with relative font sizes, the memory ran as low as it would have been for a .png image.
Here’s the SVG vs PNG memory comparison (for 16 icons):
|SVG, em||9216 k||demo|
|SVG, px||101600 k||demo|
|PNG, small canvas||7748 k||demo|
|PNG, large canvas||10060 k||demo|
So, what can we do about it? The first option is to use two PNG sprites, one in normal resolution, and the other in Retina resolution. For SVG sprites, relative font sizes, e.g. em, would be a better option.
After some more research, looks like this behavior is only observed in chromium-based browsers. Firefox, Opera and IE don’t have this problem. Of course, memory usage depends on the size of the canvas, and not on the font sizes being in px or em. But the sizes influence SVG scalability, so keep that in mind when choosing px or em for your particular case. If you care to take a look, we reported this issue to chromium, and it’s fixed now.
Another internal conference, Tau Conf #5, is coming up. These conferences are very special events at TargetProcess, and we look forward to them very much. Why? It’s a great chance to try your hand at public speaking with colleagues as the audience. People share something they have learned from their work, or something related. Gusto for knowledge, learning and sharing are the driving forces for our curious company. Besides, who says there’re no after-parties at internal conferences ..?:)
The only rigid rule for those conferences is: no third-party presenters. Everything else is flexible, as long as your presentation is of interest to the other colleagues. Everyone in the company can volunteer to do a presentation on some subject of their choice. Then we vote, and topics that get most votes are included to the conference program. Conferences are usually held in about a month after the voting, so speakers have enough time to finalize their presentations.
Here’s the program for the upcoming Tau Conf #5, scheduled for April 26th and May 4th:
We’ve done 4 internal conferences already, covering quite diverse subjects. That’s the Tau Conf #4 program from last year:
That’s the Tau Conf #3 program:
I’d like to write more about meetings today. It’s not a series of posts (officially), but looks like it’s evolving as one, since I’m picking up on my earlier posts on how to reduce the toxicity of meetings and how Skype works as on organic supplement for knowledge sharing in our company.
On top of the usual UX meetings and dev kick-start meetings, we’ve introduced a new kind of meetings recently. The company board meetings. We’re just in this phase of growth when it’s about time to try boards for decision making. At the moment, we’ve got the Product/UX Board, the Development Board and Marketing Board. The founders/stakeholders board (the Head Board) has been in action for several years by now; this board is responsible for taking decisions about the company policy, some strategic visions, etc. It’s those 3 new boards we’ve started just now. The boards, usually 5-7 people, work by a simple 5-2 vote (or a 4-1). The board members are of a mixed background: marketers and developers are sitting in the Product/UX board along with the UX people and feature owners (check who the feature owners are); developers and designers mingle with marketers in the Marketing Board. The good sign that confirms the integrity and the common shared vision of our team is that it rarely gets down to any other than 5-2 split-up of the votes. If it’s 4-3 or 3-4, this usually means that the subject requires more discussion, as some essential details might have been left out.
We’ve started the boards for several reasons. One of them is to be able to come up with unbiased visions. As a marketer, you tend to focus on the marketing things alone, so if developers infuse some of their blood into the veins of marketers, or if the UX people get involved in the decisions related to marketing — it’s good. From my experience, a more common case is when things are seen rather from the dev perspective, and developers need to be educated in marketing.
I’ve been at some of those board meetings but for the moment I prefer to keep a certain stance of cross-boardability. I try to make my point to people who sit in the board meetings, but I stay away from being too deeply immersed in the activities of any particular board. Why so? I have noticed one interesting trend. The boards start wearing out once they get into action (check the header image). It’s about the same, the more you rub the board washing your laundry, the more soap foam is generated, blurring the clarity of your vision. Well, this does not necessarily mean that the laundry will come out dirty, rather the other way round. But the laundry lady needs to clean the board from the used-up soap foam to be able to see if the laundry is clean. Not sure if someone actually does laundry this way — we’ve got washing machines after all — but, well, there’s no machine for the board’s decision-making, that’s why I’ve applied the soap-and-washboard metaphor here.
The intent behind creating our boards has been exactly that: to keep the vision fresh and clear, and consider things from all possible perspectives. Looks like some rotation is needed to maintain the freshness, and might be it has to be done more frequently than we supposed at first. Or, a fresh quick look from someone who is not a board member, but a keen observer could be helpful. If you’re not rinsing off the old soap foam, your vision will lack clarity and perspective, not to mention the notorious brain drain which would then creep in and poison your board meeting . Perhaps, we need to come out with more sophisticated rotation patterns. Or, perhaps at some point, we might need to merge the UX/Product Board and the Dev Board into one Production Board. Or, make it Marketing Board + Product Board and UX Board+Dev Board. We keep looking and trying.
P.S. Happy 8th of March, ladies :)
In one of my previous posts, I contemplated why meetings are exhausting, and uncovered a possible reason for that: people get tired naturally when they try to share too much within too short a time frame. It appears that asynchronous communication in between meetings helps to minimize this drain, so I’ll tell more on how we do it in our company.
In general, this is searching for the most comfortable process of knowledge sharing, which wouldn’t interrupt the personal productive flow of people and at the same time keep them informed just enough of what the others are sharing, in the context of each other’s responsibilities. One of the traditional ways of asynchronous communication are all kinds of comment threads – just like in this blog, if you scroll down a bit. We have the threads of comments built-in into TargetProcess, and they work mostly as status or diagnostic messages, like “changed the code”, “need the design”, “rolled out to production”. For meetings and creative exchanges, something in the middle is needed. Not as slow as email, even not as slow as comments, but something that allows a delayed reaction and powers the dynamic exchange of ideas at the same time. Note, that I’m speaking only about the communication within a team of like-minded people here. Google Groups, Wikis – can you believe it, we even tried CampFire. Michael was tempted by its design, and decided it’s worth a try. It didn’t last long however. Just wasn’t as convenient as .. yes, you guessed it right, the good old Skype.
Whatever we tried, we ended up going back to Skype. Turns out it works best for our purposes, and in our environment. Of course, we’re not using it as an “instant” information machine-gun; people are not required to answer right away. We’ve set up a number of Skype chats. For example, there’s a “TargetProcess Design Folks” chat. The design people use this chat to build the collective taste in UX, they share links, discuss drafts and help each other come up with the UI concepts. I’m pretty sure, not any number of the formal UX meetings will cover the wealth of ideas and references that this Skype roll contains. So, for this creative exchange a Skype chat is a perfect tool. The only concern might be that every task has its due time: time to exchange ideas in the chat, and time to go deep into yourself to come up with your own thing. Fortunately, one can turn off instant notifications for Skype chats, or have the notifications sent out only if a certain word(s) is mentioned.
Among the other Skype chats, there’s one called “Product”. Anything related to TargetProcess as a product can be discussed here. Feedbacks, ideas, improvement suggestions, some of those suggestions can then be added to the backlog and implemented in TargetProcess. Our support and infrastructure team have their chat as well. Unlike the chats about UX or the Product, or the chats for various boards, this one quite often requires an instant reaction.
Skype chats are a good multi-purpose tool indeed. They provide instant notifications to support and infrastructure teams, and at the same time, they work as an optimal async communication tool, when it goes about ideas/knowledge exchange to back up the team thinking. The consistency of this async exchange keeps everyone on the same page when at a meeting, and people are less tired. There’s no way one can stay completely fresh after a meeting, sorry, I wouldn’t commit to a “how-to” here :)
The more I think of it, the more it looks like Skype has the features that an agile team needs to generate ideas from the common pool, to react quickly, and to get into action. It might be that Skype won’t appear that universal for a company less agile than ours. I’m just telling about our experience.
This is a very exciting week. We’re leaving the old office - wow, we’ve been staying here for 3 years! – and moving to the new one. Office moves are always exciting. They add a tinge of chaos, complexity, and give a fresh new drive to the usual office life. If you work for quite long to build the product up to the vision that you have, it might get boring at times. You might be losing gusto, so apart from the purely practical need – well, we really DO need more office space now – this event is like stirring the low-lying waters, to get even more clarity and focus once the mud settles down.
Like with many other things, there’s the eagle view vs. the hedgehog’s view. What I call the “eagle view”, is coming up with an overall design of the new office space, having the vision of how the activities will run there, taking care of big things that eagles presume would let the smaller things get resolved by themselves. Michael has used the foxes and hedgehogs metaphor in his post on learning, so I’m catching on it, but with a bit different take on hedgehogs in the context of office moves. Hedgehogs are more concerned about who will sit where, and while we do have a draft plan for that, the very details are not quite clear. Looks like we’ll be moving like molecules in the Brownian motion before we finally settle down.
So, where are we actually moving? This is a 3 tower building, and we’re taking one of the levels, spanning across the 3 towers, with 10,764 sq ft (!) of space. The most amazing part for me about the new office is that the towers actually have the round walls! Like in the medieval European castles.
The New Office
Here’s the eagle view plan of the new office:
That’s the interior design for one of the towers, we call it the Green Tower:
Here’s the Orange Tower:
The Old Office
While the move is a chaotic fun event, there’s a little bit of nostalgia about leaving the old office. We did have some good times here. When we moved to this new old office 3 years ago, we were not what we are now, so the old office has helped us grow and develop. This office held the creative energy space , and I will keep fond memories about it. Well, after all it’s been only a 5 minute’s drive from my place, and the new office is a 10 minutes’ drive! (*ironic*)
Just a few sentimental pictures, as a token of gratitude to the old office. A tummy cat sits on the book shelf, peeping on the Mac screen.
The old designer’s room, full of light and good vibes.
The room we used to refer to as the “sports room”. Not exactly, the guitar was also there. Now in the new office we are about to have not just a room for sports but what can actually seem like a sports hall, with about 500 sq feet space.
A small coffee table with illustrated art books and magazines:
That’s my favourite pet. Zamioculcas, also called “the dollar tree”, mind you. I find this plant fascinating. We brought it to the office about 2 years ago, it was quite big already, and now it looks like a piece of tropical rainforest. I adore the lavish greenery of zamioculcas, and my desk is totally hidden behind it.
Actually, this is my biggest hedgehoggy concern about the move. How are we supposed to move the tropical rainforest plant from one building to another, if this nasty winter is still there, and the temperature outside is below freezing? Hopefully, zamioculcas will survive the move and grow stronger. Just as us, people.