At this time of the year, as we count our blessings and give thanks, I suddenly found myself thinking: “Thanks for the learning experiences.” I find real delight in learning and exploring, and I’m sure many of you do, too. Learning is interwoven with the challenges that we encounter as IT professionals, no doubt. We have to learn, learn and learn to do our work well.
If we replace “run” with “learn” in the famous quote from Through The Looking Glass, it would sound just right to what we have to deal with:
“A slow sort of country!” said the Queen, “Now, here, you see, it takes all the learning you can do, to keep in the same place. If you want to get somewhere else, you must learn at least twice as fast as that!”
Let’s now consider what people normally do to learn. Do they gauge the mainstream education techniques with their individual needs? Apparently, no. Well-intentioned corporate managers send employees to conferences believing that’s the best thing they can do to help people grow professionally. Have you ever been to a conference or a training, wanting to learn something new, only to find out that you’ve spent several days listening to truisms? The real outcome of such an event might be the feeling that you’re not alone, that you’ve mingled with people who have similar problems. Unfortunately, there’s no such takeaway from a conference as a solution to a real problem. That’s the bottomline: we often mistake studying for learning.
Most of the conferences and educational events are focused on making people feel that they study, rather than having them learn meaningful things.
What are the signs that someone is studying? It’s usually rote memorization, passively absorbing a lecture, doing abstract assignments. Learning is about taking lessons from your own challenges, both personal and professional, exploring and finding the answers to your own questions.
This awkward feeling about conferences has its roots in the wrong belief that techniques used for educating kids and teens should be copy-pasted to professionals. This grave misconception costs thousands of wasted hours that adults could use for real learning. Studying does work well for kids and teens, no question. Youngsters have to acquire some boilerplate knowledge to get started. Rote learning is great if a kid has to memorize the multiplication table. It’s all different for adults. Mature brains and mature judgement excel at recognizing and enhancing the patterns they internalized from life experiences, that’s why adults are even biologically less prone to memorizing things they don’t really need. That’s why we skip information if it has nothing to do with what we’re currently preoccupied with.
Instead of taking a formal stance and spending corporate budgets on conferences, executives would be much better off encouraging the culture of on-site learning. If I need to learn something — I will learn it. That’s how adults think. Another good scenario for learning is when one becomes genuinely interested in some subject, and wants to dig deep into it. This is what I call self-powered learning and exploring. It’s a lot more exciting and rewarding (and I speak from my own experience here), than sitting in at a conference. I also find that mutual mentoring (or a peer-to-peer exchange of insights, thoughts and opinions) between professionals is a great way to learn. That’s where conferences might actually help, as I’ve mentioned above. They are not that hopeless, after all :)
We need to be clear about what we expect from such events. We can not afford going to a conference that only touches a tip of an iceberg of what our real problem is. Do we want to socialize with the like-minded, to hear their stories, and share something with them? Or, are we taking this conference just formally, as a sit-in event? If yes, why not spend this time on an intense research, to get some real clues to what you want to achieve?
I tried hard to keep this major secret to myself, but looks like it can’t wait anymore. I will unveil it now.
Empathy is the most important tool of a UX designer.
In other words, a feeling of affinity with others.
Everyone has heard that to catch a criminal one has to think like this criminal. To understand users, one has to become a user and start an account with any new web app that happens to come around.
There’s a very simple technique that can be used to develop empathy: watching yourself. You need to ask yourself such questions as:
- What makes me happy at this very moment?
- Why do I often mix right and left?
- How did I know that this non-underscored text is a link?
While others suffer from muzzy reflections, phobias and clumsiness, you can easily turn those faults into advantages.
Once you’ve come to terms with yourself, move on to your loved ones. Ask them questions and try to guess the answers:
- Sweetheart, why are you so hysterical about this witty thing I’ve just said? Why this very thing?
- What motivates you to put bread to the fridge?
- How did you know that this blue button represents a call to action?
Do whatever it takes to retrieve honest answers as you check your assumptions.
With time and practice, you’ll learn to see the world with any stranger’s eyes. Closing your eyelids and relaxing in the chair, you will effortlessly visualize how your user scenarios are followed by a globe-trotting freelancer in Thailand, or a boxer politician from the Ukraine, or by Angela, the lady who cleans the office on Thursday late afternoons.
The personas method popularized by Allan Cooper will seem an innocent child’s game.
Slow down, slow down, it’s not all that blissful.
Empathy does not endow magical powers to read everyone’s mind, understand the motives and predict which button will be clicked. In most cases there’s even no need for that.
What empathy does though: it helps UX designers to get a bit higher above such coolish things as kerning, “pixel perfect”, skeuomorphism, flat designs, mock-ups, UI kits and discover completely new challenges.
You won’t get bored for the rest of eternity helping real people with real problems.
Holiday season is in the air. Thanksgiving is coming next week, and some of us have already put up Christmas trees. Swinging into the holiday mood, I’d like to share some things that I find especially sweet in our office. Not that we have only 5 of them. There are many more! I just want to share them in sensible chunks :)
Sweet thing #1: Cute Ginger Grater
We have this cute tiny grater for fans of ginger& lemon tea. One can slice ginger with knife, but it’s this little thing that gets the maximum out of the ginger flavor. Ginger & lemon tea is very toning. It’s a great beverage for the fall-winter season. No Photoshop was used in this image:
Sweet thing #2: The Magical White Tree
Sweet thing #3: The Blue Cat
This cat is a very influential guy. We use it as a token to identify who is in charge of automated test runs. The cat obviously feels some affinity with deer. Another sign of Christmas coming :)
Sweet thing #4: Inspiring Wooden Clothespins
A custom artistic installation piece on the desk of one of our QA engineers:
Sweet thing #5: I Love My Team badge
This one needs no commenting :)
Having published several posts on organizational culture and communication in agile teams lately, I feel compelled to write more. Here’s why. Looks like there’s a gap in people’s minds when it goes about cultural- vs. production-driven thinking. The very presence of this “vs.” shows that task-oriented project managers, product owners, IT directors and other people in the positions of authority have a loose attitude toward culture, time and again. They consider it a nice-to-have extra, while their main focus is on what appears to be those “real” factors that impact production: the count of user stories done, or bugs fixed, etc. In general, they want graphs and reports for everything and anything. However, as it comes to a candid retrospective analysis, the bottomline reasons go past figures and find their roots in the organizational culture. Alas, there’s no way to read it from a graph, as to how culture flaws and faulty personal interactions might result in a late release. Even more, considering this innate unquantifiability of those, there’s even a greater need to factor communication in. Keeping organizational culture polarized from production is a luxury one can’t afford, as it comes at a cost. Not an ethereal, but quite a tangible one.
Personal interactions wouldn’t be all that important, if software development wasn’t a sum of creativity and knowledge work. While one can formalize processes and stats on the machine-like actions, the quantitative metrics, the human aspect can hardly be formalized at all. The best attempt that I’ve seen so far is this:
One can draw a parallel between unattended cultural bottlenecks and impediments to the development flow. Any unspoken concern or unaccounted for trait of personality may impact the production results big time. Here are some examples that would help make sense of this viewpoint and trace the dependency between cultural traits and tangible costs.
As a brilliant UX designer, you are working on some concept, at a hypothetical software development company. Your work is very important to the company, and you are in a team with other UX designers. Anyone involved in UX design knows that it takes many sketches and drafts to come up with a final approved solution. Here’s what might happen next. This person has put everything that she has into this design, and is eager to see her work shipped. However, if the approval decision is made by a group, there are some nuances. On the one hand, a group can make a positive contribution. As they say, “many heads are better than one.” But what if this group approval takes too long, and it’s essentially not about the major flaws, but about some tiny details, that when communicated to this brilliant designer might leave her feeling as if the peers are too picky? What if debating over a design becomes too tiresome, day after day? A very unspoken of case, but what if this group has lost their focus and — a very bad scenario — their feedback comes wrapped in an unconscious pursuit to emphasize their own knowledgeability and authority in approving this design concept? This UX super hero will get discouraged, burned out intellectually and emotionally and…. stakeholders know that good UX designers are not easy to find. That’s where it might come to a crack that would leave this person dissatisfied with their job. In this case, organizational culture and personal interactions worked to the negative, diminishing the company’s assets.It was counterproductive to stick to the decision-making model (the group approval) as it didn’t resonate with this person’s creative style. Could be, just to continue with the storyline, that this UX designer prefers one-on-one interactions and is better off dealing with one person in the position of final approval, who would get the condensed meaningful feedback from the group to this person. The same example can actually go for developers, as they take group decisions about an app architecture, framework, code guidelines, etc. One other common concern about group decision-making is that it favors assertiveness of expression over the value of contribution. Someone with an assertive personality style would catch the group attention easier than someone who is less self-confident, but nevertheless has some valuable ideas to contribute and might keep them unspoken, if the group chooses to skip the contribution from this person. That depends on the organizational culture. Then one can sit and count the cost of solutions that have been left unattended this way. Such losses can be directly attributed to the flaws in organizational culture.
I’m certain many of you might recall similar cases, tracking the outcomes of what appeared to be just glitches in communication. It takes some thinking and weighing choices to maintain organizational culture that organically arises from the context of the tasks at hand + unique personalities. Even when one spends some extra time on that, it pays off as the whole organization will benefit more from a few wise decisions than from too many erratic actions.
.. and when not.
I wouldn’t exaggerate if I say that intensity is the most appraised quality of a tech leader. There’s a very valid reason for that: one can hardly accomplish a lot with a lax attitude to a plethora of tasks that have to be just done. When a tech leader exercises the attitude of intensity to the things they do, it is picked up by the whole team. I’m leaving off the part about organizational culture that breeds such leaders and followers in an organization. That’s something I’ve written about previously in the Project Manager or Tech Leader? article.
This time I want to highlight a flip side of intensity. This focus can be a blessing, but it can also be a curse. Think about it: what if a tech leader is putting all their ardor into actions that don’t seem to be attuned to the changing organizational or market dynamics? The actions that don’t feel in sync with the changes? As an example, might be that the decision-making mechanics is not working well in the company, but one still sticks to it. Or the business environment has changed, but too much focus on the actions originating from the expired mindset is holding the organization back.
What I’m trying to say: there’s a subtle balance between being intense and being loose. Yes, one won’t go far if things that need to get done float at a leisurely pace. Actionable initiatives have to be pursued with ruthless intensity and focus. In my humble opinion, there’s no other way to do meaningful things. However, if one is overly immersed in the planned actions, they might lose sensitivity and ignore some alarming signs. Such a leader might think to themselves: “Hmm, I feel something is wrong. But I don’t have time to think about it now. I need to act.” That’s where the catch is.
If a thought like that pops up in one’s mind, it’s time to get loose. A moment of looseness will create the space to think about what’s not going well. Wear another hat, in a way. One can go meditate, or just take some relaxed calm time to contemplate and decide what has to be done about this alarming symptom. If there’s even a slight feeling of misalignment between an organizational practice and the expected outcome, the more time will elapse going on with the intense actions, the more it will cost to the company. Tech leaders have to develop this feel of just-in-time switch from intensity to looseness. Too bad if this switch is not working. The rigid intensity blocks seeing the signs. Looseness here is about the ability to come to a halt and to look at those intensely pursued actions from a new perspective.
Taking a shift from intensity to such looseness just in time is the trademark quality of a star tech leader. It’s quite easy to follow through and to be confident about the things that one already knows. It’s much harder to be sensitive and attuned to the things that one isn’t yet aware of. However, being able to do so is one of the components of lifelong learning — and one of the essential traits of a tech leader.
Deciding what to do next is one of the hardest jobs in software product development. It looks quite easy at the start, with a fresh new product, and with a one-digit team, but at some point in time, as the product expands and grows — and lucky is the one who lived up to that moment! — we start facing some tough choices. Seems like oh so many new features are much wanted and much needed, and this decision-making becomes a very uneasy task. Even with the choices made, there might be a backward feel that another feature or improvement should have been given a higher priority and go first.
Targetprocess is quite a mature product (almost 10 years young), so we’ve had our share of those pains and choices. Some practices have been helping us decide along the way, and I’d like to share a few tips on what works, and how we continue to explore the better ways for decision-making.
Ideas and Votes
Collecting the suggestions (ideas) from customers and leads is the most obvious thing to try. That’s what we keep doing all the time. People have been able to submit their ideas and vote in Targetprocess Help Desk portal almost from the very beginning. Here’s how this page with ideas looked in the early Targetprocess:
The more votes an idea gets, the more likely it is that this feature will be implemented. We’ve been counting votes, and that’s how quite a few of the features squeezed into production. Some features had to wait for several years though, before they finally were implemented.
Then, as we’ve been coming up with an innovative version of our tool, we craved feedback not only from customers, but from anyone interested. From anyone, who spent some time playing with Targetprocess 3. We are using UserVoice to get the best of this impartial and objective feedback . UserVoice is a very convenient web venue for people to post their suggestions and to cast their votes. That’s how our page with suggestions (ideas) and votes looks:
Then the stakeholders can sort and prioritize these suggestions on a board. Numbers that come with a thumbs up show many votes have been received for that idea:
Mathematical Models and Intuition
Then, another group of influences is coming from those folks who interact with leads and customers: from product specialists, and from our support team. These guys collect the metrics which then help us make a summary of the voices from people who find it more convenient to share their feedback in personal interactions.
It’s particularly hard to decide what to do next, if the voices coming from customer-facing people do not match the priorities that stakeholders have in mind. What should take the lead: a suggestion for a feature spoken out by a dozen large customers in their conversations with product specialists, a feature that has 100 votes in HelpDesk or UserVoice, or a feature that stakeholders want to implement based on their strategic product vision? There’s no finite answer to that question. One has to find a balance between all of these. But still, how, how to decide? We are now poking some mathematical models that would process all those voices. Still, as far as I can see, in some cases a model has to be put aside. Most likely, if strategically important features are at stake. A mathematical model would be better suited for smaller features and improvements. For some crucial features forming the innovative new feel and engine of the product, it would still make sense to follow the vision that stakeholders come up with based on many things they observe. This would be a a responsible intelligent choice of a human being. Models can’t feel and think, they only process numbers and their powers are quite limited. But models work great if stakeholders want to free up the time they would otherwise spend mulling over the tiny “what to do next” choices, and do some meaningful work instead. Come up with new visions and strategies, for instance.
Recently I’ve written a blog about the benefits of visual thinking. Assuming that many of you are now aware of the advantages that visuals bring to the table, I’d like to give a few tips on how to visualize work in agile project management. Visual reports would probably be the first thing that comes to mind in this context. That’s right, visualization is most commonly used in reporting. Everyone wants comprehensive reports, fast, and that’s what visuals deliver. All kinds of stats and metrics wrapped up in a nice graphical skin, just as in this process control chart:
A Process Control chart in Targetprocess
My main focus this time is not on the visual reports, though. There’s a baseline dimension for visual choices in agile project management, as we’re looking for the most convenient ways to see exactly what we want to see. We might need to view our projects from various perspectives, and we need flexibility with visualizing things. Boards, lists and timelines would cover most of such needs. Let’s now look which of those three would be best suited for which tasks.
You will want to visualize work on a board if you need to intersect 2+ properties of a card, or if you want cards grouped by any of 2+ properties. All that switchable visualization magic can only happen if your agile project management tool does the job as described in the Kanban as Multiban? blog . Unlike the classical Kanban board, this board is supposed to be a switchable 2D (or even 3D) grid of any properties of a card or a group of cards . This is a must-have prerequisite for that limitless freedom with visualizing projects on a board. I’m aware of only one tool that has this “switchability“. Let me give some examples.
You want to know who is doing what. Which person has which to do’s assigned to them. Hmm, this is not something that you would easily see on a static Kanban board. You can dial in a custom people-work grid, and here’s how it would look on the board (click to enlarge):
User Stories, Bugs and Tasks by person in Targetprocess 3. Who’s doing what?
Then, you want to know about impediments, and how are they blocking progress in your projects. Switch the grids, and see them with ruthless clarity:
Impediments by Projects and States in Targetprocess 3
Visualizing a project with any of the switchable boards makes sense for anything drag-n-drop. It’s more than moving cards between states. The switchability will allow to fit almost any change to a drag-n-drop action. That’s how one can arrange user stories on a board for estimating. The 1, 2, 3, etc. vertical lanes are points. A user story will be dropped to any of those lanes when estimated:
Estimating user stories with drag-n-drop in Targetprocess 3
You will want to visualize something as a timeline if you need an activity or a group of activities plotted on a timescale, with some explicitly marked milestones. This is called roadmapping. If time-sensitive activities are visualized on a board, with the intersected year quarters and epics as on the screen below, the feel of time would not “sink in” that well :
A workaround for roadmapping in Targetprocess 3
.. as with a roadmap shown on a timeline. The sense of time is more acute with this visualization:
Roadmapping with timelines in Targetprocess 3
Tracking work on a timeline helps get a clear picture in one look. A timeline would also work better than any other visualization if you need to see individual allocations across several projects:
Individual allocations on a timeline in Targetprocess 3
One absurd idea for using timelines, just to give you a strong anti-pattern, would be to visualize a tag as a timeline. Sounds weird. A tag is a tag, no one cares, when and why has a user story been tagged with a tag. Hmm.. However, there still can be a realistic case even for that, if one would want to see when this tag was first used, to which to-do’s was it applied, etc.
I’ve been using timeline visualizations from Targetprocess 3 in the examples above. Frankly, if you want to visualize with timelines, you’d hardly do without an electronic tool. Apart from the switchability, it takes quite some effort to draw timelines on a physical whiteboard. Guess how much time would it take to draw a timeline any time one wants to get a custom visualization?
A roadmap on a whiteboard
A sketch of lists in Targetprocess 3
A list also comes handy if you are hastily typing in the to-do’s, especially if on the go, catching ideas before they go. With no big screen for boards and timelines around, you might want to use lists on a mobile device:
A list view in Targetprocess 3 iOS app
As a summary, your visualization choices will depend on what you want to see, or what you want to do. Switchable boards and timelines can visualize anything. If you’re still skeptical about that, check this page with even more board visualizations.
Yesterday I had the privilege of watching Hillary Clinton speak at UB. Ms. Clinton spoke on various issues related to national and international affairs, and while this speech was delivered by a political figure, many points could well be projected into IT organizations, as long as it goes about the leadership part. I’ll share some of my musings here. Now, this is not a pump-up post about passion and being a leader in anything. I just want to highlight some practical advantages that having a distinguished leader brings to an IT organization.
If we look at the names of authority positions in IT, which one do you think would come across most often? Right, it’s a manager. Or a supervisor. Project manager, product manager (or owner) and many other managers. What could be wrong about this setup, with managers in the positions of authority? There’s one crucial distinction. A manager is someone who is in charge of tasks. Managers and supervisors are fine if their job is to supervise people who would drill rocks for “room+food+$12 per month” :
Obviously, things are very different in today’s world. IT professionals are far from being starved, so with their basic needs met they want to give a larger meaning to their lives. They would want to find a delight in seeing how their work helps other people. When one has so much income, a steady job and a family, but there’s no feeling of serving others it would come to a burnout with such accompanying thoughts: “What good is it that I work here? Is there something that I’d be proud of the day I’m gonna die?” If a manager would focus on the “get done” part, a leader would put his main focus on “get those individuals inspired” part. We tend to overlook the inspiration aspect in tech organizations thinking that it’s something that would just care of itself. No, no and no. It’s for a reason that a vision & mission statement comes first for any organization. Some might believe that there’s no need to inspire high-gear professionals, as they are supposed to run on their own fuel. It’s not that black-and-white. Some individuals do have a strong sense of meaning for what they do at work every day, but such people come across quite rarely. They are the leaders, actually. The indispensable ones because they feel the inner urge to take on the lead, and set the path for this organization, so the others would feel as they are a part of something larger than themselves.
It might seem presumptuous to make a parallel between working in an IT organization and being in public service. However, some renowned companies such as Steve Jobs’ Apple, Yahoo, Google, 37 Signals are great to work for exactly because of that. They instill a sense of honorable service in their employees, making them feel they are a part of a very special organization. IT industry is a service industry, in that it is supposed to bring value to people. Tech leaders work as beacons of that fundamental belief, and light the path for others.
As a seasoned IT professional what would you choose: working for an organization filled with managers, with no vision and mission, or for one of those mentioned above, given that your salary and benefits are more than fine? Companies with strong visions and strong leaders attract those best-of-breed professionals, with the expertise that they bring along, including the quality of technical solutions and designs, and the culture of caring about customers in every tiny detail. That’s the key difference between leadership-driven and manager-driven organizations.
There’s a lot of talk going on about visualization. Many posts in our blog are based on visuals, one way or another. Targetprocess, our agile project management tool, has quite a few visual reports. Visualization seems to have so many obvious benefits. However, someone might wonder: what the heck is all this visualization about? Sure, it is nice to look at visuals and cute pictures, but what real good they are?
I want to bring the point across, why visualizing is rather a need than a luxury. There’s only so much space in the blog, so I’ll resort to a little trick. Instead of writing it all out, I’ll recommend a great book:
Rest assured, and you have my word for it, no other book in the world provides such a clear and in-depth explanation of the benefits that one gets with thinking visually. Here’s the flagship quote from The Back of the Napkin that sums up this new way of problem-solving:
“Visual thinking means taking advantage of our innate ability to see — both with our eyes and with our mind’s eye — in order to discover ideas that are otherwise invisible, develop those ideas quickly and intuitively, and then share those ideas with other people in a way that they simply “get.”
First, this book does give an extended answer as to why it is worth to develop a taste for visual thinking. In a nutshell, it’s fast and efficient (read more in the book, or watch out for my future posts :) Frankly, in some cases visuals won’t help and I’ve touched upon that briefly in the blog Visualization: Understated or Overrated? However, for most problems that we encounter as problem-solvers in agile software development, or for the problems related to corporate strategies and objectives — nothing beats visuals.
Second, Dan Roam goes beyond listing the reasons why visual thinking is cool. He uses visuals as a proof, thus showing their excellent power in winning people over — that’s actually one of his points, too. Here’s just one elegant visual from this book, and it abounds with them:
A point to note about “The Back of the Napkin” is that it’s not about making reports. The very name suggests that it teaches to use visuals in formal or informal social encounters. When meeting at a cup of coffee all that one has to sketch an idea is just the back of the napkin. Dan takes a very step-by-step, clear and confident pace in getting his point to the readers. I must confess I’ve never seen anyone champion an idea with such clarity. In fact, the concept of visual thinking does deserve to be championed in this brilliant way. Addressing one other common concern, there’s no need to be an artist in order to think visually, you’ll see why as you read the book. With such a great intro to visual thinking, one will save their time learning to make sense of visuals in general and of visual reports in particular. Sounds great: save time, solve problems efficiently… and – dare I say that? – how about having some fun with those visuals?
Other book reviews in the Edge of Chaos blog:
A couple months ago I started a series of posts about communication (see Non-Violent Communication for Agile Teams). The concept of non-violent communication has been introduced and championed by Marshall Rosenberg in his notable book. As I received feedback from readers on that post, some reactions could be summarized as follows: “What are you talking about? Which violence? Do you think we behave outright violently when we communicate at work?” I pondered that, and came up with a bit re-framed concept. While Marshall Rosenberg has been dealing with people from various spheres of life, e.g. jail confines, family violence, and other cases of the outright aggressive behavior, we have quite a different situation as IT professionals. We can not be violent per se; this is office, work and yelling at someone, or using physical force (which would be perceived as the ultimate violence) is out of question, of course.
So, I’d like to give a bit different highlight to the subject of communication in agile teams, calling it “non-judgmental communication“. If we think about it, in its verbal form, in a well-behaved social environment, what would the utter form of this “violence” be? To me, this is accusation. For example, when a person in a team publicly blames another person for a failed release, saying: “It’s all your fault. You’ve missed this thing in the code. You overlooked this bug. You’re the one to blame for this late release”. It’s an utterly simplistic example, just for the sake of example. From what I see, the culture in most software development teams does not allow people to be that bluntly accusing. We are all human, and we know that people must have their reasons for the delays, or problems with code, etc.
The next gradation of violence in agile teams would be judgment. Someone might ask, why on Earth can judgement be a form of violence? Let’s look deeper into that. The most common example is calling a thing someone else has done “good” or “bad”. Especially when this judgement comes from someone in a position of a formal or informal authority. Like, your code is “good”, your design is “bad”, your article is “good”. Think about it, which value such an evaluative adjective would bring to what the team is trying to do? It’s only a judgement, and it suggests no way out. Doomed. However, what we are looking for when we work in a team? We look for the ways to improve. To keep our colleagues encouraged to perform at their top ability. To me, the “good-bad” judgment ultimately kills this spirit of friendly feedback and improvement. Okay, you say that this design is bad. But have you noted that this person is truly searching for a sweet spot? That this person genuinely cares? That he or she wants to come up with the workable solution? Why not reach out and help? Same with the written pieces and presentations. The best thing one can do is express their perception as a feedback. So, instead of saying “this presentation was the best”, we need to learn to say “this presentation was of most interest to me. I find it well prepared”. If we want a more fitting word instead of ”good” to express our attitude, I have this friendly word ready: interesting.
Now, someone might ask why it might sound so upsetting to the other people when someone else gets the “this one is the best” score. First of all, everyone invests their best effort in what they do. The judgment given to only one out of many might sound especially painful to those others, if they feel underappreciated for their input. They would then project their feeling of being underappreciated to this “good” praise that goes to another bird in the common flock. Someone might call this nonsense, but it’s as serious as it can get. It’s all in the culture. If the feeling of underappreciation is mixed with the judgmental “good” that goes to another peer, this is a flammable mixture. It’s a far graver cultural flaw than one might see on the surface.
This whole subject of judgments can acquire another perspective. Some of you might have heard of the Dunning-Krueger effect. In short, this is when the incompetent rate their skills high simply for their inability to recognize their mistakes, and the competent are too harsh on themselves. For agile teams, this might have a consequence that competent professionals who suffer from this bias, might get all unenthusiastic about their abilities at all, which in the end would mean losing out for the whole team, as they won’t be able to capitalize on the skills of the competent ones. On the other hand, we tend to be very condescending to those “incompetent”. If someone does an utterly improper thing, and then goes how great he is, we somehow rather laugh at this person, whereas a harsh judgement could be a proper response in this particular case. It’s a very fine line, and certain psychological skills are required to keep it. Remember the Emperor’s New Clothes tale? No one dared to say that the emperor just had no clothes on, until a young boy voiced the truth. Actually, there’s another human reason for this loose attitude. Subconsciously, we might feel that we are superior to the incompetent ones, that’s why we “let them live”, just to make fun out of them, keeping their heightened false beliefs of their abilities. In such cases, a shock treatment might be needed, and something like a judgement really needs to be expressed. Like, dude, can’t you see that what you say is absolutely clueless? This will be like a sobering shower for this incompetent person, and finally it would help them form a realistic understanding of their abilities, and improve, if not in the area where they’re clueless, then in something else.
The benefits of non-judgmental communication are enormous. Organizational culture does not emerge overnight. This is something that builds up with time. The first steps that one might want to take looking to introduce the non-judgmental culture, could be this: watch yourself, whether you use judgement when giving feedback about someone’s performance. Note if you’re inclined to “good” or “bad”, and consciously replace it with “interesting”, or “smart thinking behind this code”, or “I can see that you’ve put much effort in this design”. If you need this person to improve their work — this means, to make the design more compliant with the objectives, etc. — rather give them some advice. Creative people are usually very sensitive. They need to be treated like fragile antique vases. *almost no kidding*. To get the best of their abilities, one has to learn to communicate with such people. Acknowledge their input. These are all very subtle things. But devil is in the details, and software development is more about people than anything else, and I humbly hope that my posts contribute to this shared awareness.
… and vice versa. You might be familiar with the maxim that speed is a by-product of .. something. In software development. We would sell our souls to get hold of a magic recipe that would guarantee fast delivery times. The paradox is that the faster we want to get sh… done, the slower it seems to move. Why is it like that?
Let’s compare software development flow with a car on a highway, for the sake of easier understanding. What is needed for the trip to take as little time is possible? A good highway (as opposed to a sloppy mountain road), clear signs on the way, no traffic jams. You need to rely on the car, as it’s the primary tool that gets you going. That is, you need to take care of the technical maintenance in advance. In general, as a thoughtful driver you would want to bring the probability of unexpected emergencies to a minimum.
What would happen to a single-minded driver who only wants to get fast to the final point of his destination, but whose car has a leak in a tire, or a low battery, or no fuel, and there are no gas stations on the way? What if the road is steep and rugged? Such a driver would face huge delays. It could take him twice as more to get to the destination, and then he would rub the back of his head saying: “Hmm, I needed to get there fast, and I ended up being so awful late”.
The metaphor with driving by car gives a perfect explanation to the reasons for delays in releases. The very act of driving is the actual work, such as writing code or designing an interface. If a person who is doing the actual work is distracted by side factors, it takes more time and effort to continue driving. Re-work, poor balance of tasks and incoherent interactions slow us down. An organization which has the smoothest process, with all the slow-down factors kept to a minimum, gets to the destination faster. It doesn’t mean that the car will fly on auto-pilot as soon as an agile process is in place in your company. No. The process has to allow a wise fix-and-go, to maximize the time spent on actual driving in the right direction, with no detours. It does take some hard thinking and the ability to follow through if we want to bring the unexpected interactions to zero, making sure that most of the time is spent on the actual work.
What is slowing your organization down? Which bottlenecks recur? Can you identify them? How do they slow you down? Can you re-arrange the development process to dissipate the bottlenecks? As per my observations, 99% of unexpected emergency work and distractions boil down to continuously overlooked bottlenecks in communication and interactions. A wise strategy would be to dig down to the root causes, find the repetitive lapses and fix them. As simple as it sounds, this would shape-shift your organization from a fast-running careless hare to a wise tortoise that reaches the destination just in time.
This essay is inspired by a story I read the the other day. It’s about Everpix, the photo software company that started out very well but now finds itself going out of business with debts. It’s safe to say that agile tech companies can in some way relate to this story, as many of them do product or app development. While I don’t intend this essay to be a “look-at-them-and-don’t-do-like-them” sermon, some interesting nuances of the app start-ups success and failure can be highlighted based on the Everpix story. Whether you’re doing a product as a stakeholder, or whether you want to learn more about the trends that can impact your future as an IT professional — this read will hopefully give you some food for thought.
Technology and/or Methodology + Personal Need = New Software Product
Let’s start from the beginning. How does it happen that an individual gets an idea to come up with a product or an app? It quite often originates in this individual’s personal need to have an app that would help him or her do the things they need to do, or enjoy doing. Everpix started as a convenient solution for its founder to store and organize many photos. Another handy example is Facebook: it also grows from a personal need of its founder in a way. Not exactly personal though, it was rather a collective need of a campus community that he picked up. Targetprocess, our agile project management software, got its shape first as Michael Dubakov, then a project manager, needed a better tool to make his own work more convenient. One other common trend for such products is that they catch a good surf in the waves of some technological or methodological advancement. Everpix thrived on the mobile technology — people with smartphones can take many-many photos and pile them on the web. Facebook took advantage of technology as well: with Internet, everyone wanted to keep in touch online, and the movement with social networks started about 8-10 years ago. Targetprocess benefited from a non-technological booster: the methodology of agile software development. The tool came right in time as the agile movement was unfolding.
One might say that many people get an idea to develop an app or a product not out of their personal need, but as they analyze the market and decide that this app is bound to succeed. While it might sound true, there’s a point to note. Imagine you are a software geek, and suddenly you decide that you want to create an app for expectant mothers to track their nutrition patterns (an extreme example, but you get the idea). Well, if you are technically not supposed to ever be pregnant, you would hardly know which things matter to expectant mothers, what nutrition should they take, how do they want this app to look, and how would it be convenient for them to use it. In this particular case, one would be better off if their own wife is expecting a baby.
But this would be an indirect report, not your own intrinsic need, so if your wife is not available to provide guidance in the app development, you might have some crucial things done wrong. I leave it up to your imagination as to what might go wrong in this case :) It’s always more authentic to create a helpful tool or an app based on one’s own needs and experience. Then there comes a question for product stakeholders: who will need my app or my product? Naturally, people with the similar needs. People who need to store and organize their photos. People who feel the need to be in social networks. Or, as with Targetprocess, people who want a convenient tool for agile project management. What is the decisive success factor for such product companies then? To have more and more people who feel the same need. As long as there’s no other way for photo management, they will pay for the service. We’ve all witnessed the media hype about social networks as more and more people get to use them. But here’s the catch: while in general there’s one need, people have their personal varieties of this need. On the other hand, technology is changing all the time. Methodologies are evolving and changing as well.
Drive or Hitchhike?
It seems there are two ways to continue thriving and staying on top of what’s happening: to drive or to hitchhike. The hitchhiker’s way of development is related to following the lead of new technologies and new methodologies, and catching their wave once you’re already done with the initial stage of starting out a product. The driver’s way of development seems most natural to people who nourish their products. In a way, they do it not only for their clients, but for themselves. That’s something I’ve touched upon in the essay Why People Don’t Understand How to Use Your Software. If one finds a great personal delight in slick graphic designs and spends lots of time perfecting them, this doesn’t mean that the clients would appreciate it. They might not be infatuated with that part. What if they are task-oriented managers who want a just-enough convenient tool or a convenient app and find their personal delight not in admiring web designs, but in fishing or hiking? It might seem bizarre but there are many-many web-sites and applications that stay alive for many years with their bulky user interfaces. They do their job and function well, and the clients are comfortable with them as long as they fulfill their primary need. Then, as a product stakeholder, you need to make choices. But, well, the point is that you do love nice web designs. What can you do to satisfy your own personal need for delivering a product that stands to your internal expectations without making an overkill, if your clients do not seem to care much about it? That’s where we come to the part that’s called nurturing the like-minded.
Imagine, if everyone in the world were a geek who wouldn’t buy into just function, but wanted it to go along with a nice form? That would mean that your potential market reach would be the whole world!
This idea is not new. Over the recent years, software products have been dancing along with technology. Technology is the primary law-maker. Smartphones and mobile devices are the most obvious example. But what if technology becomes all used-up at some point? What if too much start-ups and products oversaturate the market, and there’s hardly any lucrative niche left where one can fit with their product? Here it comes to some different things. If you truly intend to come up with a groundbreaking product, you need to be the firestarter, and make the users your like-minded people. Of course, not many young start-ups possess this power. They continue to feed on the technological breadcrumbs. What then happens if technology gives no new major spurts? There’s an option to strike open narrower and narrower niches by communicating your point-of-view to more and more people. Turn them into your faith, sort of. The prerequisite is to start with the narrow niche, but then once you’re settled in there, excavate it and make it wide. This involves going beyond technology. You need to pass on your worldview and needs as far as possible. Create the innovative culture or a new methodology and start the movement that would engage people. At one point or another, if product stakeholders are not that absorbed in the product, as the Everpix guys were, they will become aware of this need. This is, in a nutshell, the ability to innovate and to exercise thought leadership. It’s obvious that any software product company is changing and evolving with time, and rest assured there’s no way one would go with the same product for 5, or even for 3 years. When technology remains at a standstill, it takes even more to be innovative and to nurture the needs in people that are similar to your own needs. It’s far easier with shoes or with furniture. One can go on for years producing them, just let it be of good quality. Software development is so tricky and demanding that it requires the ability for on-going innovation to succeed and to stay aboard.
Once I voiced this concern about software guys playing with their toys to a friend. He went all indignant and retaliated: “Do you think we are that selfish? So, we only do things for ourselves, that’s what you think?” Of course, it’s not about selfishness. It’s about passing on your lifestyle and your culture to more people. If, from inside, you feel that there IS a delight in what you do, you will wholeheartedly proceed to sharing this passion with other people making them your followers (or friends). You need to make it easy for people to follow you, as in this acclaimed video shared by Derek Sivers:
But be aware that there’s a limit to how many people one can turn into their faith. Company growth in sales and in profits will be determined only by that, at the end of the day. Are you doing everything to spread the ethos of your app or product to the world? Are you able to be not only a product or an app dev company, but a mini-media company in a way, pioneering your knowledge? If not, what are the techniques that one can use to make this need appealing to people? Which stories should be shared, how it can be done in a nice and engaging way? This is a very fluid conjunction of marketing, public relations and organizational culture projected on sensitivity to people’s needs — and in the context of software development. If you are able to use all of those to your best advantage, and be agile in the sense of continuous problem-solving, then you will live a happy long life with your software products.
There are quite many posts on visualization in our Edge of Chaos blog. While we haven’t emphasized the difference between visualizing data and visualizing information, mostly, there is still one between those two. Without delving into any greater depths of theory, one can assume that data visualization is more closely related to quantitative data. This means that figures rendered into a visually clear form make sense faster as compared to when one looks at figures only. Today I’d like to give a few examples of using visuals (namely, mind maps) as an aide in the cognitive processes of research and problem-solving; I will also share some thoughts on when mind maps work at their best to amplify cognition.
Mind maps are often used to put together concepts related to a certain problem. These visuals help to get to the core of a problem or a phenomenon that we explore. When we link concepts in a network, things seem to make more sense to us, and the process of binding those nodes somehow helps to bind pieces together in our heads. The following mind map represents a case of digging to root causes of a problem (problem-solving):
Another case of using a mind map visual is to make a summary of some information that one has already digested. A mind map conceptualizes this knowledge putting it into various perspectives. As learners and researchers, we often feel the need to re-arrange some previously acquired ideas based on our own thinking, to shuffle and to categorize them in some new ways. This mind map was used to write the Patterns for Information Visualization article:
The next example looks as a mind map on the surface, but in essence it’s not exactly that. Technically it is a mind map, as it consists of some nodes linked together. Such a visual, however, would seem more appropriate if drawn at a group meeting with people discussing the dynamics of their team work. We can say that this visual facilitates a group discussion:
Here’s another example of a mind map that could have been used as a graphic facilitation when discussing Scrum process:
It depends a lot on the personal preferences and the context whether a mind map would help to amplify cognition. For example, the team reflection and the Scrum process visuals might work better at a group discussion or in a conversation. It’s cool when a person that runs a meeting draws such images in the process of speaking, as the others look at the funny images, share a laugh and put their cognitive abilities to a better use through this distraction. As a solo researcher, one might draw such images automatically, focusing on the problem and thinking deeper.
Summing up, mind maps work well for an advanced solo research and problem-solving as people make graphic sketches in the process of thinking. They also work well for group meetings to facilitate discussions related to some common context, in a shared space. However, mind maps do NOT work well when someone totally new to a subject area hopes to learn all and everything from a mind map sketched by someone else. Depending on how new the student is to this subject, the mind map might make no sense to them at all, or it will just give them a general idea, at best.
It’s excruciatingly boring to write specifications. It seems like it’s the most boring thing in the world that a product owner has to do. This could be the reason why most specifications are horrible and come across as the root cause of delays, reworks, and bugs.
This problem can be partly alleviated if a product owner is always available to talk to, but even that is not a cure-it-all remedy.
The agile movement has its peculiar point of view on specifications. The most extreme part of agilists express their feelings quite clearly:
F%$k the specifications!
Last week, in the When One Product Owner Is Not Enough post, I shared some thoughts on when a team might consider replacing one product owner with several feature owners. This time I’d like to tell more about feature teams, and their guiding principles/values, should some of you decide to try this setup in your organizations.
The very first thing to do would be to pick up the feature owners. These people would ideally spend several years working in the organization, where they would track the evolution of the product, having the general awareness of the priorities and business objectives. Of course, the priorities and objectives can be shared and discussed in a conversation with a relatively new person, but someone with the intrinsic knowledge would fit much better. Someone who’s been in the product context for quite a while, as a dev, or as a QA, or as a UX designer, would be able to balance the strategic priorities projected on their feature. A feature owner would eventually become an informal leader, based on the “first among equals” principle (or primus inter pares, as in Latin), where this person doesn’t have the formal “order-forbid” rights, but is viewed by the other peers as a competent authority, as someone who champions the team. The feature owner would also paste this feel of awareness on the rest of the team, thus fostering engagement.
The coat of arms
Next, the #1 goal of a feature team is to release their feature as fast and as best as they can… and then re-iterate based on the feedback from customers, of course. Anyone in the team has to be aware of that, and keep that in mind. They have to learn to think in the context of the whole feature, not only their one user story, or task. In other words, go beyond their primary knowledge domain. The notorious UX-dev clashes, when developers say something like “it’s very hard to do this UX in terms of development”, have no right for living. Yes, sometimes code-related things make it hard to implement a nicer UX solution. But this is not to be left hanging in the air. Developers and designers in a feature team are supposed to sit down and discuss best viable alternatives, considering all the challenges, pros and cons from both the sides. The faster things are discussed, the higher the chance that a good approach is found faster, and this would bring the team closer to their ultimate #1 goal. That’s what integrity as a feature team value is about.
In a feature team, there’s no subordinate relationship. A feature owner is not supposed to assign work as such. Neither it is supposed to work as “I have no tasks left, tell me what to do?” A feature team is even more about a collective ownership of a feature, so if a team sees some challenges, they need to talk, discuss and decide by themselves. There’s no micro-management either. If there’s a bottleneck at the UX stage, or at the development stage, or at the QA stage — it’s up to the team to come to a solution. That’s what autonomy as a feature team value is about.
A few more words about engagement. This is something that really has to be in place for feature teams to exist. It can only be rooted in the culture of an organization. The genuine interest, and broad outlook, looking beyond “this is my task, and that’s all I know”. Such awareness of shared goals and priorities in product development is a must, and it’s a job of the strategic management to keep people on the same page with the objectives, updates and changes (share feedback from customers, communicate changes in the priorities, making sure that people in the team make sense out of them).
Finally, the “first among equals” principle might be better known to some of you as “organizational flatness“. In brief, this means no formal authority. The most recent example of effective organizational flatness that comes to my mind is Valve, the video games company. They have some interesting insights in their handbook for new employees (it’s a .pdf file). But one has to be aware that absolute flatness as a goal is futile. It can be reached to some extent, but it really depends on the culture of genuine engagement. And, let me re-iterate, that “flatness” as such rather means the “first among equals” setup. There’s no way for a group to go without a leader, be it a formal or an informal one. I hope to write more on organizational flatness in one of my future posts.
I’ve been contemplating recently about agile movement as something that has risen from software developers who felt that the challenges of their work are not addressed by the waterfall approaches of the industrial production, and shared my thoughts in the Back to the Future of Agile Development essay. Then, as another layer of this thinking paradigm, I saw that Kanban as a method in agile software development stems from the human need to get rid of deadlines (check out the article Kanban as Multiban?) Now, there’s another concept in project management that falls into the same pattern. I’m talking of what is known as “project portfolio management” in the enterprise lingo, and what we call “multi-project prioritization” for smaller agile companies. So, this time I want to look deeper into prioritization, and give one more example of how a promising new trend stems nowhere else as from human nature.
On to project portfolio management. Just as waterfall was copy-pasted from industrial production, and turned into the Rational Unified Process for the sake of software development, in the same fashion, project portfolio management has its roots in the financial investment industry. As always, there’s a human need behind it. Someone must have been tired of looking for the ways to manage risks in software development projects, and resorted to what seemed the closest available counterpart — financial investment. But if we look deeper, would there be any difference between financial investment and following through many projects to completion in an organization? For sure, yes. First of all, projects are not shares or stocks, and in investment management one is looking to lower the risks, and compile the investment portfolio in such a way, so as to mitigate them, and optimize the financial gain. Only that and nothing else. It’s not that this person is concerned with being strategically involved with a public company whose stocks or shares they’re buying.
It’s far more complicated when we deal with projects, and especially with software development projects. One key difference is that the projects are meant to be followed through to completion. Of course, a lot depends on the organization. I figure that IT and software development projects could be shuffled as investment stocks — the closest match — in budgeted research fields, like in the military or in the government projects. Most IT companies, though, have nothing to do with picking up or giving up on projects. While in the finance industry the only value indicator is financial gain, there are many more value indicators in software development. Usually, the question is not if the project should be picked up or given up. The questions are:
1. Are we fitting in the budget? Do we need to secure a leeway to complete our projects?
2. Are we lax in terms of time? Do we need to sacrifice some parts of the project, and skip them, in order to ship some workable software in time?
3. How about people? Are they all balanced well in the projects? Have we made sure that the team’s collective energy is sent in the right direction?
4. This one is the closest to where we might come at portfolio management. Let’s say you work in a large organization and you have many projects, as an IT director, to supervise and to report on their health to someone standing higher. Or, in a smaller product dev company, one might have this multitude not with the projects per se, but with what we call “product features”. Ironically, for a smaller organization, this would seem the closest approximation to portfolio management. We have to prioritize and decide, whether we skip this feature, or follow through.
On all of those 4 levels, it’s about prioritization. That’s what it’s all about. Prioritization is the toughest job of all in the world, be it in personal life, or at work. Sacrificing is the most daunting challenge, and it imposes a huge load on a person or a group of people who are supposed to decide and prioritize. By now, the buzz in the industry says that the concept of “project portfolio management” has something missing in it. The tools for multi-project prioritization are not universal, and they don’t do the magic instead of this tired human being. Either the tools have to be customized (at big costs), or they miss some instrument that is crucial for this particular organization. In a nutshell, the project portfolio management concept has outlived itself for effective prioritization, just as RUP had outlived itself previously, and was replaced by agile as a methodology in software development. But still, as a product owner, or a project manager you need to have a birds-eye view on all the risks. Still, you want to get this burden off of your shoulders, and finally get a tool do the bulk of the prioritization for you, as this is the hardest job in the world. What happens usually when some methodology is not working out as expected for those human beings? Right. They’re on the lookout for new, better — and what’s most important — easier ways to prioritize.
Voila: enter Big Data. There’s much talk going on about it now. This is the next big thing coming, as it is supposed to make a productivity breakthrough in prioritization and decision-making. If we draw a parallel with the previous occurrences of groundbreaking phenomena (like, the way agile appeared in software development, or how people resorted to Kanban within the agile paradigm, or how they looked to use investment portfolio methods for project management), this prioritization seems to be the hardest job that IT professionals want to make easier for themselves, intrinsically.
Big Data is a trend that can be briefly described as follows: all the huge data about past performance and work is stored, and can be retrieved then to see how past trends can recur in the current trends, thus helping decide and prioritize. Considering the meta-law of things developing in cycles, this might work, to some extent. There is a certain probability that past trends would help one prioritize efficiently in the present. There’s some financial software developed that calculates those trends. But, from what I’ve been able to see, the big fish and the big gain in stocks usually come at random. This all boils down to the intuitive feeling. Something outside data and calculations. This is not to diminish the importance of data analysis. Any data is a huge asset. Even more this is an asset as we live in the age of information, and we need to learn to get the best of those assets. But, just as the term “project portfolio” has the trace of hope instilled in copying this practice from financial investment to software development, in that it would set us free from prioritization problems, there’s something to watch out with the Big Data trend. Yes, we always strive to put burdens off of our shoulders, as Homo Sapiens, and that’s why we started with sticks as tools, then shovels, and on. Same with the heavy duty prioritization and Big Data. To a certain extent, we can be sure that it would help us move forward, and give more sophisticated tooling for effective prioritization. But ultimately, there’s something even beyond Big Data. Some other infotech miracle. All in all, not that we should lose hope in freeing ourselves from prioritization work altogether, but I don’t think that even Big Data would become the silver bullet for the IT professionals in prioritizing their project choices. We will have to carry personal responsibility all the same. But this would definitely be a step ahead in the evolution of methods and tools for effective prioritization across many projects and initiatives.
If you’ve followed our Edge of Chaos blog for quite a while, you might recall the Product Owner Retires post. Briefly, it describes the implications of a product development team switching from single product ownership to multiple product owners. For sure, not only our team has been facing such challenges, so these insights can be used as lessons learned, out-of-the-box.
Today I want to share some more details on when it is potentially not enough to have one product owner. You might want to watch for those signs in your teams, and then act as needed. A point to note: with several product owners, not only the quality of product ownership as such is improved. This works as a field training for people, the aspiring product owners, who then mature and become more competent, thus enhancing the shared team expertise, which surely is an asset if one is looking to develop more products, or product features in the future.
So, where should we look for the signs that one product owner is not enough? You guessed it right. It’s about communication. Here’s how it had looked in our team before we decided to switch to multiple product owners:
While we have 2+ feature teams, there’s no need to show more, as the communication patterns are about the same for each of them. On the upper part of the image one can see that customers are in contact with the sales, support and product specialists, and the product owner (some). Dotted and solid links represent weak and intensive streams respectively.
Obviously, the interactions break down into 2 networks. In the upper network, customers, sales, support people and product specialists mingle. In the lower network, feature teams swirl with activity. Those two networks are connected just loosely. For example, the support might need help from developers. Product specialists pass feedback from customers to the product owner. There you go: a single product owner is the bottleneck. This person appears to be a busy hub where all the interactions overlap. Besides, if a product owner has some other responsibilities, not exactly related to product ownership (if he happens to be a CEO as well, for example), then the plot thickens even more.
Here’s how the solution to the overloaded hub would look. A dedicated product owner for each feature team:
This second sketch still reveals the communication gap between marketing and production. This gap is currently covered, to some extent. We’ve introduced decision-making boards, and we share knowledge in internal blogs (the UX blog, the product specialist blog and the support blog) and in group Skype chats. I hope to write more on that some other time.
There’s quite some talk going on about the nature of creative work. No doubt, people who work in software development are creative professionals. They engineer solutions, find technical and organizational bottlenecks, design comfortable user experiences and help customers handle their challenges. Some say creative work is all about being passionate, some say that it’s essentially a routine, and all you need to do is stick to a schedule, do your job well, and the success will come. I see a point of merger in those two approaches to any creative work, and here’s where it’s at.
The “passion” point of view has been shared by Ken Robinson in his book “The Element“, and “the routine” one has been excellently covered by by Todd Henry. Ken Robinson’s focus is rather on calling people to discover their passions. We all find ourselves at various stages of development in our creative life, and if someone is still looking for this “point of passion” (that’s where Ken’s book comes handy), then someone else might be aware that “passion” is not everything. It’s the same as with personal relationships. In the beginning people are very passionate as they create new families, but then they find out that their life has become a routine. A chain of repetitive events, such as family gatherings, looking after the kids, or taking care about the place where they live, etc. If people find themselves in an established family relationship with this “passion” mindset, they are not going to last long. This is the same as a crave to get high, in a way, and constantly whip up your adrenaline by passion and nothing else. That’s why families based solely on passion do not pass this test, and break up, as people go find some other sources to “get high”.
On the other hand, there are people who understand that it’s their passion, but now it just went to the next stage, and turned into an established routine. At this point, passion wouldn’t be the driving force, and that’s where I want to draw a parallel. If relationships are based just on passion, people behave like amateurs. There’s nothing complicated in caring about a person if passion is there. Same way, there’s nothing complicated in exploring a new pursuit you’re passionate about. What’s complicated though, is going over the exciting ridge of passion to a flat lavish valley of a creative routine. That’s were “professionalism” comes in. Could be it’s not a very appropriate word, but only a good family “pro” can be content living their life and enjoying simple pleasures. When it goes about work, only a pro can do their job routinely, excel at it, and not make too big a deal out of it.
At music concerts, one might have noticed that professional musicians look far from being outwardly “passionate”. It’s so surprising, how matter-of-factly they proceed from one great piece of music to another, take a sip of water and then just go on. And the audience is all rave.
My point is: one can only last so much if fueled only by passion. Passionate outbursts and try-outs are OK if you’re venturing for a surf glide, or for a skydive. With any sustainable activity, that requires consistent practice, it’s not about passion. It’s about the routine production of a good quality pro work, in whichever field that you are in. Of course, it can be intermixed. People can change their passions, but where one becomes a professional in anything, it’s their ability to do things just by schedule, and do them well, no matter if one feels passionate or not motivated on any given day. By the way, Malcolm Gladwell is not getting this exactly right with his 10,000 hours rule, in my opinion, but that would make a subject for another discourse.
I think that the bottomline for each creative professional — as I believe many people in software development are creatives — is to find out when they are ready to move from the “finding their passion” stage to the “creative routine” stage.
This process is cyclical. Someone can be a great pro, and work efficiently in the “creative routine pro” mode, but then there’s an urge for another passion, at which a person might choose to keep this passion just as a hobby, or pick it up seriously and become a professional in it, as in photography, for instance. But the one who arrives at the point of a steady creative routine earlier in their lives, is much better off. Such a person simply has more time to become good at doing what she does. That’s the reason we all like dining in family-owned restaurants, or having our stuff fixed by a grey-haired jeweler, whose family has been in this business for 3 generations. Same for software professionals. Young passionate creatives at one point or another either turn into grey-haired experienced professionals, or jump to their next passion. This passion-routine cycle might be repeated. But it’s hobbyists who are driven only by passion. Professionals do their job well in an established routine, and feel calmly good about it.
We’ve been working for several years with Kanban process, and there’s quite a bit of experience about it that we’ve shared (see the posts tagged with “kanban”). I’ve contemplated things around Kanban recently, and here’s another interesting perspective. It might help make more sense of the Kanban method as a method for managing knowledge work, and software development work, in particular.
If we look into the 6 core Kanban practices, as identified by David J. Anderson in his fundamental book “Kanban — Successful Evolutionary Change for your Technology Business“, the first practice is “visualize“. While the other 5 practices (Limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively) are very important, the visualization practice is the key to all of them. Taking a flashback into how Kanban evolved historically, first it was a system “to control the logistical chain from a production point of view“. Seems like Kanban as a method for software development differs from Kanban as a scheduling system for the material production in the following 2 things (mainly): non-linearity of the production process, and diversity of concepts and workflows.
I can imagine what the first sparkle that inspired software development folks about Kanban was. Some of us have this special relationship with the concept of “deadlines”, and probably Kanban — on a purely human, maybe even subconscious, level — has been seen as an opportunity to break away from deadlines and estimates. Well, might be that Kanban came later than Scrum due to the fact that people got tired of the time-boxed iterations. And there it goes, a trendy new method for software development, that says: no time-boxing! Do your work at your own pace, and don’t worry about deadlines!
That’s the most obvious advantage that laid on the surface, and that’s why software folks were so glad to switch to Kanban, intrinsically. The Kanban movement started back in ’09-10, and the 5 Wrong Reasons to Apply Kanban and 5 Right Reasons to Apply Kanban posts in our blog are the evergreens that can provide some practical advice even now (especially as they resonate with the current NoEstimates movement).
Now, if the flow and no estimates aspect is a woo in Kanban as copy-pasted from the material logistics model, we’re having a bumpy issue with the visualization core practice. The easiest way to go would be to copy-paste the visual production flow from logistics, as a stock of parts in the warehouse (the backlog) reduces, and then sequentially goes through the In Progress and Done states:
Looks as easy as a pie, right? But, remember, software development is a knowledge work. While some part of it, such as work items (user stories, tasks and bugs) can indeed go through this simplistic flow sequentially, there’s a bunch of non-material related concepts and dependencies that those work items carry along with them. They are the non-linear “sticky fish” that might hinder the movements of this big whale called “software production’. Visualizing this knowledge work is not something confined solely to workflow and limiting WIP. Working with Kanban as a method implies visualizing various concepts about processes. Kanban is ultimately a “signboard”. One straightforward Kanban board often lacks all those multiple perspectives that we need to monitor processes and to make them explicit. Obviously, a part of this limitation can well be addressed by swimlanes, when Kanban is not a board with just columns, but a grid of switchable columns+swimlanes. It’s quite hard to get such a level of visualization on a physical board, too cumbersome to maintain. Fixed swimlanes on an electronic board (or, even switchable swimlanes but with some limitations) would not be enough. Kanban in the context of knowledge work requires unlimited columns+swimlanes combinations, with a plethora of custom 2D data grids. And we need to switch them fast, in a few clicks. Well, we can use tags to add another optional dimension for work items, but sometimes tags are not enough.
What we need from our Kanban boards for software development projects would look like this:
Any data from the project could be extracted from the database and visualized in an instant. The teams-work items grid above is just one example. This sketch implies fast swapping of the vertical and horizontal lanes and visualizing the same data in a different way, with even more sophisticated filtering for the lanes available, if required. For example, you’ve created a 2D grid that shows user stories grouped by features. You only need to see the stories from the “open” features, to unclog the grid (features are represented by the horizontal lanes):
Here’s the list of possible properties (“the sticky fish”) that can go along with a user story:
- Iteration: if you see the upcoming iterations, you can move the stories to the grid cells, and create an iteration plan.
- Release: same as above, for a release.
- State: this would be a classical Kanban board.
- Priority: user stories can be prioritized similarly to how the states are changed.
- Effort: same as above, but for effort.
- Feature: that would be a story map backlog.
- Person: a work-by-person grid.
- Project: user stories broken down by projects.
- Team: user stories broken down by teams.
- Tags: even more flexibility.
- Custom fields: same as above.
That’s the diversity of 2D visualizations that we could have with just one swimlane. But it’s not only about swimlanes. Both the horizontal and vertical lanes could be tuned in the same fashion, unveiling thousands of custom 2D views.
So, what we would have here is not just one Kanban. It’s a “Multiban” — many boards on one screen, where boards are switchable 2D data grids, and the data itself remains intact. Another example of such a data view is this:
Imagine this freedom. With such unlimited ability to visualize anything, the Kanban method would make much more sense. Any concepts, any perspective that you need could be visualized. If we have the first visualization core practice for Kanban handled that well, we would be able to take advantage of the 5 other Kanban core practices, mentioned above, and utilize Kanban as a process to manage software production (the knowledge work) more fully. That’s what we are coming up with in the next version of our project management tool, and in this post I tried to provide some “behind the scenes” reasons for that.
If I were to pick the one-in-a-lifetime book on how to create presentations, with no option to get hold of any other book on the subject ever, I would not hesitate. This book would be slide:ology: The Art and Science of Creating Great Presentations by Nancy Duarte. In our work life, as software development people, we do need to sell ideas, at one point or another. It’s not the prerogative of sales and marketing people only. Have you ever struggled with bringing a point across to the rest of the team? Have you ever thought: “How could they miss this clue, why?” If you ever asked yourself such questions, then this book is for you.
It delivers tons of smart right-to-the-point tips on how to intermix visuals, text and concepts. There’s a major warning, though: slide:ology is mostly about presenting ideas. If you’re looking for the ways to visualize data nicely, I’d refer you to some other books (see Data Visualization 101: A Basic Guidance). Nancy’s book goes far beyond “visualizing all that moves”. She provides smart ideas backed by years of experience and the sound knowledge of cognitive science, design and typography. Data visualization is just one component of a good presentation, and slide:ology does not provide that much detail about it as Tufte’s books do. If you’re looking for the ways to visualize some corporate data, then this book alone probably would not work.
Without going into too much detail, I will cite just one meta-idea from the slide:ology book: reduce the cognitive burden. Make it easy for the audience to focus on your main point in a limited time frame, and steer them in your tunnel vision, for that matter. Presentations are not about giving wide options and taking final decisions, but about raising the awareness. I remember the ending keynote presentation on UX delivered by Jared Spool at the Agile 2009 conference in Chicago. It did have a significant impact on our CEO, and we’ve started some strong internal movement toward interlacing a better user experience with our product. It didn’t happen overnight. But this one presentation sparkled the awareness. It took some time for us to digest it, and come up with a better UX. In the same fashion, if some issues in your team lack mutual understanding, there’s no better persuasion tool than a smart internal presentation. By smart presentation I mean:
a great idea wrapped in carefully chosen words and carefully chosen visuals
.. and there’s no better companion in this job than the slide:ology book by Nancy Duarte. There are a few other great books about presenting ideas. Probably, I’ll write about them later. But this one is a sure win. And I’m not promoting slide:ology for the sake of promotion, it’s based on personal experience. Once, I’ve listened to an internal presentation, and it appealed to me a lot. Then I asked the person who delivered this presentation: “How did you do it?” Then she told me about the book, and that’s how I ended up reading it, and sharing my opinion with all of you.