Why we ditched Scrum, in favor of Kanban in JIRA

Warning: don’t misinterpret scrum for agile as a whole 🙂

Around a year ago I wrote a yearly retrospect on how the workflow at SkuVault is organized, and how we set up our jira boards to work in sprints.

sprints and their goals

There was no Kanban backlog at the moment, and we used Scrum board as an improvized scrumban tool: we had the sprints, which were treated as folders to fit tickets in some time period. Classical sprints were not suitable for our workflow, I mentioned the reasons in Year Retrospective @ SkuVault. So that sprint-folder system was great, visible and allowed us to predict.

2017-07-16 21.39.59

Yet, in a year period the signal that our approach (sprints as folders) doesn’t quite work appeared – there was a number of tickets migrating from sprint to sprint being rescheduled over and over.

Allow me to add a small note here on SkuVault specifics: There are different categories of work, and planning a common roadmap doesn’t quite work either: we get different priorities from different departments (QA, Product Management, Services and Angry Clients, Services and Happy and Willing to Pay clients) – so the urgent ticket scope inflates. Urgent tickets may require distraction of a developer working on some client request, which shifts the timeline for delivery. So, in a nutshell: there is no unified roadmap between different categories or depts – there is a near-term plan only, with each category having it’s own stack of priorities. Now add to this a remote team that works in collaboration across atlantic and with the timezone difference of 9-10 hours 🙂

worldmap
SkuVault is a distributed team of awesome people, spreading across 9 timezones, or sometimes more. Notice how pathetic I am when it comes to image editing. Those are not cute animals – those are coat of arms symbols, lol 🙂

So a question is: how to remodel the workflow to reflect the specifics?

Buckets and Kanban

We came up with the idea of buckets: basically those are categories of work, originating from different departments with separate product owner responsible for stack of priorities.

Last year Atlassian finally realised the scenarios teams use their product for. So, Backlog for Kanban was born out of desperate cry of thousands of PMs, Teamleads and other people who cannot develop themselves and just drag and drop tickets on the boards (/sarcasm).

The feature came out quite handy and we were able to merge our workflow with our development process IRL.

kanban_backlog_glory
Finally, there’s an option to see upcoming backlog you can both groom and plan inside, and drag that to ToDo as the near-term goals! Don’t forget to estimate that properly 😉

Backlog Kanban allowed us to re-evaluate a lot of backburners that were hanging out there, never getting into the sprints. It also gives us a cleaner board – cause you can store current workload apart from near-term plans, yet in the same board. It’s something you already get with scrum boards, just without sprint management.

Current State

We attacked backburners and development scope from two fronts:

  1. created a separate IDEAS project, where tickets were getting fully fleshed out prior to development;
  2. moved all of the backlog tickets that were on the shelf in development projects back to the IDEAS, to re-evaluate;

