In a recently published article, A Product Owner’s Syllabus, I shared how we educate product owners in our company. A product owner’s job requires competence in a number of domains, as it turned out. There’s one more consideration that I want to highlight. It’s rather related to the environment where this product owner works, not to personal skills or knowledge. Sometimes, though, it’s quite hard to draw the distinction between personal skills and how those skills are influenced by the environment.
3 Levels of Product Ownership
Product owners can act on the following levels:
Mix of innovative and market-driven
Why is it important to single out these levels prior to doing drills in narrow disciplines included to the PO syllabus? This helps the trainees realize the high-octave “why” of this work. They say that philosophy is the mother of all sciences. In the same fashion, knowing the very reasons of why a product exists at all is the necessary first step. This knowledge and reasons are very product-specific. That’s why I’m skeptical about all kinds of “certified” courses, because attending a course and taking part in abstract drills (such as the ones brilliantly mocked at in here) will not turn anyone into a mature product owner overnight. To me, the best credentials for a product owner would be the history of the product that this person owned or managed, at least for some time, and the thinking that stood behind their decisions. There’s no better learning than by doing.
Just as in my recent post, where I anchored our evolving as a company with the way we do visual process management, I will look back at the history of our product yet again. We’re cool big guys, because we can look back as far as 10 (!) years ago. Targetprocess 1.0 was launched in 2004. Targetprocess 2.0 was released in 2006. Targetprocess 3 came on the scene around 2012-2013. The 1.0 version was the minimal viable and marketable software for agile project management. Targetprocess 1 had 7 releases, from 1.0 to 1.7. Targetprocess 2 had 24 sub-releases, from 2.0 to 2.24. With Targetprocess 3, we released the version 3.0.11 last week, and the next release will be 3.1.
The Market-Driven Suite and Innovation
Looking at the releases from 1.0 — 1.7, and 2.0 — 2.24 (click the hyperlinked words above), one can draw some interesting conclusions. Targetprocess progressed with the agile movement and with what the market wanted( I wish we had a decision sequence timeline to track this better). The 1.0 version appeared as a result of market-based thinking, because agile was a rising new trend back then, and our product owner and founder (who has the project management background) wanted to do a decent software for agile project management. Then, with time, the 2.0 version was released. This was a re-written software with completely new UI. The product owner sensed that the product needs a robust core and an improved UI, before any new features could be added. That was a strategic market-based decision. Then after about 8 years of following the market, the product owner hits the level of innovation with Targetprocess3. It is indeed an innovative project management software as it brings along a new paradigm in visual project management. I do not intend to go too deep into praises, I just want to show with this story that it takes 8-10 years for a product owner to become mature and operate on the level of innovation. Some product owners never get to this level. They implement the features that make their product more appealing to users, to outperform the competitors, or both. There’s nothing good or bad about it, just the way it is. It’s quite rare nowadays that a completely new product comes as “innovative”. Start-ups are mostly busy discovering smaller niches in the established market and filling them in.
A Basic Drill for Newbie Product Owners
Well, a product owner may or may not reach the innovation level. Let’s get down back to earth. I have this list of questions ready for trainee product owners to help them exercise their minds in product-based thinking as they consider implementing new features:
How often will people use this new feature?
How many people will use it?
Will this feature address any particular pain of users?
How it will help users save their time, if at all?
Will it make any difference, or will users be just as fine without this feature in the product?
Will this feature make the product easier-to-use or more complex?
Will it help bring new business, or is it meant for established users, mainly?
Formulating such questions can be a good exercise at an internal company training. The road to success starts with one first step, and this simple drill might be a nice first move in a career of a product owner, who might become an Innovator some day.
What Comes Next In Your Product?
3D Backlog Management
Product Development: Drive or Hitchhike?
A Product Owner’s Syllabus
I’ve poked around the subject of visual process management in my previous articles, accentuating the complexity and non-linearity of software production process, and how a traditional Kanban board fails to visualize the diversity of organizational contexts and workflows. With that in mind, I’ve introduced a concept for a universal visual process management system that is capable to embrace this diversity and linearity on one screen, with flexible zoom-ins and switches, and called it Multiban.
The Limitations of Kanban Board
Many software development teams suffer the limitations of Kanban board, at one point of their evolution or another. When a company grows, the scope of work grows as well, the structure of the company and of the teams, that it is comprised of, are changing, and what if one Kanban board is not capable to accommodate those changes? What if a large company is working on a suite of products, and a 1 team-only Kanban board cannot show the bottlenecks that are out-of-the scope for this team, but still influence its work? Or, what if the 1 team-only WIP’s are not relevant, because a suite of products is a sum of components, where each team’s work is a component of the whole product, and WIP’s and value streams have to be balanced on a wider scale, beyond the scope of one team-one project board?
We had to find answers to such questions. In 2012, Michael Dubakov published the Our Development Process: 50 Months of Evolution article. The changes that have occurred over 2012-14 are not covered there, but it still shows how our needs in visual process management were addressed in parallel with the changes in our company setup. Keep in mind that we are a very special company. We develop Targetprocess, agile project management software, since 2004, and we have an advantage because we are free to choose how to shape our product to make it respond to the changing needs and structure of our organization better. Over the last 5 years, we’ve been consistently working to make our tool more visual and more powerful. I will single out the major landmarks.
2009: Switch from Scrum to Kanban
In 2009, we switched from Scrum to Kanban. By 2009, we’d been doing iterations for 3 years, and iteration development worked great when Targetprocess was a young product that needed to gain the critical mass and stay alive. Then, we realized — and that coincided in time with the uprise of Kanban — that we’d be better off reaching our goals as an organization if we practice development with Kanban. If you’re interested, here’s an in-depth story of the reasons and the production context that we had back in 2009. With our hands-on attitude, we didn’t linger with it, and implemented Kanban support in our project management tool. That’s how our Kanban board looked back in 2009 (one team-one project):
We implemented this Kanban board to cater both to our own needs, and to the needs of our customers.
2010-11: Kanban is not enough. How about TeamsBoard?
While the major reason for our move to Kanban in 2009 was the change in the product development dynamics (the product matured, and we needed to switch to the “add features” mode), the major change in 2010-11 was the switch from one team to many teams, as we realized that this setup works better for the “add features” mode. The count of feature teams is not fixed, it changes depending on which features we’re doing at the moment. So, we felt the need to visualize the work of many teams on one board. Hmm. That’s not what a simple Kanban board was able to offer us. That’s why, as hands-on as we are, we poked around and came up with what we can now call the forefather of Targetprocess 3. Take a look at TeamsBoard, edition 2010:
This board doesn’t look too fancy now, in 2014, but back then it was surely a step ahead compared to a simple Kanban board. One can see backlog, and work in progress for many teams. If some states had their WIP limit exceeded, the TeamsBoard would show it. In the screen above one can see that WS team had the bottleneck with 3 bugs and 1 user story resting in the Coded state. Then this work of testing could be shared with the other two teams. The TeamsBoard also allowed zooming in on each team, and what they do, by person.
2012-14: Targetprocess 3 and Fine-Tuning Process Visualization
Then, as we realized that sky is the limit, and visualization has enormous potential for project management, and for our own needs, we moved forward with the concept of the tool where anything can be visualized, depending on the changing dynamics and goals of a company. The fundamental idea is to offer a flexible tool that adapts to any process and follows any organizational changes. The other fundamental principle is the switchability of visualizations. We do not have stakeholders who tell us what to do and what to implement next. Our feature teams and our customers are the stakeholders. They tell us where else they need flexibility, and our backlog is formed based on those needs. We run recurring UX Process Visualization sessions, to see where else do we have yet to make room for more visual flexibility. We stepped aside from the traditional Kanban as the visual process management system long ago, and what we are now having is Multiban a visual process management system that supports any development process, for any number of teams and any number of projects, with cross-team and cross-project planning, using timelines for roadmapping, views as reports, etc. This screen from Targetprocess 3 is related to the good old Kanban of 2009 only by its board-ish looks, while in reality it is a switchable slate of views, zooms and perspectives.
Why Multiban makes sense?
It’s time to say a few words about Multiban now. Perhaps, the fastest way to explain how Multiban differs from Kanban is to use a metaphor. Multiban can be compared to the 17-inch interactive screen as in Tesla luxury electric cars. This awesome screen is a one-spot customizable dashboard for media, navigation, communications, cabin controls and vehicle data. Multiple Kanban boards for one suite of products (or a related suite of features, as in our case) can be compared to putting many touchscreens in the car, or even to using plastic controls for each of those functions. Would a driver feel more comfortable using one smart touchscreen? Or many simple screens? Or many knobs? It depends. For one thing, no doubt, the super-fancy touchscreen would require a learning curve. If a driver is OK with various controls, and if they do not depend on each other, then probably the car and the driving will be OK. Switching back to knowledge work: too many things are interrelated in software development, and losing track of those connections can have a bad impact on the way the work is done . It’s hard to keep everything in mind, and use visual board as a polished parade version of a development process. Multiban, as the visual process management system, is presented by a set of views, reports, controls and boards that comply with any diversity, and any complexity of workflow, or organizational structure. Targetprocess 3 is the only digital tool that supports Multiban at the moment. The concept of Multiban is the by-product of our organizational evolution, which dictated the need for evolutionary changes in our visual process management. Now we are ready to share what we’ve learned and implemented with other organizations that have been evolving, or will be evolving, in a similar fashion.
Kanban as Multiban?
Stuck with Kanban? Consider Multiban
My twitter stream delivered an interesting quotation about quotations yesterday. This one, and the tweet came from Bob Marshall:
A quotation is a handy thing to have about, saving one the trouble of thinking for oneself, always a laborious business.
Quotations indeed take a fairly large part among tweets and other social web shares. When something troubles us at work, whether we are looking for a solution to a technical or to an organizational problem, and if talking it out with friends and colleagues is not enough, or we are shy and/or unwilling to speak, we find outlet in sharing quotes by reputable gurus, and those quotes reflect how and what we think about this problem.
I only in part agree with the quote by A. Milne above. The habit of using quotations can be perceived as lazy thinking, sometimes. However, I don’t think that people who share quotes or links online are the lazy ones. On the contrary, they are the ones who do think. It’s just that for the time being they are shy to step forward with their opinion, expressed in their own words. It might be even scary for some, to stand out and say: yes, these are my thoughts, and my words and I’m ready to be accountable for them. We are all human, and we all have things that we are not yet ready to let out to the outer world. This might be out of fear, or out of passive-aggressive reactions, or … <insert your reason here>. We might be too lazy to care about building formal logical discourses so as to pass on the message to those who do not share our thinking right away. Some people seem to resonate naturally with each other, and with some people a heavily geared-up persuasive rhetoric has to be used. Take a moment and think: which people in your social circles throw links or tweet quotes instead of writing or speaking up? They are just not yet ready to make this leap, the shift from the safe protection of quotes and references to the scary uncertainty of how the world and others would react to what would then officially be treated as their own opinion. Absolutely, they need to be encouraged to speak out and to write up.
The scary uncertainty got hold of me and of my article on self-organization earlier this week. I expressed my own opinion, backed up by intuition and personal experience, and didn’t pay much attention to references, details and credibility proofs. If I did, it would take a book, not just one article. Anyway.
There’s another controversial subject that probably has many heads in software development thinking about it. I want to bring it forth, but this time I will take a safe protection of George Lois, an advertising guru, who wrote the book called “Damn Good Advice (For People with Talent!). Software development is a creative pursuit, at least, when it comes to the ideas part, so I was delighted to see that a recognized creativity guru thinks about teamwork along the same lines that I do. The subject of groupthink, and the dynamics of software development teams working efficiently together has preoccupied me for quite some time, but I will hold back my thoughts for now, letting George Lois speak instead:
Team work might work in building an Amish barn, but it can’t create a Big Idea.
The accepted system for the creation of innovative thinking in a democratic environment is to work cooperatively in a teamlike ambience. Don’t believe it. Whatever the creative industry, when you’re confronted with the challenge of coming up with a Big Idea, always work with the most talented innovative mind available. Hopefully.. that’s you.
Avoid group grope and analysis paralysis. The greatest innovative thinker of our age remains Apple cofounder Steve Jobs, a modern-day Henry Ford. Jobs was not a consensus builder but a dictator who listed to his own intuitions, blessed with an astonishing aesthetic sense.
Everybody believes in co-creativity — not me.
Be confident of your own, edgy, solo talent.
Wait, wait. Before you throw rotten tomatoes, George Louis does give credit to teamwork, and I do, too. Here’s what goes next in the book:
Once you’ve got the Big Idea, that’s where teamwork comes in – selling the Big Idea, producing the Big Idea and bringing the Big Idea into fruition.
For props, here’s how the Amish barn construction site looks. George Lois has this image right in the book.
People We Like
Dissecting Dysfunctional Meetings
Uselink: Organizational Culture and Development Process
How Communication Factors In To Production
I continue exploring deep reasons behind various phenomena in agile software development. It’s amazing, how often the universal principle of entropy manifests itself in the relatively short ~ 10-year mainstream history of this movement. It looks like I have another eye-opener.
Entropy in software development
What is entropy, in simple terms? This is the principle of bouncebacks as in a pendulum. If there’s too much emphasis on one side, a social or ideological pendulum bounces to the opposite point, as if to compensate this overdoing. We have too many decisions to make and we’re tired of that? Let’s invent the panacea, called Big Data. We got tired of deadlines in waterfall software development, and even Scrum didn’t help, because we got tired of those time-boxed iterations? All hail Kanban now, because it has no deadlines. We are tired of managers treating us as numb tools? We want to break free, so we delve into the tempting freedom of self-organization and no managers at all. I sketched the visual for this pendulum, to make the metaphor clearer.
Now, the universal law of bouncebacks is not a problem per se. It’s a given. We can’t get away from seasons changing; and they say that if you laugh too much, you will soon cry. Anything in this world has a bounceback, if overdone. What all those bouncebacks have to do with problems of my company, you might ask? That’s what I’m getting at. There’s a composite of forces that start a trend or a movement. If the critical mass of companies are having similar problems, then the pendulum gains the powerful momentum to the opposite side. That’s how it happened with agile. Some companies hopped on this vessel as early adopters, some have not yet accumulated enough energies for that move, some are in the process of swooshing with the pendulum swing. Each and every company has their own unique place in this swing, the unique combination of energies and driving forces. The way I see it, the art of technical leadership has nothing to do with catching the swing and rushing headlong where everyone else is rushing. To follow the “join everyone else” call is the easiest thing to do, and a certain component of luck might help here as well, if a company has caught the early tide flow, and benefited from the swoosh. The hardest thing is to sense where your organization is now, in which particular point of the swing, and how standing there influences your org’s productivity and ability to deliver software to your customers.
I’ve spent enough years in software development, with customers, developers and managers, and I speak from personal experience. It feels good swinging along with the pendulum as it bounces from the left to the right, as on the picture. I felt that the agile movement and self-organization in a team is what I really needed at some point of time. However, later on I started connecting the dots in the bigger picture and saw some signs that self-organization and several other values declared in the agile manifesto are not universal laws. They rather signify the points of bounceback. There’s no universal proof that self-organization, or face-to-face communication yield the highest productivity for any company. Keep in mind that agile manifesto signatories are software craftsmen. They’ve postulated the agile principles to declare that software development is a craft, and they are a noble guild that wants to serve customers. By declaring those principles, they mentioned nothing about constraints, times-to-market, expectations of stakeholders, and financial goals.
Is it a human instinct to deliver projects on time?
Some complexity theory studies compare the laws by which organizations function with those of colonies of ants or flocks of birds (e.g. check this article dated 2009). According to those theories, ants and birds know instinctively how to self-organize to fetch food, or to fly safely to their destination, and the researchers somehow concluded that IT companies must follow the same pattern. I’ve shared this belief until recently, when a realization struck me. I beg your pardon, but is it our natural human instinct to deliver a release on time? Or to a meet a harsh deadline? Can you imagine the Great Wall of China built by a self-organized team? Of course, no. Why am I asking this? Well, software developers are not ants and birds, and, speaking of instincts, their basic high-profile instinct as software craftsmen is to craft what they do to the point of perfection. If given endless time, they would craft it at their own pace, be it a UX design, or a piece of code, and that’s where they indeed are able to self-organize and run a flat organization as e. g. Valve or 37 Signals do. Lucky is a software craftsman, and lucky is a team that can afford the luxury to release at their own pace, with this deep feeling inside that they have crafted this piece to perfection. However, we live in the world that is full of constraints. A pizza-sized team of craftsmen wants to grow big, because they now want to come up with yet another awesome software. This move requires more hands, and coordination with stakeholders, internal and external ones. The noble castle of software craftsmanship is invaded by merchants, who want deadlines met and sales goals hit.
So, when the harsh reality of the market hits the noble craftsmen, they follow inertia and think that self-organization (or flat structure) will let them achieve those very non-instinctive deadlines and sales goals. Looks like that’s what happened to the guys from Everpix who did not have practical guts to comprehend that they have to take merchants into account, and kept having their heads in the clouds. If they were smart enough to sense in due time that the pendulum wants them to swing backwards, down-to-earth, to pragmatism and discipline, Everpix might have still been alive delivering some nice service to people. That didn’t happen, however.
It’s time now to take a pragmatic look at the eulogies they sing to flat organizations and self-organized teams. The opposition of hierarchy and flat goes first in the list of pendulum bouncebacks (see the sketch above). As for the other three pairs, I’ve covered them elsewhere. The flat company structure is related to the concept of laissez-faire leadership. While this is an excellent approach to leading a company from the standpoint of individual learning and skills acquisition of team members, it does have some faults if what a company needs most of all at this very moment is maximum productivity. Quoting the article that I linked to above: “Researchers have found that this is generally the leadership style that leads to the lowest productivity among group members.” Again, this leadership is a bounceback from rigid hierarchy. It does allow people to take decisions and contribute to the activities that are beyond their direct responsibilities, but people have only so much energy, and it strongly depends on individual working styles. It could be that someone who has a lot to contribute to good decisions is not OK with the combined need to make decisions and to produce deliverables. Organizing and decision-making is work, the chore that drains energy from the performance component of such an individual. If a UX designer or a senior developer who is at the same time responsible for the implementation of a feature or a design spends too much time in decision-making activities unrelated to their main work, this is a serious hindrance to productivity. Oh, and don’t forget that personal discipline and responsibility is a must for that style, as well as high cross-competence in all aspects of software development. What happens then if team members lack competence, and what they do is learn? The momentum spent on learning is subtracted from production. Here’s a visual to help explain the idea quickly:
The background colored shapes show how each of the components would take from the other two, if overdone.
Balance learning, time and productivity?
There is a way, though, to get the best of productivity and keep the learning in place. But it does require smart thinking behind the daily setup of company operations. Back to the pendulum, the tech leader has to keep the company somewhere around the pivot point, with no rush to extremes. Someone has yet to develop the balanced mix of agile and hierarchical management. This mode of pivotal operation implies razor-sharp intensity and focus in anything and everything, the foresight in knowing and defining which issues need whose attention, and when, and setting the boundaries as far as to the point of worshiping individual productive flows, that of decision-makers and that of performers. It takes some hard thinking, and taking hard choices: can we afford hitting 5 meetings with 7 people to discuss this issue? Is it worth it? Does it really matter for productivity that everyone reconciles and has the same viewpoint on any given problem? How the skills and competence of people can be applied optimally, to keep them working and have them learn new things? As I read stories about companies that seem to be successful with flat structure, I noted their discipline and foresight with work-related interactions. So, if tech leaders want to copy-paste the laissez-faire style because everyone says that it’s cool, they need to be realistic in the assessment of where their company is in the pendulum, and which priorities overrule at this very moment. Hands-off leadership, which is the same as self-organization, is a luxury that not everyone can afford.
I hope to share more thoughts on the modus operandi of tech leadership in the future.
Back to The Future of Agile Software Development
Kanban as Multiban?
Prioritization and Big Data? Think Human Nature
Why Is It Right to Write?
This article includes 42 timelines that I looked at recently. Timelines are used in education, finance, aviation, banking, news and media, in project management and what not. I hope this one-stop collection will foster a feel for good visualizations, helping you be creative with your own timelines.
There goes. Let’s start with timelines in education.
#1. Native American Timeline
The history of Native Americans is presented as a railroad with stops.
#2. Historia Timeline
Some major history events with pictures are listed here. This is rather a repeating sequence of date-text-picture pieces, not a classical timeline with x-y axes. It works well for educational purposes, nevertheless.
#3 History of the Earth
This timeline embraces 5 billion years. I like how eras are synced with water and earth stages.
#4. Microbiology Events
Here’s the explanation of specific time periods from this timeline. The layout is similar to #2.
#5. Timeline of World Religions
It would take a lot more time to retrieve the information presented on this timeline from plain text.
#6. The History of English
Same as with #5.
#7. The Growth of The Republic: Population and Economy
This is a fragment from the awesome infographic A Visual History of the American Presidency, which has several timelines incorporated into it. The growth of the republic timeline shows how population and GDP were growing with time, along more states joining the Union. You can explore this infographic online for more details, the screen below is given for quick reference.
#8. US Presidents Succession Timeline
Another fragment of the same infographic. Fluctuations in popularity are mapped over years.
#9. The Ideological Dynamics of the US House of Representatives
This timeline shows how conservatives, liberals, democrats, GOPs, etc. correlated over time. The source infographic is interactive: data can be filtered by state and by party.
#10. Kennedy Shooting
Another reference to US Presidency, a sad one. This timeline has a mix of daily and hourly distribution of events, depending on how fast they unfolded. The source timeline is interactive; bubbles with more information open by clicking on dots.
#11. Alcohol Taxes – The Tipsy Turvy Republic of Alcohol
Let’s switch from US Presidents to US alcohol. This timeline is self-explanatory (click for high-res).
#12. A Century of Motoring in America
I found this timeline in the Information Graphics book. Here’s how it’s described: “This is a history of the automobile in one image. Using the metaphor of a board game, the graphic follows the most important milestones in the first 100 years of cars. ..History is thus conceived as a timeline drawn on a fictional map.”
#13. LA – NYC Road Trip Timeline
Country roads, take me home.. That’s the feeling that I get looking at this timeline. 2 guys drove from LA to NYC for 14 days, and made 4219 miles. The color-coding in timeline shows who drove, for how many miles, which places they drove by on any given day. You can explore this timeline in more detail here.
#14. NFL — History of Current Franchises
This timeline is a bit unusual, with events going from top to the bottom. Each bar is a team, colors show which league the team belonged to throughout the history (click for hi-res).
#15. Bestselling Books
This timeline shows how the rank of bestsellers in Catalonia (Spain) fluctuated from Oct 2007 thru Oct 2008. With timelines, dotted and solid lines are used to convey more information quite often. Here, the dotted lines are used to accentuate best sellers that dropped out of top 10. The books by Catalonian authors are shown in red, the others – in blue. I included this timeline not for the sake of the info that it conveys (sorry, I don’t speak Spanish), but for the sake of showing that a timeline can be used to represent such kind of information as well.
#16. Mission to Mars
An unusual timeline showing Mars as a destination for many missions that resemble tentacles closing in on the Red Planet over a circle of time.
#17. Sleep Agony Timeline
From Mars to purely down-to-Earth matters, such as sleep. That’s a sleep timeline from a life of a parent in NYC.
#18. Sleep Bliss Timeline
Here’s how it looks. Not as cluttered as the agony one.
#19. Motown’s 191 Number One Hits
One more timeline from the Information Graphics book by Taschen. The distribution of 191 top hits released under the legendary Motown label is shown over time, with years – months intersections running by circles. Color coding refers to the most successful artists. You can look into more details of this timeline here.
#20. The Web Technology Timeline
No comments :)
#21. Transparency Productivity
This timeline explores the connection between technology and productivity. No outstanding infoviz mastery here, just a good quick-look timeline.
#22. Life Online
This high-density timeline shows how technology influences social life over time. If you want to take a close zoom-in look at it, as well as on the timelines #23 and #24, there’s only one way to do it – get this book. The timelines were created by Paul Butt.
A close-in on technology…
…overlaying with culture/media events:
…and with the count of visitors per month for major online hubs:
#23. Disk Space
The evolution of data storage and processing.
A a close-in on a piece of this circle timeline:
#24. Mobile Evolution
The evolution of mobile phones and text messaging.
#25. Timeline of MS Windows
It only traces the evolution of Windows till 2007, but the rest of Windows history can be visualized in the same fashion. The timeline overlays MS Windows versions with devices.
#26. CNN Traffic Analysis
The central spike chart demonstrates weekly page-views over time; black tags mark the ten busiest weeks, with specific events highlighted with white tags below the central axis. In the lower part, the growth of site categories is tracked. This timeline demonstrates the evidence of how CNN.com became accepted as a timely news source.
A close-in on the bottom-right part of the timeline:
#27. Airline Business Timeline
I have a special kind of love for some airlines, so I like to look at timelines related to aviation. The interactivity is here.
#28. The Flights Timeline
Powered by Hipmunk. It’s easier to pick a flight with this visualization. Expedia has no such timelines, as far as I remember.
#29. World’s Worst Plane Accidents
Look at this timeline, and fly safe, always.
#30. 3D in Focus
This timeline shows the rise in box office earnings from 3D movies, as well as a timeline of every 3D movie released in the last ten years. Created by Reuters.
#31. A History of Violence
Another timeline by Reuters. It’s the job of news agencies to deliver information to the public, in a concise and timely fashion; so it’s no wonder that Reuters produces lots of great timelines.
#32. Booms and Busts
Probably, financial timelines are the ones that we see most often. I included a couple of them to this collection. Click here for the interactive version of the Booms and Busts timeline.
#33. Oil Price Timeline
Barrels over time, by Reuters (source).
#34. Euro Zone Debt Crisis
Good job. I mean, not the crisis, but the timeline.
#35. Gantt Chart Timeline in MS Project
Rounding this list up with timelines related to project management. Gantt chart is the grandfather of such timelines. Maybe someone has forgotten already how those look? Here’s the reminder.
#36. Multiple Projects Timeline in Excel
I found this timeline here, and I can’t but admire people who manage to track their projects in Excel. However, I wouldn’t say that this timeline will work for complex projects. This Excel timeline shows personal projects, plotted over time.
#37. Basecamp Timeline
Heh, this number goes to 37 signals who recently rebranded themselves to Basecamp.I will turn on the critical mode here. This information is presented as a timeline, but to me it looks likes a feed of events. The alternation from the left to the right breaks the monotony, but probably this screen could have been used to convey some other information. When there’s too little info over too much space, it’s called “low information density” in infoviz lingo.
#38. IntelliGantt Timeline for BaseCamp
That’s a BaseCamp-based modification that someone created. Months and days are vertical lanes, horizontal lanes are people. I like it, that’s a nice timeline to see the dynamics of assignments per person on a timeline.
#39. Planning and Construction Timeline
For a change, here’s a timeline unrelated to software development. It shows when the building units will be busy or vacant, and how the construction will be planned.
#40. A Hand-Drawn Project Timeline
Anyone can draw a timeline on a whiteboard. That’s a timeline sketch that we’ve done about a year ago. At the moment, something similar to this timeline is available in our project management tool. Hand-drawn timelines can work if someone takes on the responsibility for syncing all the data from the tool with the timeline (think, how much data you have?)
#41. Product Features on a Timeline
We use digital timelines more often than the hand-drawn ones, no doubt. That’s how a timeline for features looks in Targetprocess 3.
#42. Person-Project Assignments Timeline
With a switch in settings, we will get another timeline view. I’d better stop here because I’m tempted to showcase even more timelines that we’ve made possible, but that probably would be too much.
These were my 42 timelines. I stopped at 42 because it’s the ultimate answer to anything. The whole Universe consists of overlaying timelines, if we think about it. Some timelines exist simultaneously in parallel spaces, some timelines are consecutive. Thinking with timelines not only helps us grasp information fast. It helps us embrace the whole world.
.. or how agile manifesto has put a stigma on writing, and how this stigma backlashes on the culture of learning.
In one of my previous articles I’ve explored the roots of agile movement, and the mindset that guided the founding fathers of agile manifesto. The manifesto had this as one of the principles: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” In the environment that existed 10+ years ago, when developers wanted to break free of the documentation associated with bureaucratic procedures, it seemed very reasonable to introduce and to follow that principle. It turned out, however, that the ardent followers rushed to the other extreme, and any other writing than that of code, or of user stories has rather been regarded as waste. No doubt about it, face-to-face conversations rock within a development team, and this principle is very appropriate in this context. But here’s the catch: if a principle is copy-pasted to a group of similar but still different situations, this might result in some negative side effects.
That’s exactly what happened to writing. With this inherited stigma of bureaucracy and waste,writing things down might look like an optional topping on an ice-cream. Why write, if everything can be discussed? I want to tackle such attitudes in agile teams and highlight tremendous benefits that the culture of writing brings with it. I am not talking about group chats, or problem messages, or technical documentation. What I mean is writing to express a thought, or an opinion, or to share the thinking behind some decision with the rest of the team in a logically coherent piece of text.
If keeping a library at a softdev company and reading is a #1 way to broaden horizons and balance technical competence with the other sciences related to software development, writing is #2. Talks and discussions are only #3. Why is writing so uniquely rewarding? On the one hand, it comes across as a tool that helps to hone logical thinking and express ideas with clarity. Speaking in a discussion as in a meeting is a spontaneous communication, an unprocessed feed of thoughts, that lacks the fine polish that is required to make a point. In contrast, lawyers are trained to have an excellent command of spoken rhetoric — the art of building a logical discourse to convince others. It’s the essence of their profession.
IT people do not seem to be that sharp with rhetoric skills, unfortunately, and they “owe” this to the technical focus of their education. I’ve written more on that in the article The Origins of Big Data Trend. Writing will fill this gap; the more someone writes, the more fit they become for speaking. Somehow, most people believe that the reverse is true: first comes speaking (and they do talk a lot), and then writing. It’s not like that. Being a good writer comes prior to being a good speaker, so if someone likes to talk but cannot write, might be that this person wastes everyone else’s time in meetings (unless they use the services of speech writers, which is unlikely).
With thoughts carved in the written form, people get better at sharing what they have to say, and eventually become better speakers. We also become better thinkers, because we start writing with one mindset, and then shift to another one in the process. Writing helps turn on the lights that highlight a problem from many perspectives, which is more likely to result in an efficient solution. When thoughts exist only in someone’s head, they are ethereal and scattered. Once neatly stacked, either on screen or on paper, they acquire discipline.
Now, suppose someone is aware of all the treasures that writing brings with it, and wants to champion this culture in their company. How can writing be practiced, in which form, does it have to be pushed on each and everyone? Of course, not. Some people in your team might not be ready to write yet.
We need time to accumulate the critical mass of knowledge that will want to find an outlet. There’s one tip as to how to define who is ready for writing, and who is not. Many use social sharing these days, so if someone in your team tweets links related to a problem at work, this person might be ready to venture out and share thoughts in writing. Such people need to be encouraged to write; throwing links will not take them far in expressing their own thoughts and ideas. There’s one other important thing. If writing is a part of company’s culture, then writers will need their peers as readers. Posting to an internal company blog comes first, then there can be a public blog. Posts can include logical discourse pieces that explain how this or that technical or strategic challenge was resolved or can be resolved; stories that software developers usually share in forums; essays and insights about company culture, what can be improved, what’s hot, etc. Sky is the limit. From the learning perspective, it doesn’t really matter what people write about. What matters is how they write and how their thoughts and ideas resonate with readers.
I came across a very interesting timeline visualization the other day, as I was skimming Semiology of Graphics, the awesome book by Jacques Bertin. If you’ve been following articles on visualization in the Edge of Chaos blog, you might be familiar with it (see: My 12 Visualization Books).
This timeline shows how the actual and potential decisions and events have unfolded during the Cuban missile crisis in 1962. This series of moves, as in a chess party, is believed to have brought USA and USSR to the closest point of real nuclear conflict that threatened massive mutual destruction. The crisis was eventually resolved, and this visualization covers the whole story:
This mixed events-decisions timeline got me thinking. No doubt, the Cuban crisis does deserve to be visualized that way, with its hidden and/or possible threats and agreements. But I don’t recall ever seeing any similar mix of both events and decisions on a timeline anywhere else, neither in a presentation, nor in a case study of a project success or failure. There’s a bunch of visual techniques for decision-making, but it looks like there’s no common visual technique to facilitate a retrospective analysis of decisions bundled with actions.
For example, we can use a release timeline to reverse-track the points of ”Done” for features, and we will embrace the whole picture in one look. But what would we do at a release or a project retrospective, if we look at a timeline and see that our initial estimate for releasing a feature is very different from the actual release time? An events-only timeline won’t give any clues to stakeholders as to which decisions resulted in this late release. Hence, they’d have a lesser chance to improve them. Someone would look at a timeline in 6 months and think to themselves: “Hmmm, I can’t remember what happened, why we were actually that late with releasing this thing?” That’s where visualizing a sequence of decisions+events over time might come in handy. It’s worth noting that we are somehow more interested in “the reasons for failure” when at a retrospective, but this wording and thinking is hardly a good fit. We need to formulate this question in another way. Which sequence of decisions resulted in the delay?
Focusing on avoiding mistakes takes our focus away from becoming truly exceptional
Well, it could be that taking such a grand look at a delayed project release is an overkill. Okay. Let’s then move a level up and see how visualizing decisions+outcomes will help in an even more serious stuff, such as analyzing a failure/success of a business, or a start-up. This article puts together 51 Start-Up Failure Post-Mortems. Ironically, the web page offers a context ad which says something like: “get data and trends on start-up failure”. I’d say the prevalence of data- and trends-based thinking is something that most of the failed start-ups have in common. With everyone having access to statistics and trends, it’s quite logical for the failures to be grouped by certain criteria. A successful start-up must have something more up their sleeve than data and trends. That would be spot-on decisions in their particular context, free from “join everyone else” mindset.
What I’m getting at is: if start-ups and established businesses had a visualization technique similar to the one used for the Cuban crisis, they would be able to take a deeper insightful look into the nuts and bolts of things. I presume that people who read the stories of failed or successful start-ups want to learn their lessons based on these stories, so having them visualized as a timeline with actual/potential decisions looks like a good idea.
I only hope that one day some start-up will get busy and come up with a timeline that would visualize not only events, but actual/potential decisions and their linkage with the events as well. This will give an excellent tool not for decision-making — there are zillions of visual techniques for that — but rather for a retrospective analysis of success/failure of a business, or a product release, or a PR campaign, or shooting a blockbuster, or staging a play. The practical applications are diverse, and such a visualization would facilitate the insightfully pragmatic thinking and successes, rather than failures.
*The highlighted quote is taken from the book Turn the Ship Around!: A True Story of Turning Followers into Leaders
Retrospectives, Part 1: In Your Own Sweet Way
Retrospectives, Part 2: In a Sentimental Mood
Mind Maps in Cognition
Competent Decision-Making and Rusty Tinman
No, I don’t love them for acting like police and filing reports if they spot a deviation from some “standard certified” rules in the development process. I wonder if it makes sense at all to monitor software engineering processes for compliance to abstract guidelines written by someone who’s never seen how your company actually works?
No, I don’t love them for meticulously clicking through screens in the UI-heavy cases, even though this job does deserve to be admired. Also, I don’t love them for following established testing practices without ever having a thought of questioning or tweaking them.
No, I don’t even love them for writing automated test scripts; it’s because some people view this skill as the only upper sky limit for QA’s. Neither do I love them for checking that a certain functionality in the product is implemented exactly as in the specs.
My point is that with all the above scenarios QA’s are supposed to function rather as cogs in a machine, and not as thinking individuals who have a lot more in store than the narrow-minded ability to follow rules and guidelines. It depends on an organization, of course, because in some companies QA’s are regarded only as human-shaped tools.
What is it that I love our QA folks for, then? It’s their ability to see the big picture and contribute to the quality of the product on all levels. I also love them because they keep a reasonable calm stance to bugs and glitches in software and UI. Some QA’s take it personally if the count of WTFs per minute is overriding all possible limits.
I love our QA’s for being curious people who go beyond the “human tool” thinking which seems to be prevailing in the industry, unfortunately. A professional QA person is someone with the analytical and critical mind, who reaches deeper into the background of the job at hand. It’s not only about writing automated tests, or test-driven development. The QA’s big picture embraces anything that has to do with how product appears to users. A truly competent QA will question irrational practices, bring this to everyone’s attention, and suggest ways to do things better. This sounds like a mix of internal auditor and external agile coach, and not everyone will have it, but if a company manages to raise such people in-house, the benefits are obvious.
Our QAs have this thoughtful mindset in place, and some of them have re-invented themselves outside the QA domain. A web operations/automation engineer, a product specialist, a feature owner, and there’s at least one ex-QA among those guys who overhauled our technical support and introduced the high service standards that our customers seem to appreciate.
The well-rounded QA’s are precious in almost any activity of a softdev company. They start from the bottom up and literally click their way through to the bigger picture. QA’s excel at noticing the flaws that others might miss, and this combination of inherent responsibility + attention to detail +analytical mindset makes them appear both as excellent problem finders and problem solvers.
Why do we need a library?
In a recently published article ( The Origins of Big Data Trend) I’ve pondered on the reasons and consequences of why software developers find themselves locked in the narrow technical mindset, and how this affects business and technology trends, for better or for worse. When someone only knows how a second leg of a centipede makes a move, and has no idea of what makes the whole centipede glide on all its 100 legs, they will be at a loss in the face of unexpected new challenges. Software development craves for more people with a broader outlook. That’s why it’s in the best interest of IT businesses to encourage the culture of learning with their employees. If formal education fails to provide this well-rounded knowledge, we need to invent our own ways to catch up. Reading appears to be the most obvious catch-up strategy.
The culture of continuous learning has always been nurtured in our company. It starts with hiring: we only welcome people who are genuinely interested in learning, and have curious minds. We learn, explore, share knowledge, do internal conferences, and one of the things that supports this culture of learning is an old-school library of paperbacks in the office. This tangible library makes learning easier. If you see all those books every day, it’s hard not to stop by and not to skim through a book, or two, or three. We do not have a formal curation strategy, as to who is supposed to read what. If someone wants a book — the book is ordered, and that’s how our TauLibrary has been formed. It has 300+books and counting.
How do we manage books in the library?
We use Targetprocess, our project management tool, to track the circulation of books. There’s a project called “Library”. When someone wants a book, they create a user story and put it to “Please order” state. The next state is “Ordered”, and then there’s a state called “In Stock/Reading”. If a book is assigned to someone, the assigned user is currently reading it. If a book is available in the library, no one is assigned.
Here’s how the books look as a list of user stories:
.. and broken down by some tags:
Which books do we have?
The library has books on management, agile, lean, kanban, testing, programming, machine learning, artificial intelligence, continuous delivery, statistics, mathematics, data science, psychology, linguistics, philosophy, writing, marketing, SEO, design, visualization… Ufff. What else? I find it hard to categorize all those books that we have. Tags might do this job better than me. Perhaps, there’s even no great need for categorization. Software development is a fusion of many disciplines, that’s why developers need to know what visual arts and cognitive sciences are about; designers need to get an idea of what developers are doing; marketing people will want to learn more about data science and visualization. Everyone has to catch up in some field of knowledge. Reading is the very first step, what goes next, depends on individuals. Either way, a library is the low money investment with a huge return on a company’s ability to innovate. Ultimately, all things learning transform to innovations. The spirit of innovation will reveal itself in the way people think, get insights and discover subtle perspectives of looking at familiar problems. If the culture of learning became mainstream with IT companies, I’m sure this world would have a lot more friendly, nice and usable software products.
My 12 Visualization Books
Infoviz: Taxonomy of Names In Sports Leagues
A Lifetime of Presentations in One Book
Continuous Problem-Solving Is No Accident
Work in software development is made up of 2 essential parts: planning and doing. It stands true for any methodology, be it agile or lean or any other variety thereof. The theory of project management has it, that a project can accommodate 10-20% of time spent on planning, tracking, adjusting trajectory, wiping the binoculars, etc. At least, we used this approximation when I worked in an outsourcing company many years ago, and it varied depending on the challenges the project was facing.
With projects, this world has only 2 options for anything else than doing:
Option #1: the bulky “talk-plan-remake-do it again” cycle is a given.
Option #2: over-indulgence in all things talking and planning is a waste.
The hardest job is to distinguish if a project falls into option #1 or option #2. If the option #2 is disguised in the make-up of a given, developers and other performers will feel troubled about whatever they’re working on. When someone has a job to do, all they need is to be left tete-a-tete with their work, and as little contacts with the outer world as possible. If a stretch of work — be it during the day, or over longer periods of time — is interrupted by previously overlooked hurdles, the drive to ship is replaced with something like this.
The unwelcome “talk-plan-remake-do it again cycle” usually happens if planners are not directly involved in the ship-deliver activities, and lack foresight in tracing the hurdles in advance. For the actual performers, being subjected to all kinds of catch-up moves feels like a huge annoyance. Performing is a raw and healthy thing. Some software developers naturally feel more inclined to performance-based activities, and their philosophy is: “I care only for what I have to ship, and I don’t want to mess with the waste of talking.” If we draw a parallel with performance on stage, the feeling after having shipped a piece of work would be akin to this: I’ve worked my a.. out, I’m sweating and exhausted, but I’m happy because I performed and delivered the show that people liked!
There’s nothing as fulfilling as a happy experience of a well-accomplished performance, and performers find delight as they ship something on any given day. All the tiny dwarfs in the world run a round of applause at that. The deliverable can be a piece of code, or those few milliseconds of faster load times, or a finished design element, or an HTML-coded web-page. If it feels like too much unwanted planning and discussing that undermines this desire to perform, your team is in trouble. This feel signals that the whole act of planning is misinterpreted, and is seen as a thing-in-itself that lives in isolated reality, unrelated to a shippable outcome. Besides, it’s a proof that the keepers of “talk-plan-remake-do it again” routines lack competence in nailing down the optimal solutions at the right time. If that’s what’s happening in your organization, remember that talkers and planners are not the rainmakers. Performer is the rainmaker, and planners would be better off if they let performers perform, or better yet, get to performing and doing rather than talking and planning. The catch here is that with time some sort of organizational blindness might develop, as talkers and planners manage to come across as rainmakers. Beware that optical illusion.