The concept of Minimal Viable Feature (MVF) is a significant milestone in product development. Release something that you think solve a problem and listen for the feedback. While the concept itself is great, the devil is in the details. In general, it is quite hard to learn how to define MVF. It is an art, not a science. In this article I will share my experience and some patterns I learned.
#1 Cut. The. Scope.
The most common mistake in MVF definition is bloated scope. There is always a desire to put one more thing into the feature and make it more useful and more appealing to the end user. No Product Owner can resist this intention and in almost every single feature I lead I added some unplanned user stories. In fact there is nothing bad with this approach, you discover new information and change plans. However, there is a real danger to push feature beyond MVF and delay its release. 9 months feature? We had it in our company.
Now we have a 3-months rule for every MVF. There should be serious reasons to spend more than 3 months on MVF implementation. MVF goal is to prove concepts and discover “unknowns”, don’t blow it to MMF.
#2 Feature kick start
Everybody should understand why we add this feature into a product. There is only one reason to add a new feature — it solves some important problem that quite many users face quite often. In the simplest case you have hundreds of requests that picture problem in bright colors and all you have to do is invent a solution. In a more complex case users don’t fully understand the problem and throw out various solutions that in fact don’t solve this particular problem. Only experience and system-level thinking can help to spot such cases. In the worst case you have no feedback and rely on your intuition to define the problem. This is a dangerous practice that can lead to extreme results: genius insights or total fuck-ups.
On a Feature Kick Start meetings we have people from marketing, development, testing, design and sales. All bring valuable information about various facets of the problem.
These meetings have several goals:
- Clearly define the problem we solve.
- Define a scope of MVF.
- Decide what we don’t know and what feedback we will accumulate now and after MVF release.
- Bring development team and sales people to a common understanding about the feature.
#3 Huge upfront UX is bad
We tend to have UX and Development as a completely separate activities. Sometimes we spent months on a feature UX, built prototypes, tested them and then boom… priorities changed and feature is no longer needed so much. Almost all the time we spent was just a waste. Let’s say we get back to the feature next year, but now we have new information and UX we did a year ago is obsolete now, so we have to start over again.
Now we start UX when feature is actually starts. It means Feature Team almost completed previous feature, so it has some spare time to dig into the new feature and discuss its design, flows, etc. It may happen that developers don’t do much for some time, since UX is not ready. However, there are often many things they can do: fix some old bugs in background, prototype new feature, try some technical and architectural ideas, implement something we 100% certain about. So while in theory it looks like you are not “utilising 100% of resources capacity”, in practice single-feature flow for a Feature Team shortens cycle time and reduced waste activities.
#4 MMF is inevitable
Usually MVF solves a part of a problem and some cases are missing. Usually the solution itself is not the best. In most cases MVF is not a “complete” feature and you should finalize it. We call this finalization Minimal Marketable Feature (MMF). At this point feature provides a complete solution to a problem, the solution itself is beautifully designed, it is on par or outperform similar solutions in competitive products.
It may happen that new feedback will reveal that MMF is still not enough, so then you can iterate and release as many improved features as you need. This process is not formalized in our company.
#5 Real feedback is slow
We hoped to have 2-3 weeks delay between MVF and MMF and we thought it will be enough to accumulate enough feedback. We wanted to have process like that:
However, in most cases it takes 2-4 months to generate good amount of relevant feedback. It takes time to accumulate and reveal common patterns. For example, we re-designed navigation and allowed users to create their own Groups and Views inside these Groups (BTW, it was the case when we throw out UX done 9 months before feature start). It took us 5 months to actually understand what mistakes were made and what problems most companies have with this new flexible navigation. It appeared, the navigation was too flexible, so now we are reducing this flexibility and add some restrictions.
We changed the process and now we plan for 3 months delay between MVF and MMF. This gap is used by another MVF, so on a high level we release first minimal feature, that release second minimal feature and then based on generated feedback we complete both features.
#6 Real feedback comes from real usage
Don’t get me wrong, I’m not against prototypes, wireframes sharing, surveys, etc. However, my experience showed that the only way to get a really relevant feedback is to release something in a product. All other ways of feedback generation are flawed. Real users bring so many unexpected and interesting insights.
When we started UX process adoption on our company 6 years ago, we tried almost any possible way of feedback gathering. We created several solutions to a single problem and run usability tests, ran surveys, interviewed customers, ran UX groups and shared concepts and ideas. We still use most of the methods from time to time, but our current approach is extremely lightweight and balanced. In general, we build light prototypes only when we just can’t select a solution from two options (50/50 votes inside our team). We never build full interactive prototypes that replicates future system behavior, but just share sketches and main concepts. With right questions asked this simple method allow us to get a very nice preliminary feedback.
- Set clear MVF goal and cut MVF scope that beyond this goal.
- Bring sales, marketing, development and design people together to define MVF.
- Huge UX phase upfront is bad and usually leads to waste.
- MVF is not a full feature. Embrace it and don’t rush.
- Real feedback comes from a delivered feature only.
- It takes several months to accumulate information to reveal patterns and decide how to improve feature.
I’m 35 and only recently I truly nailed what drives my life — it’s “creation”. When I create something meaningful I feel really great. My creations are not tangible in most cases, like poems, songs, design solutions, new product features, articles, books and blog posts. In general I think creation of anything that lasts is a good way to spend your life.
Source: 25 ‘Minecraft’ Creations That Will Blow Your Flippin’ Mind
Deep immersion into a working process turns off everything around. You suddenly ignore all external sounds, you don’t feel how minutes and even hours passing by, you don’t notice poor lighting and reject timid body requests. Then you wake up and check the result. Maybe it’s not perfect, maybe it’s just a start of something significant, maybe you will throw it away in several days after critical examination, but nevertheless you have a sense of achievement. You’ve just completed a thing that may be a part of your legacy.
Can you write? Can you invent a software that changes people lives? Can you build a house? You never know till you try. Your life passion is not “programmed”, it should be “discovered” via experiments and achievements. Moreover, public recognition in many cases is not a good indicator of your achievements. Your personal feelings do matter. When you achieve something and enjoy the process, it is a good signal that your experiment was successful and you should keep going. When you spent quite a lot of time on, let’s say, quantum physics with no clear results and theoretical constructions bored you to death, maybe you should try something else (or maybe you just have a depression, but it’s curable).
Any startup and any ambitious mature company should hire as many creators as it can. These people are enthusiastic, active and relentless. They are the engine of a company. They keep learning, experiment a lot and failures are just a part of their working process. Every team desperately needs at least one creator, otherwise it will be mediocre at best.
How to discover a creator? It is relatively easy to do. Usually they can have something from the list below:
- Side products (frameworks, apps, whatever)
- Blog, articles, books, whatever
- Hobbies related to creation (painting, robots construction, fancywork)
- They usually like LEGO and Minecraft (this option alone is not 100% proof that a person is a creator)
Consumers are all around. We all consume books, movies, TV shows, cars, food, etc. How many of us transform all these consumed information, experiences and skills into something meaningful? Surprisingly, creators are quite rare. It’s incredibly hard to find one and align his goals with company goals. Sometimes they are not polite and hate everything that blocks or slow downs acts of creation. They will not tolerate political games and bureaucracy. Most attempts to cheat them and exploit them will fail in the long run.
We need to build companies that promote honesty, creation and learning. I’m here to create. You?
How diversity helps us in problem solving, creativity and overall intelligence? It helps a lot. Diverse groups of people can produce better results and radiate more creativity. But what about your own, personal diversity? Is it a good idea to accumulate knowledge from wide range of disciplines? Does knowledge of music theory help to write better code? Does knowledge from biology make you a better user experience designer? I believe yes, and here is why.
Douglas Hofstadter and Emmanuel Sander wrote a very controversial book Surfaces and Essences. It is not an easy read, but it is time spent well. Authors unfold thinking process from language to high level constructs. They show how analogy-making helps us think, generate new ideas and fuel our creativity, including scientific insights.
This book deeply resonated with me. In general I agree that analogy-making is a core of our creativity. I even tried to apply knowledge from Running domain to Software Development domain and generated some quite interesting ideas like Interval development. Sure these ideas can’t be proved easily, since analogy doesn’t mean the idea is great. But still it is relatively easy to take knowledge from one domain and apply it to another domain.
How can it help me?
All that brought me to the idea to increase my personal diversity and expand my knowledge beyond typical areas like system thinking, software architecture, groups dynamic, innovation models, user experience and other stuff every CEO learns. I read books and took courses about quite diverse topics already, but I did that in a chaotic way.
Suddenly it became obvious to me how all these new domains can help me to be more creative and solve problems better.
What domains should I explore?
I think you should try anything you always wanted to learn, but didn’t have time to. It is quite hard to predict what analogies can be generated from unknown domains. For example, you always wanted to know how people paint, how art evolved and how Michelangelo painted a fresco of The Last Judgement on the altar wall of the Sistine Chapel. Dig into the art domain and learn as much as you can in a single year. Will it help you to be a better software developer? Why not? If you try to paint something you can train patience and learn how to sketch (everybody should sketch, you know). Michelangelo’s approaches may give you some ideas how to structure your work. As I said, it is hard to predict exact ideas that you’ll generate in the end, but I promise you will generate some.
I personally want to study biology, music theory, architecture, education, medicine, go and swimming. If a simple running domain gave me new insights, I believe larger and more complex domains will bring even more value.
Why one year?
A year is a good timeframe to focus on something. It will be your new hobby for a full year. You can read 20+ books, take 1-3 online courses, maybe take offline courses, try to apply your new knowledge constantly. Small domains demand less time, but larger domains are hard to grasp in 2-3 months.
I don’t believe in quick solutions. You can read a book or two about a subject and have some fresh air in your head, but it is not enough to just scratch the surface. In 10 years you will have a decent knowledge in 10 domains. That sounds cool to me.
Did you try that?
Nope. I started to dig into music theory recently. So far I’m just sharing the idea with a hope that there is always a chance you’ll like it and give it a try.
And maybe, just maybe, you’ll even find your new passion. Who knows?
This is my personal humble feedback on Agile Conference. I do make broad conclusions though, so feel free to provide your vision in comments.
I haven’t visited Agile conferences for like 5 years, the last one was in Chicago. It was pretty good. The main innovations were Kanban and UX+Agile. Many sessions were still quite boring to any experienced agile practitioner. Now I’m in Orlando. Conference becomes huge. There are so many people around. But what about sessions? In 3 days I visited exactly one session that was really interesting and useful, it was about Netflix culture at DevOps track. All the others I visited were not useful, boring, kinda OK, way too abstract or completely trivial. Maybe I was just unlucky and missed all the good talks. Maybe, but I picked carefully, to be honest. I talked to some people and received mixed feedback, but in general it looks like conference content is not great. DevOps track looks very good, BTW, and I heard many good words about it.
How do I feel about all these things you ask me? I personally see a serious stagnation and the lack of innovations in agile community. Don’t get me wrong. There are bright people with brilliant ideas, but it seems they are in opposition to the main trends. How’s that happened?
Agile is about helping businesses to kick ass. To do that, there should be innovations in various directions. We, as an agile community, should invent new ways to help business understand what is valuable and what is not. Invent new development practices and try them in various contexts. Inspect organizations as a whole and invent new ways to detect problems and solve them on a system level. But what we have at the moment?
There are many topics about Scaled Agile frameworks. I visited several sessions and I have an opinion that speakers have no clue how to really scale agility. Proposed frameworks are kinda prescriptive and heavy. They reminded me RUP-days. You really can create a good framework based on RUP, but there were few successful cases.
SAFe looks complicated and it does not address root problems on my opinion. We need real structural transformations, while SAFe implies specific receipts and says that it will work in almost any context. How is that possible? Everything is context-dependent, and that is why many agile transformation initiatives failed and will fail. People just apply a recipe without deep thinking, ignoring context-specific things and expect it to work. It won’t work in many cases, and you can’t fix it without context-awareness.
SAFe has many good practices inside. It can help companies initially and you will see some tactical success, but I also think that in the long run SAFe is a strategic disaster. It may take 5+ years to feel that, but I don’t believe that company will inject a true agile mindset starting with SAFe. It can happen, but it will be exceptional cases mostly. The really bad thing is that companies will not notice the problem. With waterfall the problem is (now) obvious, while with SAFe they will have an illusion that they are truly agile, while they are not.
So at the end of the day I have a perception that majority of speakers present some abstract theoretical frameworks with extremely poor argumentation. Why this might work? In which context? No clue.
I also wonder why we have no talks about Kanban here? Is Kanban agile or not? Agile community have personal troubles with Kanban approaches? C’mon, folks, this separation is childish.
All that sounds like rants without solutions so far. So I have some actionable proposals for the next Agile Conference. Here is my feedback:
- Add a decent mix of various disciplines. We can learn from complexity science, biology, sociology, sport, physics and other disciplines. Try to intrigue people from these disciplines to really mix their practices with our practices and invent something new finally. At least invite them to speak about things they know to stimulate our imagination and analogy thinking. Invite Dave Snowden, finally, to see his controversial view on scaling. There should be more perspectives. We need greater diversity.
- Have more real-life experience reports with real practices that work in some contextes. It will help to learn from each other and spread good practices. I know many good discussions are firing up between people, but why don’t do that on sessions as well?
- There should be more science. People over the world do great research about group dynamic, development practices, cooperative games, etc. Invite them to share their researches.
- Invite bright business people to talk about marketing, agile workspace, new hiring practices, strategy, etc. It will finally help merge Agile and business together. Nothing is separate. We should see high-level pictures and learn from them.
- 75 minutes talks? Are you kidding me? Nobody can control attention for more than 45 minutes. Split these talks and make workshops longer, since 75 minutes are not enough for a decent workshop. I’d like to see more TED-like talks, short and precise. Experiment with that at least. Inspect and adapt.
In short, Agile Conference demands more inventions, real-life reports, more science and different format. Conference organization is just perfect, it really is. I can’t imagine better. Content, however, is below average, and that is embarrassing for agile-minded community. We can do better.
The final thing is the slogan I saw yesterday. It is just unbearable to me: “Allow agile and waterfall work together” WTF?
I thought we were working on replacing waterfall and change the ways organizations work. Do we, as a community, still think it is a good idea? Or are we starting to agree with a status quo? I believe we are fucking not. There is no limit to perfection.
“Pirates are bold not safe” — These guys are doing something good
How to deliver more value faster? I’m constantly thinking about speed in software development. This article is a result of my thoughts. I built a model that describes all obvious and complex dependencies between software development practices and briefly analysed this model. I hope you will find something new and enjoy the read.
“Every single CEO of any IT company wants to build software faster. Time is the most expensive and valuable resource. You can’t waste it on re-work, refactoring, meetings, physical activities. Right? It depends…”
Read the full article
A simple tale of how we created Targetprocess, the visual project management software.
It all started back in 2004. In those days only a few people in Belarus had heard about agile and almost no one actually used it for their work. Iterative development, what the heck is that? Pair programming? TDD? However, at one local software development company where Eugene and I worked, we had a chance to try Extreme Programming for one of our internal projects. As a side effect we needed a software tool to manage such a project. During that time there were several horrible free tools and a few paid ones that were ridiculously expensive. We thought to ourselves: “Why don’t we make our own XP project management tool?” as many programmers at that time must have. For us, this single question turned into the concept of Targetprocess (the very first name was SWIPE — Sprint Web Integrated Process Environment).
I dedicated last 10 years of my life to a single product: Targetprocess. It’s an agile project management software. Company had its highs and lows, product evolved, goals changed. The hardest problem to me as a Product Owner was features prioritization.
We have thousands of ideas: small and large, good and great. Many of them came from customers, many of them were invented inside a company. I always struggled and rarely felt a deep satisfaction about features order in a backlog: “This feature has so many votes, maybe we should do it first?” and then “But we have a cool vision and people don’t see it so far, we should focus and deliver a set of features that support our vision”. These voices took endless battles inside my head and I was quite unhappy. I just couldn’t decide what argument is the best. Now I know the answer — both.
I think there are two major phases in product development: Innovate and Refine. And you, as a Product Owner, should use different mechanisms to prioritize features in these phases.
Innovate phase is fully dedicated to your vision. You do listen to customers and pay attention to their feedback, but in the end you invent a solution that supports your vision and solves many problems in a new, unexpected way that almost nobody can see so far. Let’s say, you want to mix two domains like Project Management and Information Visualization. Nobody asks for that. When you share your ideas you get positive feedback, but many people still ask about a faster horse. You ignore these requests and move forward with your vision.
In this phase you rely on your intuition more.
Refine phase is completely different. Now you silence your ideas and focus on customers requests. Customers are extremely good at small and moderate improvements. They spot all major problems and give your an honest feedback. Definitely, there is no need to implement every single idea — that is a direct road to hell. If you have a service like UserVoice where customers can vote for ideas, most likely you can safely implement top 5% of requests.
In this case you refine the product and polish it based on customers feedback.
It is clear that these phases demand different prioritization schemes. What work for Innovate phase will not work for Refine phase. That is why I had cognitive dissonance, and it took me 10 years to nail the problem and find a solution.
The solution is to mix these phases, like that
You switch focus every 3 months and it makes prioritization a breeze. Next 3 months we are going to innovate? OK, let’s take these two features that will deepen our vision and differentiate us from competitors even more. Refine phase? OK, let’s take these top ten requests from customers, find solutions, get feedback and implement these solutions.
There is no constant battle between innovation and refinement anymore. You cease to compare oranges with apples. You finally feels confident and calm. And everybody wins.
Existing project management tools have several serious flaws. They hide data inside and give the perception that you are in control. You are not. You don’t see the important things and have to dig through endless lists and reports in order to squeeze out the information you need. When you finally find something, it is not easy to change data you need. You have to navigate away, and visit several screens to achieve what you need. What a pain.
The real problem is that all existing project management tools are bad at information visualization.
Many think that information visualization consists of fancy infographics, dashboards, and reports. That is far from true. There are many definitions, but I like this one:
Information visualization utilizes computer graphics and interaction to assist humans in solving problems. [Purchase et al., 2008, p. 58]
In a nutshell, you should be able to extract the data you want, present it any way you want, and manipulate it right away any way you want.
Problem #1. Find
It is quite easy to add data into software: projects, tasks, people, plans. It is not as easy to get this data back. Quite often you have limited filtering options and can’t narrow down lists, for example, of user stories in order to see just user stories you want. So you have to dig through the list, change pages to find a single story, do something with it, and repeat.
What if you can extract anything without limitations? Zoom and focus on things? Find exactly what you need?
Problem #2. See
Even if you can extract something, you can’t always see information in a way you want. Most tools rely on lists heavily and provide little options to see things better. Lists, some predefined boards, some predefined reports — that is all.
What if you can switch between different representations in a single click? What if you can see information in a one dimensional list, a two dimensional board, or a timeline with a single click?
Problem #3. Change
Even if some tools do provide visualizations, they are static. You can see a report, but can’t do anything with the data. You can see a timeline, but rarely can change it right away.
What if you could see something important and change data right there?
If you take any project management tool, you’ll see that it doesn’t follow information visualization principles. Everything is fragmented. Lists are here, boards are there, timelines are rare and often are not interactive. There are many limitations with finding exact data you need. There are even more limitations with changing data.
Targetprocess 3 was built to solve these problems in the roots in project management domain.
Targetprocess 3 is a tool that has information visualization principles in its core. It removes many of the limitations that other tools have and gives you the freedom to handle data the way you want.
Solution #1. Find
In Targetprocess 3 you can find anything using powerful filters. There is almost zero limitations and you can create very clever filters. When you have no limitations, you can extract exactly what you want and narrow down the data to see.
Solution #2. See
In Targetprocess 3 you can select data and quickly switch between various views in a single click: Boards represent two-dimensional views, Lists show hierarchies and Timelines show progress of things.
You can create any board in a minute: Kanban Board, Task Board, Work by Person, Roadmap and many, many others. The Board UI handles huge data easily via collapsing, focusing and zooming.
Ben Shneiderman stated a Visualization mantra:
Overview first, zoom and filter, then details-on-demand.
Views in Targetprocess take this mantra seriously. You can see the whole picture on board, zoom and filter when you want, and dig into details when you need.
Sometimes you need to work with hierarchical data. For example, product backlog. Lists in Targetprocess 3 are really good at it. You can use filters and flexible settings to see exactly what you need on all levels, update anything in a snap.
Most tools can’t give you a sense of Time. Any data in Targetprocess can be seen on a Timeline. Progress tracking on all levels is a breeze. You can track releases and iterations, see people’s workload, spot long tasks and delays, discover unexpected patterns in your development flow. Moreover, you can create projects portfolios, product roadmaps, plan releases and iterations. Visually.
Solution #3. Change
When you see something, you often want to change that. Targetprocess 3 helps you add entities quickly, select any entities you want and manipulate them via batch drag and drop. Lists provide beautiful experience in adding and editing data. Timelines enable visual manipulations to create roadmaps, plan releases and iterations.
In fact, Targetprocess 3 is a domain-specific visualization software. It focuses on project management domain and provides not static reports, but interactive visualizations. And that makes a big difference. Now information is at your fingertips and you can really find it, see it and change it on the spot.
Targetprocess is free for teams of 5 people. Go see for yourself.
It is really, really hard to design getting started experience in a tool. We’ve had many iterations and improvements, but still are not happy with the current implementation. So we’ve started from scratch and want to improve the existing experience in Targetprocess.
It is always interesting to explore how other vendors solve similar problems. This post is a quick summary of getting started experience in 15 (mostly project management) tools.
Salesforce shows you a Getting Started page with several videos. This is it. Videos are quite lengthy and you have to spend about 30 minutes on watching them. It is interesting that such a sophisticated tool like Salesforce solves getting started problem with videos only.
Trello is a super-lightweight tool for project collaboration. It’s based on an idea to create many boards and manage them. First board is actually a getting started board where you will read about all the features. It cleverly has 3 columns: Basic, Intermediate and Advanced features. If you open all these cards and actually do what they say you have a good understanding of a tool and know how to use it. Great implementation.
Asana is similar to Trello, but much more complex (I personally don’t like it). Getting started experience is more detailed as well. First, you see a short video that actually explains a little. Video is on a separate page and it’s hard to miss it. Then you have a 3-steps wizard to define your identity, invite team members and create a team. It is quite handy and well designed. Finally, you dive into the tool. UI is loaded with many buttons and panels. The only help you have is “Videos” section at the bottom. Still Asana has a style and looks modern.
Plan.io meets you with a wizard that guides you through the system. I liked it initially, but in a minute I got frustrated with too many steps. Then it became really annoying. Huge texts in popovers are not welcome to read, so I skipped them and learnt a little. And “Something is still missing” message drove me nuts in the end.
Clarizen is a feature-rich project management tool. Initial wizard is OK, but I have had some “Hmm…” moments during project type selection. Then you see another wizard that shows you a 6-min video and obvious navigation panel. The tool looks heavy, with many controls and screens. It doesn’t feel hard to grasp though.
Basecamp is a famous light-weight coordination software. It’s very simple. First, you see a bright welcome message. There are similar bright messages in new areas you visit, which is good. Sample project describes real features in Basecamp, so you can explore UI and learn something about the tool at the same time. Interestingly, I like Trello’s implementation of this idea more. Not sure why.
Before you start, you have to lie about your phone number (I’ll never understand why this field is required). Then you see a several steps wizard. While some steps make sense, I don’t think that “Assign task via email” is so important to have here. It is not so clear how to complete this Welcome Quest, I had to think a bit to find out why some steps are still there. Also Skip link is hard to find. Maybe it is intentional, but such solution has its flaws. There are several areas on top and when you put the mouse over an area icon you see a popover with a video. Quite a clever idea, but the implementation is annoying. Maybe it is good to hide these videos at some point.
In this traditional project management tool you see just 2 help messages after login — and this is it. Minimal effort in getting started design. I am not convinced the tool is simple enough to handle the getting started experience that way.
You immediately see a news feed with product updates. Maybe it is better to show a feed with product usage tips. So there is no getting started design at all.
The welcome message you see is irrelevant and too lengthy. Similarly to Trello, there is a ToDo list that describes the tool itself. Empty areas helps you to make a correct action, like add a Task. System shows you good tips in the right moments. I’d say getting started in Redbooth is well-designed and usability is great.
TeamLab looks complex. Right after the registration you see a video and wait while your account is being created. Good use of waiting time! Then you start a project and see three(!) yellow messages right away: one about Android app, another about email activation and the last one is a getting started wizard. Too many for me. The wizard is very short with just four steps. The system gives prompts to some actions when you navigate to a new screen, which is very handy. Help is built-in, so you don’t navigate away when you want to learn something. Quite good.
This is an agile project management software. It meets you with a video (too small) and a project setup wizard. UI is not stylish for sure — too many colors, various icons and overall impression is not great. Large bright buttons with actions in empty areas are good though. The tool was easy to grasp, but I’m a domain expert :)
Jira’s getting started experience is similar to Salesforce — it is very basic. You have a dashboard component with Getting Started steps. Small wizards are nice. Service Desk area is different and shows you quite many popovers. I got lost with them, in fact.
This agile project management tool shows you a 6-step wizard that describes main UI areas. That is it.
Targetprocess is not an easy tool. It is really flexible and has a new UI-paradigm, so we wanted to show people how to use it properly. First, you select a process to start with. Then you see a 3-minute video that explains a concept and main ideas. Then you jump into a wizard. We put significant effort into the wizard and I should say it is the most clever implementation I’ve ever seen. But it seems the wizard is very long with too many actions and steps. We have stats here. Around 70% of people abandon the wizard after step 2. It means 70% of people learn nothing from it. And even the pulsating blue dot doesn’t help to grab their attention.
Let’s summarize the most popular approaches to getting started. Most show a video and provide easy access to more videos about a product (Asana, Yodiz, Targetprocess). Several tools use the tool itself to design ToDo with getting started actions (Trello, Basecamp, Asana, RedBooth). Some tools have UI wizards (TeamPulse, Targetprocess, Clarizen). RedBooth tries to give guidance to users in a good way, I think. Nothing novel, for sure.
I personally think that a long wizard doesn’t work and most people just skip it. Also it is required to unblock as many paths as possible in user interactions. If a tool demands something at some point of time, there should be an obvious way to fulfil that demand. For example, if it’s not possible to add a user story without a project, there should be a clear way to add a new project right from the “Add user story” screen.
Today I want to discuss a topic, that many of us thought about for sure. I want to talk about interest and fun at work.
An Interesting Task
What does “interesting” task mean? People are different and interesting tasks are different, but it is possible to define some common properties. Maybe you can provide many properties, but I think only two are particularly important.
An interesting task is usually challenging. It is close to the edge of your skills. You feel that you can crack it, but don’t know how exactly so far.
An interesting task should give you a new knowledge. If you solve the problem and learn nothing, it doesn’t feel very cool. When you solve the problem and learn some new concepts, then you feel much better in the end.
So interesting task is challenging and generates knowledge.
However, there is another thing — developer’s experience.
They almost always work on interesting tasks. Any task provides some challenge, any task generates new knowledge.
Initial enthusiasm is gone and now it is a serious job with less and less fun. If the fun level drops below a certain edge, you are in trouble. It means you learn nothing. If you learn nothing, you will become a “zombie developer” eventually. A zombie developer goes to work and solves similar problems again and again.
No real thinking, no real challenges, more brainless activities like meetings, small talks (not the language), status reporting, hacker news, Facebook, Twitter, chats, death. True zombies don’t like interesting tasks. They like familiar tasks that demand minimal effort to complete. They work on the lowest energetic level possible.
The day when you say to yourself “I didn’t do any interesting task for weeks” should rise a red flag in your head. Go and fix that. Talk to managers, change position, change a company. There should always be a healthy mix of interesting and familiar tasks. Fight for that.
After 10 years of professional programming they accumulated a good backpack of knowledge, experience and sarcasm. There are not so many tasks they find interesting anymore.
Some give up and just do their job. They say: “We are professionals and solve problems not for fun, but for the value to the people. That’s what we do”. They try to re-frame a problem and replace a real solution with psychological one. Sometimes that works, but often not so well. These people are unhappy. They do the job well, but you should not expect any enthusiasm, initiative and courage. Create one more 3-layers enterprise solution? OK. Build another one social network? OK. Zombie Developer Level 80.
Some try to find a way to the mastery, solving the same problems better and better. For example, writing compilers for 20 years. It is an honourable road only a few can ride. You should be very determined, patient and calm. These qualities are rare in the Western culture.
Some push forward to the limit to work on really challenging problems. They change jobs, change countries, change industries and technologies. They jump from problem to problem, developing astonishingly wide skill sets. Definitely, they don’t have depth in all the areas, but they do provide unusual point of views and can attack problems from surprising angles.
Any good company should provide enough interesting tasks. It is a serious mistake to believe that people will do everything with equal passion. They can, but only if the balance of interesting/boring tasks is good enough.
Most likely, every company should have people with all levels of experience. Junior developers will be happy to work on tasks that veterans treat as trivial. Experienced developers will be happy to work on tasks that veterans treat as OK. And you need veterans to storm really challenging problems (if you have any).
I personally thought that junior developers were not required in our company. I was wrong. It leads to a situation when veterans have to work on simple and trivial tasks more and more often. Fun level drops. Productivity drops. Danger to lose veterans increases.
Which distribution of junior, experienced and veteran developers a company should have? It depends on problems you have. There are 25 developers in our company: 19 experienced and 6 veterans. So our current distribution is 0-75-25%. I think a more healthy distribution would be 25-50-25%. What we are going to do is to hire 6 junior developers to have 20-60-20% distribution so far.
Here is the distribution for various types of companies. X – developers expertise, Y – % of developers in a company:
As you see, currently Targetprocess team is skewed into the “scientific projects” type, while it is certainly not scientific so far. We should move back into the product development distribution.
- Almost every task is interesting for junior developers.
- Experienced developers should maintain a healthy balance between interesting and OK tasks.
- Veterans have two viable roads: sharpen their limited set of skills to the mastery or attack new problems all the time and become a smart generalist.
- Company should care about “fun level” and have the experience distribution that fits existing problems.
Routine Pros and Passion Cons
Continuous Problem-Solving Is No Accident
Cognitive Endurance Basics for Software Developers