This + we’ve added Buckets System, with the support of limited number of devs in the pool for each bucket. I’ll try to write a separate post on how Buckets work in our company later (spoiler alert: they work only as indicators of ticket origins, otherwise – they are kind of not really helping, as of the current state, after some teams shuffling 🙂

Boards, Workflows, and two Backlogs

We’ve got two workflows – one for preparing the ticket for ready-to-be-developed state, the second is for development itself.

Each workflow has it’s own board – as you know, boards are the best ever unicorn rainbow tool to show state of the project from a particular angle.

So two boards reflect those workflows.

IDEAS Board

(Also called pre-development), managed by Product Management. Includes it’s own backlog for backburners, that we put in the shelf for some time (or close to forever); Sign Off, Detalization and Formalization, Architecture Review and finally Ready to Schedule states. Each step has a description and a format of how it should look.

pre-dev-workflow

The point of this board is to reflect status of every single idea that we decided to evolve into a feature, and to see the bottlenecks in Product Management workflow.

pre-development board
Ticket on the right is not violet – it’s just blocker by another Core task
PDM Workflow

Establishing that IDEAS board was also a result of creating full Workflow for Product Management, without letting the ticket out of the IDEAS project and into main SkuVault development project, until all the details and edge cases are fleshed out (well, you caught me – there is no chance you get all 100% of edge cases, but you should try as hard as you can).

By creating standards for each step of formalizing the ticket, we’ve ensured the consistent quality of ready-for-development tickets, which ensured that they won’t be put on hold until clarification from API partner / Client / Product Management. You don’t get big stream of tasks pouring into development, but the quality of such tickets lets developers be distracted less and be more motivated, because who wants to switch context and work on something unfinished.

Development Board

As I pointed out in previous posts – development board is pretty much untouched -> if it works, don’t break it 🙂

SkuVault v1.7 - JIRA 2016-06-08 15-12-47

But the utilization of Kanban Backlog in JIRA came quite handy for both of the boards: you are able to have a set of tickets in the backburner, still in same project, but not wasting ginormous amounts of space on the board -> you just access all backlog via a special planning view.

backlog_predev
Pre-Development Board Backlog

While IDEAS board has a backlog with things, that should sit on the shelf for some time, Development board utilizes kanban backlog in a slightly different manner: I store optimization tickets that we need to check every couple of weeks / months there; as well as User Stories for Epics, that are still in IDEAS, that we didn’t get into development yet; or it’s a very handy way to form a pool of tasks for upcoming developers.

kanban_backlog_glory
Development Board  – Backlog. Two Magento versions support is on hold -> we’ll reevaluate them in the coming months – they’re waiting for their turn.

 

JIRA also support swimlanes for boards, which is utilizied by us in a manner of separating projects one from other:

development board
Three projects in Progress for Shawn -> Lots, QC Improvements, Shipments. The higher the project’s swimlane – the higher it’s priority.

..in a nutshell

  • We’ve ditched sprints, in favor of Kanban. It’s much easier to not pointlessly drag and drop tickets from one sprint to another, if they’re not ready. As I wrote, Urgent tasks needing on call devs contradicts with uninterrupted scrum approach for developing concrete chunks of functionality in a given timebox (mind the fact that scrum and agile as a whole deals with deadlines badly, while we have deadlines most of the time);
  • Kanban gave us differentiation by projects on one board, without making the board too crowded. Scrum boards give that too, but count the hassle of moving unfinished tickets from one sprint to another, which doubles the maintenance work;
  • Kanban Backlog is a great feature, allowing us to manage all tickets in the project. We could have done this in two boards (one for new tickets to be moved to agenda or closed, and another for development / formalization itself) – but now we can manage all tickets in one. Neat.
  • We had an Urgent Board (Kanban Workflow), and Development in Sprints (Scrum) -> now that we moved Development itself to Kanban, we were able to unify the boards, and everything, from minor to blocker tasks, is visible on the same Board! This is great!
  • Never use scrum rituals just for the sake of rituals. We didn’t use sprints for the sake of sprints, we approached sprints as folders and timeboxes. However it’s a common mistake, while management or teams create a cargo-cult for scrum. Most likely you’ll use different practices and methodologies over the time, and finally will come to a hybrid approach that makes you efficient.
  • There are different companies, and certainly there’s no silver workflow bullet for all. So given the maturity / infrastructure / tech. stack / staff – you should model the workflow related and reflecting the flows inside that particular company. SkuVault is changing, growing, scaling – and so is the workflow. Different depts can have different workflows – and we reflect that.

Communication in distributed teams: Messenger & Rules

In order for the distrubited teams to work, you got to have a clear flow, a set of general rules, that will fence the process and allow people to collaborate effectively around the globe. If everything is set up correctly, you are able to create amazing products with global professionals, and cover customer support 20+ hours a day.

Communication

What do you miss most when working outside of the office? Procrastination!

Communication that is effortless in office envoronment may be not as natural in distributed teams.

Messenger (SkuVault uses Telegram, chosen for it’s simplicity, availability across all platforms, stability gorgeous GIF bot) and videochat software are there to try to equally substitute verbal communication.

Due to project specifics, we have the following channels in telegram:

  • Urgent chat, where On Call & Quality Assurance teams collaborate in order to resolve outstanding issues as fast as possible (you can read more about On Duty teams in my previous post on year retrospective);
  • Dev chat, that is general for all devs, covering the questions of “Who the hell broke QA again?”, …, to “So have you seen Azure copied Amazon pricing plan”.
  • Russian Dev chat, due to significant part of the team being russian-speaking, is for fast communication and clarification across russian devs;
  • Quality Assurance chat, for questions and discussions across QA members;
  • Freshdesk feed, for fetching freshly issues support tickets, so that if immediate attention needed -> relevant people are informed;
  • separate project chats with various messaging activity, depending on how big and urgent the project is.

Telegram

Telegram is extremely handy when it comes to making life easier. We use:

  • hashtags, to mark needed messages in order to find them later. That could be #shipstation hashtag to mark everything related to ShipStation integration across all chats;
  • mentions, which allow to ping a person even if the chat is muted. So if dev doesn’t want to get tons of messages on a related subject, he still is notified when he’s mentioned;
  • great gif support (not only kittehs, but also when you need gif with reproduced bug);
  • bots! we fetch freshdesk support tickets, notified about engine and web errors thanks to telegram bot api 🙂
  • size, platform availability, stickers, e.t.c.

now this sounds like a telegram evangelism

Video Conference

When it comes to video conferencing, we use hangouts, since skype app is awful.

General Flow and Jira Ticket Descriptions

It’s bad when you lack information on stuff you need to implement. In order to minize that, we have rules on filling out the ticket, so that as less questions as possible are raised.

Ticket description has testing plan, implementation plan, sequence of steps on how the feature should work, client and needed sandbox credentials, and tons of other information. Now that doesn’t prevent requirements change, scope creeps, blind spots (we all know that software development is an endless pain and all related people should suffer), but it surely reduces questions to clarify / misunderstanding / delays to the bare minimum and greatly helps in communication.

General Flow for the ticket before it hits implementation requires it’s acceptance by PM and dev, so those are members who control whether ticket is clear enough or not.

Workplace Attendance

Although you are not obliged to come to the office, it’s still essential to be at your workplace during working hours. If you’re working flexible hours, you need to agree upon them with a manager or people you collaborate with, so that you have a consensus solution on comfortable time to work for all.

Calendar lists days off, while chatrooms are good to inform colleagues about hours off, if necessary.

Working remote takes self-dicipline and responsibility, but pays off really great.

Notifications for pinging stuck projects

Be sure you use various notifications, such as jira web hooks + telegram, email notifications on stuck code review or testing, color coding on project management boards for due dates and approaching deadlines. Alltogether, those measures prevent unexpected situations and make the risk of missing deadlines, reduces the risk of tickets stuck halfway, keeps you alarmed in almost all cases where the flow takes wrong direction.

Project Management & Business Analysis Meetup – Ufa

So it happened – I managed to gather 2 people for PM & BA meetup (without any PR xD).

After visiting Vienna, I desperately wanted a platform to share knowledge or / and mock each other on PM & BA failures. So I created one:  Ufa Project Management & Business Analysis Group 

Initial meeting consisted of Me, Nur (from modulbank.ru – online bank for small businesses) and Oleg (from smena.io – various crms / solutions for partners). Both work as analysts at cool and interesting teams.

So thank you, @Nur and @Oleg 🙂 First meeting went nicely, at my favourite coffe place Chat House. Meetup went as expected: we’ve shared experience and discussed who works via which workflow, how we formalize requirements and what are the places we store them.

I miss good ole Ufa42 Conference, I think we gotta revive it 🙂

Year Retrospective @ SkuVault

Last year guys from SkuVault offered me an amazing opportunity to help the company manage a growing development team, create organized schedule, establish workflow that reflects the company goals .

For those who don’t know – SkuVault is a Warehouse Management System (WMS). Like a swiss army knife, SkuVault manages and syncs your inventory across e-Commerce platforms, POS, Logistics and Warehouses, providing accurate quantities in order to prevent out of stocks. Headquartered in Louisville, KY – SkuVault helps to manage the inventory for hundreds of clients all across the globe.

2540ridgemar

It’s time to list some of the achievements we accomplished during this year.

Observational Research and Optimization Scenarios

For the first 2 weeks, I was examining the flow within the project, and getting to know the team. Each couple of days I published blog posts on my findings with ideas on how to improve and optimize the workflow. Some things in my new team were completely different from my previous experience:

  • No teamleads. That meant that developers split up into Code Review teams, and reviewed each other.
  • Technology stack (.NET at SkuVault vs Scala / Riak / react.js at Storia). With all the pros and cons, .NET development teams don’t have that clear BE / FE differentiation: backend developers can work on frontend tasks via ASP.NET MVC, so our devs are more like (..universal soldiers).
  • No UX / UI design step in the workflow. This particular part makes every decision much faster. The product itself (SkuVault Warehouse Management App) uses Bootstrap, and is very utilitarian from design perspective. Key factor here is ease of use (as much as it can relate to industrial application).
  • Distributed team on both sides of the Atlantic, covering almost 24 hour period.
  • SkuVault is used by hundreds of customers around the world, bugfixing happens daily, and there are different bug priorities. This particular moment doesn’t work well with typical “sprint->release” cycles (because the priorities may change quite fast, or something needs to be urgently released).

With all those differences in mind, I started to streamline the workflow in JIRA.

Statuses, Transitions, Workflow

I managed to decrease the number of statuses.

  • Used to be: 23 (with any transitions allowed between any statuses)

shawshank_redemption

  • Became: 9 (with clear status sequence that reflects state of a bug / new feature).

SkuVault v1.7 - JIRA 2016-06-08 15-12-47

Most statuses were redundant, I’ve changed some of them with combination of “labels + status”, some were eliminated and substituted by generalized statuses (for example statuses “Design Holds”, “Client Clarification” changed to status: Hold + label “IncompleteDescription”).

The Workflow is constantly being refactored and improved per developers’ suggestions and whole team feedback. Last week I’ve released the 7th version of the workflow in a year.

Flow in general, and for every team member (BA / PM / Dev / QA) is described in our wiki, as well as terminology, list of labels to apply (there is a special glossary for labels). I explain the workflow as a sequence of steps, so that there is an instruction in case of emergency, or a new person onboarding.

On Duty Teams

During the first week we started to ask developers to fill a small questionnaire to find out how often they are distracted from new feature development by urgent client requests or bugfixes requiring immediate attention. It turned out that significant time (up to 80%) had been taken by Urgent Tasks, which distracted devs and made their work less efficient.

So the management team (well, actually it’s more like PMs, CEO, CTO and Support Lead) decided to establish teams of on call devs. These teams (2 devs: Frontend and Backend) would work only on urgent tickets, which allowed the rest of the team to work on regular tasks, ideally, without distraction.

On duty team concept has been rethought a couple of times, and currently we’re aiming at having 3 devs on call each shift, as client base grew significantly, and so have the requests, tasks and points of attention. Some of developers still get pulled to urgent tasks, because SkuVault heavily relies on integrations with other SaaS / eCommerce / Shipping systems, that change their APIs, improve their products, and may occasionally alter the way they interact with our system. And on duty devs may have questions for the developer who built the integration originally.

However, the concept itself proved to be extremely helpful, and overall the issue is resolved.

Mentorship

It’s a common thing to establish, when you have senior and junior devs 🙂 In order to clarify overall system architecture questions, seniors mentor other developers and code review.

Ticket Description Standards

Creating a clear guidance on filling out the fields and required info on a bug / new feature / or any other issue type is essential to streamline development.

Rules: Filling out ticket fields in JIRA - Project Management (SV) - Agile Harbor IKB 2016-06-17 12-01-08

Changing Kanban approach to Hybrid Scrumban

In a nutshell, a year ago development boards (one for planning, one for development) included lots of statuses, was extremely heavy (as you gotta display ~1k tickets), and hard to manage. Kudos to Tim Jannace and the team , who managed to bravely (and successfully) operate and maintain this board!

However, an agile board should focus on one goal: to show a piece of flow relevant for particular scenario / area. So those two boards were split up, so that each board reflects a single scenario:

  • Development Board, where the tickets transition from ToDo to Ready to Release: Scrum Board;
  • Urgent Board, which is used by on duty teams, and includes only Critical and Blocker tickets: Kanban Board;
  • Quality Control Board, where developers and test managers can to see the scope of tickets they need to review: Kanban Board;
  • Release Board, for the release manager to overview and manage the tickets that should be merged to master: Kanban Board.

There are boards for DevOps tasks, of course, as well as for other projects, but developers mostly have to check 2 boards maximum. And both of the boards are easy to use and lightweight.

On the other hand, pure sprint -> release cycles do not reflect how SkuVault operates, because of the Urgent bits that need to be released almost daily. So sprints are more like folders here, which allow us to forecast approximate or particular start / release dates for the tickets, and limit feature scope in a given time period. That’s why it’s called ScrumBan 🙂

Notifications, Due Dates, etc

I’ve also established automated email notifications on Pull Requests or Tasks are not Reviewed / Tested for more than 2 days.

We started to use labels trigger notifications for tickets that will soon miss due date, or for ones that shouldn’t be rescheduled.

There are a lot of other specifics, changes, undergoing improvements – over the year team grew significantly, as well as number of clients – and we adjust the company flows accordingly. Developers look motivated, and I couldn’t be happier to work in such an environment.

Key findings this year:

  • Don’t make a release the goal itself. Quality product is the goal. So you can skip a release or two, but deliver something good. Even if there are lots of clients,they would understand the importance of stability, not the feature they want firsthand;
  • Write up retrospectives on problematic moments, so that you solidify foundation of your experience for yourself and others. Try to gather additional data and opinions inside the team, in order to provide a broader angle to the problem;
  • Make everything possible to have a good human relationship with developers and other team members. You are colleagues, and a good person will always try to do her best, if she’s motivated (see motivation reference article);
  • Horizontal hierarchy and a little bit of dev anarchy is always good. Every team member should have his voice at least heard;
  • Always update team feedback on how things are, this is essential to keep the flow up to date and address concerns that devs may have. Cause you know, in IT, team is what defines success, and good manager’s work is to facilitate work and motivate the people;
  • Maintain comfortable release pace for the team and the clients;
  • Read professional literature, but don’t forget to check how this works in reality 🙂
  • There is always room for optimization. You just don’t have enough time! You can spend days micromanaging things, to extrapolate optimization on global flow later. Neverending exciting job.
  • Maintain work/ life balance. Don’t let team overwork.

Aside of your professionalism, key things to stay motivated are team spirit and ability to apply and improve your skills. For the past year we became mature, overcame challenges, and continue to create awesome WMS for our clients. Looking forward for the next adventurous year at SkuVault 🙂

Thanks to Ksenia, Slav and Kim for the review, and SkuVault team for the support.

Tuning up Scrum Approach

IMG_2016-06-17 13:21:33

Recently my colleague, Tim, decided to try out Planning Poker, to have better estimations. Planning is essential, and scrum already offers a framework of how to deal with planning. But over the course of my work and experience with scrum techniques, team usually shapes

Previous experience showed that daily scrum meetings are merely pointless. Direct communication / skype / IM is much more efficient. Especially in distributes teams.

And following each and every ritual from scrum routine is time and efficiency consuming during the first iterations, since agile methodologies need a good deal of instructions. Usually, after some time teams shape up scrum as they want, and it just works, so from my experience it’s not essential to follow scrum by the book (Agile Estimating and Planning book by Mike Cohn, written 10 years ago). Here are additional thoughts on why our transatlantic distributed team doesn’t fully fit into planning classic scrum and it’s rituals:

  • Due to out product having two versions, we sometimes have developers jumping in and out of projects;
  • Since we’re distributed and flexible – it’s hard to incorporate planning poker with all it’s “team that takes the hint” practice. Distributed team of two-three people can handle classic scrum, but not bigger one.
  • In order for classic scrum to work, team must be onsite (together in one place), and everyone should be in one timezone. That’s not our key point, we’re strong in our flexibility, adapting to challenges and different projects. Scrum meetings are not that effective, when one part of the team has finished work day, and the second one only starts with the fresh brains (smile)

Story Points vs Ideal Days and time estimates

  1. Story Points are valuable when it comes to relative complexity (e.g. that task is twice more complex as this one), and when the team has sort of fog of war before them. However, when elaborating on stats from burndown chart and calculating Focus Factor, we go to the point of calculating how many points / ideal days of uninterrupted development do we need. All because we need to know how to squeeze features into sprint timebox.
  2. If you work with JIRA
    1. Story Points are not as comfortable to work with, as Original Estimate field. Subtask story points do not sum up in parent ticket, unlike original estimates.
    2. Story Points lack ‘remaining story points’ bit, which is uncomfortable once user story has spilled over to the next sprint. Original Estimate, in this case, can be complimented with Remaining Estimate field.
  3. It’s not convenient to estimate buffers for unplanned work with Story Points.
  4. At the end of the day, Story Points are calculated to that very same hours developers spends effectively inside a timebox. Do we need an additional layer of calculations, if it will eventually come to measuring time?

Planning Poker

Planning poker is a ritual before the sprint, where the team (devs, qa) estimates upcoming user stories by a consensus-estimate (average estimate of all team members), assigns user stories to developers, and discusses possible roadblocks collectively.

Don’t have anything against that, but it often comes out time consuming (not that critical as it sounds, actually), and shows lack of detail from other estimators. Moreover, planning poker usually means that devs themselves think about which ticket is to take, which is quite hard to do when we have such a vast scope (~1300 tickets in backlog) + ~2 sprints planned ahead.

But let’s omit devs and tickets self-assignment and time consumption. That’s all tunable.

There are online tools for planning poker:

Estimations and Forecasting

Man Day !=  Calendar Day, because developer gets distracted during man day. So none of these terms reflect what we need.

Story Point is too abstract. Let’s use Ideal Day term, meaning 6 hours of undistracted work.

Key questions to answer when making a good plan (cynical comment: plan is worthless, planning is essential, as Napoleon said) are the following:

  1. How many ideal days on average are in sprint.
  2. How many ideal days can certain developer actually works per sprint.

Once again, Ideal days != calendar days.

Buffers and Planned Days

While starting to estimate and plan back in August, I started by making buffer of 0.5 day, thus making development occupy other 4.5 days in the sprint.

Currently it’s 1.5 days buffer, and 3.5 days of development. This may not be enough, as I’m continuing to tune and gather stats on that. I think that somewhere closer to 3 days is tolerable.

MONTH

TIME BUFFER / SPRINT

PLANNED DAYS

August 0.5 4.5
September 1 4
October 1 4
November 1.5 3.5
December 1.5-2 3-3.5
  • I’m aiming at 3 days of development for devs, and 2 days for code review / scope creeps / finishing up tickets that are reopened;
  • Time buffer includes time for Code Review, fixing Reopened Tickets, other distractions;
  • Planned Days = Ticket Estimated in Ideal Days multiplied by Complexity Multiplicator.

Such empiric way is basically the same focus factor scrum is offering, but without a layer of story points that you later need to convert. And btw, it falls into same ratio I had during previous two projects, which is 2/3 development, 1/3 buffer for fixes and everything else. Seems like more or less ratio across projects then.

Complexity Multiplicator

Plus we have complexity factor, which helps to form buffers. Complexity multiplicator is a combination complexity and unknown unknown. 3 ticket complexity levels:

  • easy <x1.2>
  • moderate <x1.5>
  • complex <x2>

The common equation for one person will look like:

Sprint = SUM(User Story x Complexity Factor) + Time Buffer
5 days = SUM(User Story 1 x Complexity Factor; User Story 2 x Complexity Factor) + 1.5

Individual numbers differ among developers.

All in all, these are estimation basics. Questions asked will add up to this post. Meanwhile, some literature to read:

resized_high-expectations-asian-father-meme-generator-you-are-scrum-master-why-not-scrum-phd-f56adf

I’m not telling pages behind those links are true / correct, but they are certainly allow to overview issues from different angles.

Manage process, not people

It’s all about the process

I might be a captain obvious here, but supporting a process for an analyst / pm is a more important, than micromanaging tasks amongst developer pool.

When a new team member steps in, who’s responsibility is to manage development processes, she needs to find how to make business processes inside a company better.

Business processes are evaluated from various points of view, but in a nutshell, aside from developer professionalism, she needs to make sure there’s no room for slowdowns and uncertanties when product passes different stages across different teams. Whether there are delays in communication, or delays of resources for the project, or sick-days, – there should be a correct process to tackle such cases, in order to minimize negative outcome.

There’s always a temptation to micromanage issues, no matter how big the project is and how little time you have. But project manager’s job is to create a process that allows to handle various situations. Once the process has been established – keep an eye on the workflow, so that it doesn’t jump over the fence of how the process should work.

Fencing is the key idea. Micromanagement is bad, if you don’t have a clear process: it’s time consuming, it’s inefficient on a project scale (of course there are exceptions), and most important – micromanagement doesn’t cope with scaling.

So the typical steps to establish a working mechanism is to:

  1. Create the process
  2. Adjust it to keep all needed operations inside that process fence
  3. Make sure operations can connect to each other via unified inputs and outputs
  4. Optimize the process to allow painless scaling
  5. Do not pay too much attention to micromanagement 🙂

Team Spirit + Exciting Project = Good Product (and vice versa)

lego-teamwork

Product is crafted by people. It is not a sum of collaborative work. It’s usually a combination of work, excitement, collaborative ideas, feedback loop inside the team throughout the whole project lifecycle.

Passion is right at the heart of every person, and if environment tends to motivate – a person will work hard to achieve a good result (appreciated by the team and himself). Moreover, working with passionate team amplifies the overall product, makes it bigger than sum of efforts.

I approach to motivation as to a three-factor equation.

  • Excitement about the project (and willingness to work on it)
  • Ability to apply your skills (and improve them)
  • Compensational part

Let’s leave out compensational part. Let’s also make a note, that such approach doesn’t work on lousy boring projects.

The rest two points are extremely transparent, if you work in a smaller companies with more or less ‘flat’ hierarchy and informal communication.

Excitement about the project comes from inspiration. It could be something cool, that brings value to the market. Aspirational team, that challenges you, while you challenge them. This makes it extremely easy to go & do your job day by day. Such teams later stick together, even working on different products, to exchange ideas and share experience (as we did with Ufa42 Conference).

MhWNOxz

Once the project is exciting, challenging – person starts to work hard in order to bring his valuable contribution. Developer, manager, designer, analyst – everyone is involved into general decisions, everyone is able to improve the product from the inside. Which means he can apply his skills in a good way, practice fresh approaches and technics, learn on mistakes, tune the workflow.

However, lack of involvement in product creation (aside from simply doing your job), vertical hierarchy and formal chain of command – it all kills the motivation. This brings us back to our equation: team is unhappy, not motivated = product not exciting. World doesn’t need boring products. Don’t forget: awesome pros won’t stick with something dull for a long time, they will leave as soon as they can. And we all know, that finding great teams is something almost impossible 🙂