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.
No Deadlines?
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.
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 :)
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:
Read more about Lead and Cycle Time Distribution Chart.
Improved Views
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
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:
That’s the Blue 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.
One wouldn’t normally relate Valentine’s Day to the office life of developers, designers, QA people and other guys involved in software development process. Such qualities as love, compassion, care and empathy do not obviously stand out as prevailing in our work. It’s mostly rough and tough. The word SCRUM is actually derived from rugby, a guys-only sport where the winner is the one who stands tough and pushes hard. As people work to create software, they quite often tend to be unyielding, protective of their opinions; they’re used to pushing, and sarcasm often comes out as closest to ever having any empathic perspective on your colleagues.
Have you ever been in such a situation, as a designer or as a writer or as a developer that you’re given a task, you work on it all alone, you come out with more and more drafts, and everyone seems to be criticizing your work? It takes stamina and a good deal of emotional stability to be able to withstand sometimes pushy remarks. No, I don’t mean to say that colleagues intentionally want to make you feel resented. All they want is to get work done, and their comments have the sole purpose of helping you complete whatever you’re doing as best as you could. They’re beta-consumers, the first to take a look at what you’ve created, before you shoot your design or a piece of text to the outer world.
Here’s the point. Like I mentioned in one of my previous posts, we’re a company with trust established as one of the signature values. I’m not showing off, just citing the fact. So, a possibility that someone is saying something to hurt another person, is totally left out. However, even in this healthy environment, and with all the love for the work that people have, the universal laws of biology have a life of their own. The work is demanding, creative, and even as rewarding as it seems – your brain and your neurons just get tired. It’s purely physical. People are made of flesh and bone, they’re not made of hardware. With this tiring, people become hypersensitive to the remarks about their work, and may start taking them personally. One can’t get away with it. So, I’d like to highlight the need of awareness about this quality of human psyche.
If a colleague is fatigued, stressed out about some work, or if some personal factors add up to the stress, what if we try to feel the challenge that our fellow human is undergoing, and instead of being purely work-focused, give a little bit of personal attention and some help to each other? It’s not that hard really. Sometimes, if someone is stuck with a design draft or something of that kind, instead of giving some remarks on what this person does, wouldn’t it be wise and nice to switch the focus from judging to helping? At the end of the day, it’s not only about helping your colleague. It does contribute to the task at hand. You can save your colleague by dropping in new fresh ideas, or see if there’s any other way to help him or her. If you don’t know how to brighten up the life of someone who spends their days near you in the office space, go ahead and find out. Wipe the dust off of your right brain hemisphere or the heart chakra or whatever other scanners and sensors you could put to test for the other folks . This would also provide a side balancing effect for your own brain, giving it some rest from analytical tasks for a change. Maintaining the culture of compassion in a geeky environment might look like a weird idea, but what your company is worth if it’s not about people? People are the greatest asset, but somehow they’re not usually treated as such. So, is there any other better day than February 14, 2013, to emphasize the need for human relating, as well as the need to be more loving, compassionate and non-judgemental about others?
Happy Valentine’s Day everyone!
Over the last several months I’ve published 2 parts of the series on agile retrospectives, and the 3d part is supposed to come up as it gets closer to spring. By the way, the Groundhog Day will be this Saturday, so I’m eager to find out what the groundhog predicts :)
This whole work, research and observations led me to musing about meetings in general. Most probably you’re familiar with the “Meetings are Toxic” maxim from the “Getting Real” book by 37 signals. I tend to agree with it. In short, meetings are huge energy drainers and productivity flow breakers, so the deal is to figure out if this energy drain is actually worth it. However, there’s at least one great thing I’m very happy about when it goes about our meetings: there’s no space left for elephants in the room! Unlike in the picture below. :)
I’ve been a part of some meetings in our company, and I’ve talked to people asking if meetings are productive? What are the other ways to reach the desired outcome? As always, there’re pros and cons. If we try to follow 37 signals and their maxim, we will most likely miss something vital at the end of the day. People get together and talk at meetings. Getting together and talking is good, that’s for sure, but is it paying off the value? The answer would be “yes”, despite the subject drift-offs, someone holding the attention of the group for more than it’s appropriate, being poorly prepared due to the overload with other tasks and commitments, etc.
One note though: this “yes” holds true for our company, and it depends. Besides, there’re various kinds of meetings. Developers get together to discuss, sketch and define the way to do some functional feature. These meetings occur all the time, and they don’t seem to interrupt the productivity. They really do matter. What I’m getting at are product management meetings, UX meetings and other larger company meetings.
It appears that the core of the “it depends” is hiding in the ability to create an asynchronous loop of valuable inputs into the product vision and UX concepts. What if we all were able to see as one without the drain of a meeting? To give it a personal perspective, through all the years of working with clients I’ve felt a disconnect, a slight or at times a larger one, between what production does, and what leads and customers want and feel. We’re doing better now, which is great, and people who interface with leads and customers are able to make a meaningful input at the product board meetings. In our company, the product board is a 7-member decision-making unit, which includes developers, UX-ers and people who interface with leads and customers. The only nasty problem that persists is that meetings are a work in itself. If only someone’s job would be solely to attend meetings. There’re other tangible tasks to do. Designers need to actually create sketches and prototypes, developers need to build the architecture and write the code, and marketing/support people need probably even more energy as they are always in the trenches, talking to leads and customers. Oh. And product managers and feature owners are responsible for smart product decisions.
Unfortunately, smart product decisions are not 100% guaranteed by those meetings only. We’re sticking to the board meetings approach so far, and it’s definitely a step ahead in our evolution. Seven minds are always better than one mind. But is there a comfortable, slow-paced way for those 7 minds to unite in one vision? If seven people are trying to share their product perspectives over a short time frame, as in a meeting, that’s where the ultimate, never-mentioned source of this exhausting drain sits. It’s simply about the way we are wired. You just can’t pour your vision from your brain to someone else’s brain in one quick shot. It’s not like with whisky. It’s exactly for that reason that we inevitably face the need for building the gradual, asynchronous awareness of the product as a whole. This is related to Michael’s recent Specialize or Generalize post, and it goes beyond the boundaries of software development as such.
Back to 37 signals. Their “Meetings are Toxic” judgement is sharp, clear and perfectly correct in the context of their evolution. We’re doing things our way, as we try to back up meetings with various asynchronous ways of building and sharing a versatile product vision e.g. Google Groups, internal blogs, wikis, talks in the office kitchen, etc. Asynchronous exchanges are compulsory homework before the meetings; they work great for any knowledge work, for many reasons, and it would take a yet another blog post to tell more about that. For now, I will just reference this great article on asynchronous communication.
In the first part of the series on agile retrospectives, I mostly focused on the visual inventory as I went over the reports and charts we’ve been using at TargetProcess, along with some stuff from other people. I’ve also given an outline of the heuristic, trial-and-error approach as the essential methodological foundation for running retrospectives.
In the second part, it’s time to look into the secret nuts and bolts of what actually makes retrospective meetings work. I’m stepping out to embrace a broader picture, as the subject of company culture — it’s exactly about the quality of this oil that makes the retrospective engines run — is limitless. It can’t be reduced to a few worn-out, cliched how-to adages.
Maturity and the culture of trust
A team has to be mature enough to hold retrospectives. One of the common pitfalls is when teams are eager to run retrospectives just for the sake of running retrospectives. They know that if they are supposed to be agile, they need to do retrospectives. But it’s not as simple as following a guideline. The need has to come from within. The team has to develop this intrinsic feeling of power to solve their problems and – even more important – to accept the responsibility.
So how would you know if a team is mature enough to run meaningful retrospectives? If it’s not, how do you go about nurturing such a team? Do you have to bother at all?
First and most, it’s about the no-blame culture. Well, it’s better in the positive, not in the negative, so let’s put it like that: no-blame culture is the culture of trust. Let me mention here that trust is one of the signature values in our company.
The culture of trust emerges from a dozen of subtle ingredients. There’s no exact recipe as to how much of each ingredient you should take and in which proportion. It’s not a cocktail, for better or for worse, but it does bear some resemblance to a cocktail, as oftentimes you’ve got to stir, or even shake it well before enjoying!
Communication: tell me who you are, and I’ll tell you who I am
Following the lines of cocktail making, communication appears to be the basic ingredient of the culture of trust. I completely agree with the point of this article that “lack of communication” is an umbrella term for all kinds of hidden conflicts and unresolved issues. It represents an antithesis of the culture of trust.
So, if in your company “lack of communication” is light-heartedly referred to as the common excuse for troublesome issues, that’s when the red lights should go flashing, better yet with the fire alarm sound. When people don’t talk, or misunderstand each other’s messages, or are reluctant to spend time explaining their point of view– this is the surface skim of what can be a severe turmoil of contradicting values, assumptions and beliefs.
For a certain time, this turmoil might simmer as a dormant volcano, but the eruption can come at a bad time, when everyone assumes the volcano is asleep for good. At a retrospective meeting, for example, in the form of finger pointing:
Finger-pointing, it seems, falls short among the other consequences of the notorious lack of communication. Look, if tons of paper and web pages have been wasted to research/discuss this problem through and through, but it still persists — it means that avid readers are missing the point in their own organizations, being either short-sighted or far-sighted, or sometimes even both. It also means that some essential things are left off from those writings, as for some reason people fail to fix the glitches once and for all. That’s because they don’t get to the bottom line.
For now, I’ll take just one cultural pitfall related to retrospectives and meticulously dissect it, tissue by tissue (surgical metaphors seem to fit better here than cocktail recipes).
The pitfall: no one wants to attend retrospectives
All right, about this one. Some common tipsy-tricksy symptomatic cures and surface reasons for this pitfall I’ve seen in some books include:
- people don’t want to spend too much time on a retrospective, that’s why they rather stay away, so let’s set a time limit of 1 hr (insert 0.5 hr etc.), and this will fix it
- no one wants to attend because it’s soo boring, so let’s make retrospectives fun! Let’s go somewhere outside and invite some clowns so they entertain us, or let’s have gourmet chefs cook delicious food for us. Only then a retrospective will work.
- people don’t feel relaxed enough. They’re shy to speak up, they experience social awkwardness, so let’s do a group therapy session with a set of relaxation exercises.
How does that sound? Shallow, at least. So, I’ll run the chain of whys to find the underlying deep reasons (see the first part for another example of the whys technique).
No one wants to attend retrospectives. Why?
They believe this is a waste of their time. Why?
They decided to take some actions at the previous retrospective, but it didn’t work. Why?
Everyone seems to be fine with the current setup. Why?
… and so on. Most typically, the chain of whys will uncover one and the same issue: a retrospective is not a meaningful activity. Sometimes, a retrospective is just a ritual the team leader or the CEO is following to do agile by the book, while in reality they’re well aware of all the problems, and already have some solution in mind. So, a retrospective in this case is more of an opinion-check meeting to sense the atmosphere in the team, and to see if the leader’s decision is aligned with the expectations of the team or not. Of course, it’s not all black and white. The authoritarian leadership style is hardly viable anymore, but some annoying breadcrumbs of this style can cause cultural itching. Nor an utterly team-based ruling will make it work ultimately.
A report from the trenches
I’ve already mentioned briefly that we’re now working on the new version of our product, and we’re back to doing retrospectives. Recently we’ve had an intense 16-day span called Subbotnik to come up with what turned up to be a private pre-beta (not even a beta so far).
So, there was a retrospective, and the team along with the Scrum Master decided that we’re now doing it in a milder mode, with good old 2-week iterations, and even with a burndown chart. Also, there appeared to be a deadline (something unheard of in our company for several years), so people somehow decided that we need to suspend the IDP (Individual Development Program) until we release for the deadline.
A side note: we have an individual development program, similar to Google’s famous 20% time, and this is one of our signature practices based on the essential company values. Maybe the Scrum Master was too rigorous in propelling his methods to reach the desired outcome, or the team believed that this deadline is indeed a matter of life and death, either way, they decided they’d suspend the IDP until that deadline. There were signs of the latent simmering, and after some get-to-the-bottom-of-it discussions it’s been finally made clear that we are NOT actually chasing any particular deadline, we just need to do it as fast as we can, until it comes out good (in short), and we will not sacrifice the IDP practice to this deadline.
This is a very characteristic example, a perfect specimen of “the lack of communication”. If the team and the Scrum Master were aware that there’s no deadline actually, they wouldn’t have opted for holding off on the IDP, as much as it means to our company. So, the lack of clear communication caused a slight shake to the cultural foundations, which later on might have developed into the subdued discontentment.
The core of this deadline/no deadline problem lies in something personal. It’s about the desire to come up FASTER with a great new version of our software, the software that is so incredibly helpful indeed. If speed becomes an obsession, it can backfire with the unpredictable side-effects. Anyhow, in our case, the urge to deliver fast collided with the higher values, besides, we’ve learned that deadlines might only work for Subbotnik (the development practice we’re using to clean up residual bugs).
More analysis: we’re a company with the culture of trust. So, the issue of finger pointing hasn’t been affecting us much, from what I see. But at times some communication glitches occur. Even with trust established as the core value, lack of communication might produce the effect of hidden blame placement. Generally speaking, for any production work, the people that one wants to criticize most are those who do not deliver enough information in the context of tasks done together. This non-delivery of information, I think, is not an intentional evil act, it happens inadvertently. If someone is obsessed with speed, it wouldn’t occur to them that by keeping the latest update or idea to themselves they’re doing anything wrong. This is the case of too narrow focus, or maybe being too far-sighted, letting people out of the mutual loop.
You might ask: so what, what’s the solution? Is it just one more story about the lack of communication? Is there any real cure to it, other than the recipes fit for kids daycare? Note, that we’re still talking about agile retrospectives based on our IDP non-suspension case. The real cure is to get the point through to people who set the outer culture and the inner culture. Lack of communication would continue to be referred to as an all-forgiving excuse, until someone who is in charge truly gets that the side-effects violate company values AND in the long run slow things down, not speed them up. That’s a paradox, very well known from the story of the turtle and the hare: Festina lente OR “Hurry up by being slow”, as translated from Latin. Things will not happen faster if you save those few seconds on not mentioning an important update to people who work all together, especially in a location that high. This famous picture brightens up the doorway in our office, along with some others, and I find it particularly fascinating.
To put it in other words, no cultural attitudes are shifted by a compulsory decision to follow some prescribed “shoulds”. The attitude might only change if an established behavior pattern is violating some higher meaningful values. I’m not giving any “how to make bad patterns change” advice intentionally, nor saying what those higher values could be. There’s no universal answer and recipe. Every organization has their own secret nuts and bolts, and in the end it all gets down to people, their personalities and interactions. Forgive me, my dear techies, but it’s about psyche and emotions, not about stats, graphs and calculations. Binary thinking with its universal “wrong/right” -“good/bad” rhetoric has no answer. There’re countless subtleties and nuances. The point is to be able to identify the prevailing idea or sentiment or value, and go from there.
Here’s a simple life-based example, not related to software development or project management, just to show how “need” or “can’t stand this anymore” beats “should”. For my tennis practice, I have a set of balls, usually about 60 or so. They last for about half a year, sometimes longer, and then they need to be replaced with a new set. My latest set of tennis balls has been alive for almost incredible 12 months, and it suited me OK, because I’m practicing on the fast surface, and while old balls don’t bounce as fast as new balls (well, there’re different varieties, but this particular set had exactly that aging pattern), it’s almost like the imitation of the slow clay where you have more time to get to the ball and to make a good move. The fast bounce has some disadvantages, to cut it short, and it’s not what I’m focusing on at the moment.
So, my coach kept reminding me that the balls should be replaced, that they’re old and they bounce slowly. I kept dragging, finding excuses not to replace the balls, although, of course, I should have had them replaced weeks ago. Guess what did the trick to me? The sound. Old tennis balls produce this particular “rotten” sound, and with my sensitive musical hearing, there came a time when I finally couldn’t stand it anymore, and took care of the replacement without further lingering. So, you can see that the “should” didn’t work, not until a higher value was challenged.
Single-Digit Teams and Mainstream Advice on Retrospectives
The closest I can get to a “how-to” style is as far as saying that a single-digit group (<10 people) is less likely to have communication problems, and more likely to act sensibly as a team, at retrospectives as well. But again, organizations change and grow, and what has started as a small start-up becomes a mid-sized well-established business.
Back to the tips and tricks I’ve mentioned above. I can’t say that they’re good for nothing at all. Quite often, in a larger organization, there’s no real lever to influence culture shifts for people assigned to run retrospectives. If someone is confined in a certain space, like, a singled out task of doing a retrospective – then they would look for the ways to create some ado around this ritual, and operate in the limits for which they’re accountable. Role play, shuffling moderators, allocating fixed times, inviting clowns etc. — such advice is tailored to this very audience.
But I hope the awareness is there. The rituals do not set in motion the really powerful driving forces in a company. That’s what I’ve tried to outline in this part.
To be continued
