Kanban Management Professional (KMP) is a two-day class and is designed for managers (technical or non-technical) as well as individual contributors and anyone wanting to continuously improve his or her organization to reach outcomes and capabilities such as:

• Relief your organization from overburdening
• Increase transparency, Trust and work satisfaction.
• More Satisfied Customer and Employees
• Improved and more Predictable Service Delivery
• Higher enterprise and business agility
• Improved workforce flexibility
• More organizational congruence

Kanban Management Professional (KMP) follows the Kanban System Design (KSD) class; which is a 2-day class designed to teach participants:

• The core practices and principles of Kanban Method,
• Foundations of service design and service management;
• Practical, actionable and evidence-based guidance on how to use Kanban to catalyze improvement with minimum resistance to change.

Equipped with this guidance from KSD and KMP classes, you will be able to reach all the outcomes mentioned above and more. After KSD and KMP classes

• You will become a better manager,
• and if you are an individual contributor, you will be able to influence your organization with ease to continuously make it a better place.

Learning Outcomes

KMPs know how to streamline upstream and downstream flows of work, manage knowledge work more efficiently, improve service delivery, and create greater customer satisfaction.

Here are some of the outcomes and objectives of KMP class:

• Dive deeper into the evolutionary change management principles, and use them effectively to manage resistance to change.
• Use Kanban method to manage work across your enterprise. Horizontally, between service providers; Vertically at different levels of the organization — from strategy to individual deliverables.
• Explore the depth of Kanban general practices, and apply them to manage end-to-end service delivery — from customer needs at upstream to needs met at downstream.
• Design Kanban Cadences and Feedback loops for one or multi-services to create centralized coordination and decentralized control.
• Use strategies such as Shaping Demand, Risk-based Replenishment, Blocker Clustering, Disruption and Dependency Handling, Constraint Management to improve Service capability.
• Use distribution and Weibull shapes to analyze service delivery characteristics, and make a better risk management decision.

Who Should Attend?

Kanban method is for all people who are in the knowledge and creative work domain and in the service business. Especially those who manage these businesses.

Managers: C-Level executives, Directors, Business Unit Managers, People Managers, Service Delivery Managers, Technical Directors, Heads of PMO, Heads of Product.

Individual Contributors: Software Engineers, QA Specialists, Release Managers, Project Managers, Portfolio or Program Managers, Project Governance auditors and process engineers, Scrum Masters, Agile Coaches, Product Owners, Product Managers.

What does happen in those two days?

Both days consist largely of interactive group exercises, games, and simulations. They are designed in a way that you can put what you learn in use immediately after the class.

Day 1:

• Why the Kanban method? (the motivation)
• Basic Approaches to Kanban
• Evolutionary Change (An Enterprise-level Case Study)
• Handling emotional objection to WIP Limit
• The Kanban method and its value System
• Kanban for the Enterprise: Service Orientation, Scaling and Upstream
• Are customers satisfied? Are we improving the right thing?
• Doing the right thing, Working on the right thing, making things better (Feedback loops)
• Commitment and replenishment in-depth

Day 2:

• Communication flow for business agility
• Implementing organizational feedback loops with Kanban cadences, such as service delivery reviews, operation reviews, and risk reviews
• Managing sources of delay caused dependencies and variability
• Models for improvement: measuring performance, disruption and dependencies, bottlenecks, overhead and inefficiencies
• Managing Evolutionary Change

Kanban Management Credentials (KMP)

You will need to complete both KSD and KMP classes to gain Kanban Management Professional Credential. A globally recognized certification from Kanban University.

The Kanban Management Professional credential confirms you have had top quality Kanban training to design Kanban systems and use Kanban method body of knowledge at scale across the organization. Vertically at different levels; and Horizontally across teams, departments, and units; while continuously improving and advancing in the usage of practices, and principles. Doing this will also make a long-lasting impact on your organizational culture for good.

Check Class schedules here: https://www.learnkanban.cz/public-course-schedules

The book basically talks about what a product and service is made up of, how customers measure the product or service and what metrics company managers must apply at different levels to be always fit for customer purpose (the Why’s of the customer). If I want to summarise the book in one statement, it would be like: Align your business to how your customers measure your product and service.

When I was reading the chapters, four guys came to my mind: Peter Drucker, Jack Trout, Eliyahu M. Goldratt and Clayton Christenson.

The book reminded me of Peter Drucker; because he once made a profound observation that has been forgotten by many, his observation goes like this: “Because the purpose of business is to create a customer, the business enterprise has two — and only two — basic functions: marketing and innovation. Marketing and innovation produce results; all the rest are costs. Marketing is the distinguishing, unique function of the business.” F4P gives you the tools to not only identify your “right” customer, but also it helps you to innovate through insights you gather from those customers.

Jack Trout; because he was for me the master of marketing strategy and positioning. I learned a lot from him and his writings. His work is very much centered around customer perception (how and what customers think and believe about your product, service and brand), and how you can change that perception by applying different strategies, and how you can position yourself at the right spot in the customer’s mind so you maintain your differentiation. According to Jack Trout, To survive one has to find inspiration down at the front, in the ebb and flow of the great marketing battles taking place in the mind of the prospect. F4P emphasises on working with your frontline employees to gather insight so you keep your business fit for purpose at all times, or in other words maintain your positioning. F4P gives you the tools and techniques to do exactly that.

Eliyahu M. Goldratt; because he once wrote “Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way… do not complain about illogical behaviour …” How to discover the right metrics, how to use them across your organisation and between business units and department (or services) is in my opinion the most powerful idea of the David’s and Alexie’s book. And it all starts from how customers measure you and how that should be linked to all other metrics in the organisation. F4P shows you how to define right metrics, how to link them, and how to transition from one to another at the right time. This single technique can have huge impact on your business. (I will go in more details later in this post)

Finally it reminded me of Clayton Christenson, because the customer purpose is very much similar to Customer’s Job. He once wrote: “ Most companies segment their markets by customer demographics or product characteristics and differentiate their offerings by adding features and functions. But the consumer has a different view of the marketplace. He simply has a job to be done and is seeking to “hire” the best product or service to do it. Marketers must adopt that perspective. “ F4P Framework helps you segment your customers based on purposes and needs and connects that to the rest of your activties in the organisation.

It is important to mention that, Outcome based driven innovation of Tony Ulwick reminded me of Fitness Criteria from F4P Framework, Where you quantify customers’ needs and use it as your performance metric, or as Alexie and David suggest your KEY performance indicators.

What you do not find in Peter Drucker’s, Jack Trout’s, Eliyahu M. Goldratt’s, Clayton Christenson’s and Tony Ulwick’s materials is a practical evidence based approach on how to find the right and key metrics for your organisation, how to measure and monitor them, how to connect them to other metrics in your organisation, how to use those metrics to change behaviour and cause improvement.

Another important fact is that the F4P framework can be used for external customers as well as internal customers (something that all other authors mentioned here missed.)

I recommend you to read Fit for Purpose: How Modern Businesses Find, Satisfy, & Keep Customers, But let me also tell you how I used F4P and how my colleagues and I experiment with it.

Collecting Feedback after training

In F4P book, authors introduce a simple form for collecting insights from customers who used your service or product. They give example from their training business and how students who fill out the form help them make strategic decisions about their market segment and marketing message. You can read about this more in the book , but here is a link to David’s earlier post https://anderson.leankanban.com/fitness-for-purpose-score/

I do use this form after each training I give wether it is on Risk Management, Kanban method or product management or any other trainings, wether it is for external customers or my internal ones (colleagues). I alway find interesting insight from the answers, and most of the time adjust my delivery to be more fit for the audience purpose.

One of the trainings I provide is a 6 hours introduction to risk management. I usually provide this to company internal audience (maybe one day I will make it a public class). Over the years, I have modified the training to fit to my main audience (technical people, software developers, Agile Coaches and Scrum Masters). Recently I have provided the newest version of my training for a group of programmers and my Fitness Box Score was like 0/0/37 (37) 15/15 Which means:

Out of 15 people who got the training, I collected 15 result, and 37 purposes (or needs), and the audience scored those needs as 4 or 5 in all cases, this means that I either met their expectations fully or exceeded it. I now know, that this training is a good fit for programmers who work together at one project or product.

David and Alexie give more examples of fitness box score and scoring techniques in their book.

Defining metrics for internal company teams

What I like the most about F4P framework is how it defines metrics and their interdependencies. I think this is the strength and differentiator of F4P framework and also a market need. The fact that every metric is a KPI in today’s world shows the problem that exists in organisations. Most Managers talk about KPIs, and when you ask them what are your KPIs? They usually list all financial metrics they collect. Once I have heard a senior manager saying that his KPI is for his unit to be break-even at all times. That company is not in good shape now, and that manager was let go.

F4P framework shows you how to define metrics that matter, and how to stop using metrics that do not matter. It starts by understanding customers, and what they care about, and how they measure your service (or product). For example, in the case of my Risk Management training class, one of the common purposes (needs) was: to learn about risk management, so I can apply it immediately. Therefore, I designed the class in a way that the audience work on real risks from the start. They start to work with risks that they face today at their work, they analyse them, plan countermeasure and etc. They all get out of the class with their learning already put in to action. On top of that, the class is tailored to software engineering risks and how to understand and handle them. For me the main KPI is students’ learning — if students can use the concepts immediately after the class. In fact this is how they measure the training too.

F4P shows that KPIs are only what customer care about. Revenue is not KPI, Market share is not KPI, Operating Cost is not KPI unless your customer measure his/her satisfaction of your product and service delivery based on your Revenue, Market share and Operating Cost . Do you have a customer who measures his satisfaction of using your product based on how much revenue you have earned this quarter? the higher revenue the more satisfied he is?!

According to F4P, you have Fitness Criteria metrics (or KPIs, metrics that customers measure you based on), Health Indicators, Improvement Drivers and Vanity Metrics. Here is the beauty of this framework. Your Health Indicator can change to Improvement Driver, and then change back to Health Indicator again. And your Health Indicator can be linked to your Fitness Criteria (or KPI, what customer care about).

Your Health Indicators measure and monitor the health of your system. When you see a Health Indicator out of its defined normal range, then you want to upgrade that metric to an Improvement Metric with a specific target. When you reach that target, you can decide to downgrade it to Health Indicator again and set the range or keep on improving. This is where F4P influences behaviours (recall what Eliyahu M. Goldrat said?) , F4P help you to choose the right Health and Improvement metrics. Linking Health Indicators to Fitness Criteria makes sure that your changes (drives from Improvement Metrics) will have positive affect on your product and service delivery.

So far we discussed about external customers, the beauty of F4P framework is that it works for internal customers too. But, first you should review: what is Service, and what are Service Delivery principles?

I was about to write what is service, but this picture explains what is Service very well. If you look at any sizeable organisation, you realise that it is an ecosystem of interdependent services, Kanban method recognises this and introduces three Service Delivery principles:

1) Understand and focus on service customers’ needs and expectations (internal customer as well as external)

2) Manage the work; let people self-organize around it

3) Evolve policies to improve service customer and business outcomes

For example, your HR provides certain service to the rest of the organisation; your Accounting Office provides certain service; Your QA, Development, Product Management units/departments/teams provide certain service to the rest of the organisation. Individuals also provide service to their teams or unit. For example, a manager may provide decision making service for certain topics. But, how do you measure these internal services? That is where F4P can help. HR can monitor its service delivery with fitness criteria of internal customer (employees) and also discover new services it can provide, makes improvement to current services and monitor the health of its services. And it all can link to not only internal but also external customers.

I was working with a project based company, At one point we created stable but fluid teams. The idea was that teams move between projects instead of managers allocate resources to new project every time. However, one challenge arose: Sometimes one team did not have knowledge about a specific technology, or it needed to increase capacity for a short period of time to handle unplanned and irrefutable work. Instead of allocating resources for these teams in need, we defined a service mechanism. So, teams could provide service to each other based on their unique capability. So, one team could be fully dedicated to one project, but also be available to help other teams should the need arises (I will write another blog post about the mechanism that the work can travel between these teams without interruption). All these interactions could use Fitness Criteria (KPI), Improvement Metrics, Heath Indicators to keep each service provider fit for its customer purpose.

Employees satisfaction and ideas to improve company

Another area that I experiment with F4P little bit was on employees satisfaction. In his book, The Alliance: Managing Talent in the Networked Age, LinkedIn founder Reid Hoffman discusses a framework that companies should use for today’s world of shorter term company-employee relationship. In nutshell, both company and employee should agree on the value they create for each other for the next, let’s say 2–3 years. In other words, what services employee provides and what services the company (or manager) provides to the employee. Such a two-ways service relationship can use F4P. First, there is a threshold that both parties must be aware of in regards to their fitness criteria, then they can monitor that with health indicators and whenever needed transition to improvement metrics.

After explaining this concept to my direct reports, I then asked them to write what they want the company to provide them with. Some common answered were Be Better at what I do, Learn new concepts, increase my experience in XYZ area, gain ABC credentials, increase my market value by X%. We then worked together to draft a plan and agreement for that service delivery, and monitored the performance by frequent feedback. I left from that company and did not finish this experiment, but soon I will explore more.

This post is getting longer and heavier than I originally intended, so I am not going to make it even more complicated. But, one other area that I tried F4P is during Product Customer discovery for obvious reasons, especially in getting insights from customers of competing product category.

Conclusion, Read Fit for Purpose book. Enjoy it and share your findings!

Also, it has been proven that stable teams work better together on long term projects in software development. However, almost majority of software development companies or digital agencies break teams and reassemble them based on new projects or clients. This creates unnecessary complication and waste when the team starts to form again. A possible solution for this is to keep teams togather and allocate projects to existing teams (or ideally team pull projects). When they are done, then do not break the team, but find a new project for for them — This will put stress on New Business Development, and may force improvement and novel solutions to get new projects. The idea here is clear and simple but what else can be done to break the current organisational models of digital agencies or software project based companies ?

What I am writing about is based on my experience in digital agencies and software development organisations. What you will read below may not work in all cases and therefore I am not suggesting a complete method or framework, but one possibility out of many. Although I am talking about software company but below may work for any knowledge worker company that works based on projects and teams.

For the sake of simplicity, lets have a fictional organisation called OrgSoft.

OrgSoft is a typical software development company. It has several layers of Vice Presidents, Management, Team Leads and the rest of the workers. Strategy is set from the top and communicated to the bottom. Projects are won based on tenders or sales team go out and bring projects. OrgSoft also has a PMO office and well organised project management process. They are able to run projects based on traditional project management, Scrum or Kanban or Disciplined Agile Delivery or anything in between (by now OrgSoft may be more advance than many digital agencies or software development companies in terms of project execution and agility.)

When they win a project, they assemble team sometimes, they need to sacrifices other less important projects in order to make the new client happy. Sometimes, resource allocation gets chaotic despite the fact that there are weekly project reviews and planning between Scrum Masters, Management and Project Managers. But, that is how things are and everyone take it as given, at the same time they try to improve things as they move forward. OrgSoft also has a support and maintenance team dealing with external and internal clients. They act as post production team for clients, and “try” to act as internal DevOps for internal development teams. Like any other organisation OrgSoft has different departments and specialisations, as well as supporting departments such as HR, Marketing, IT Services and etc. While orgSoft need to be more productive and “efficient”, they also must gain knowledge and be more innovative, lean, agile and all other cool stuff!

But, We know from Cynefin Framework that to be Agile and innovative, you should navigate between and through Complex-Complicated Domains and sometime touch Chaotic domain for the sake of emerging solutions. However, the OrgSoft processes are taking it to an organisation with more constraints and rigidness — Despite all the cool agile and lean implementations. To reduce this rigidness, we must have less governing constraints and more of enabling constraints. So lets get to surgery:

1. We will break all the organisational hierarchy. No one is anyones’ boss for now. This breaking gives us a system that we can shape. It may take us to Chaos for a short period of time. but we immediately put some enabling constraint around it.

• First constraint is the company itself. All people are member of this company and they act within its Boundaries.
• Members should form teams. Every member must be part of one and only one team. This applies to everyone including executives, HR, Marketing and the rest.
• Teams may have team lead or they may not. It is up to them to define or introduce a team lead. They may decide to rotate in the role of team lead, or they may choose to not have team lead, but have a spokes person, they may also decide to rotate on spokesperson role.
• By now the organisation should look like this. Keep in mind that there is no hierarchy yet and there is no connections between these organisms.

1. At the later stage of our evolution, teams define Explicit Rules of connections and they form a network of independent teams.
2. They also agree to provide service to each other, there will be no blending but one team can provide service to another if needed. This will help to over come specialisations that may exist or skills or knowledge level. Or some teams may end up being specialise on certain domain.
3. There are also other teams that only provide service to the rest of the organisation: HR, Marketing and Sales provide their own related services. There is also another team which act as experts in different areas. They get together as a team and provide domain expertise knowledge to the rest of the organisation. Expert Teams may decide to dissolve their team and each join another teams to be more productive, but for now they decided to give it a try.
4. Each team is also free to chose its internal way of working, some decide to work on Kanban model, another team decides to work based on Scrum, another team decides to do Extreme Programming, another team decides to do whatever they want.
5. An executive team also has been formed. They agreed to be only Enablers, and coordinate the whole company. Nobody will report to them and they are not anyones’ boss. They are Servant Leaders of the organisation.
6. Service oriented design allows teams to focus on flow of work between teams. And the flow of work can be handled by Kanban. One of the responsibilities of executive team is to monitor the flow and help teams to balance demand and capacity between teams and to external parties.
7. There is also a Business Development team, They go after new business.
8. Crews: Because New Business Team needs support from the rest of organisation in preparing proposals. OrgSoft agreed to introduce the concept of Crews. They agreed to have “New Proposal Crew”. This is not a team, each crew members has certain responsibility and task and will not intervene other crew members. Because the roles and responsibilities are explicitly defined, Crews can form and disperse very quickly without going through team formation. So, OrgSoft New Proposal Crew forms when they are in preparation for a new project pitch, and after that is prepared and submitted they de-formed and go back to their teams. This does not mean that overtime they need to prepare a new business team, they only form crew from different teams, sometimes a Crew may be formed form one team. The point is that a Crew is temporary and it is not a team, and is tightly constraint for quick action, as each member has specific responsibility and task to execute.

OrgSoft decides to experiment with hiring as well. Therefore, they decided to empower teams with hiring. Each team hires, team members can move around. Team divides to two like cells to create new teams as a scaling practice. If a team needs HR services, then it pulls HR services for hiring as well, otherwise it has full autonomy to act within the constraint of team purpose.

If needed, Each team can send their request to HR as a service request. HR and Recruitment Supporting Team collects all requirements from all teams, and ordered open positions based on Risk Profile that they created. They use multi-dimensional risk profiling for recruitment such as below. They defined five risk dimensions to help them prioritise recruitment. (More on risk profiling on another blog post)

The ordering defines in what sequence new candidate will be moved to each team. Although each team should pull the candidate, but it should also be a mutual agreement, the candidate should also agrees to join the team and selects, each candidate can also try teams and if they are happy they can stay with the team or decide to move to the next team in the sequence. Therefore, it is in the best interest of a team to be attractive. Such a goal enforces teams to constantly improve themselves and be a proud team to attract talent that they may need.

To scale, only a high performing team can be divided into two teams, and attract new team members. In cases that Larger teams may be needed, then two teams can combine to create a larger team. The number of team members will be decided just in time and based on the project and context they will operate in.

Project Portfolios are handled as a pool of projects and Clients. Each Project-Client will have its own multi-dimensional risk profile, and it is prioritised and sequenced based on the risk profiles. Teams pull projects as they have availability. The goal is then to match capacity with demand in a way that there will always demand (higher than capacity), capacity is not jammed. Therefore 100% utilisation is not the goal, but the goal becomes how not to have 100% utilisation, and have enough revenue and profit. (I will cover portfolio management in such organisation later in another blog post).

In situations that a team does not want to divide into two team to handle a smaller project, then they accept two or more projects to work simultaneously. To prevent multi-tasking and have enough predictability. They use Kanban with multi-class of services for each project. One team member volunteers to coordinate flow of work and handle incoming works.

Related Posts: Breaking Hierarchies, and the birth of a Network Organisation at a Pure Project Based Company

When I talk to some ScrumMasters about servant leadership, it is also hard for them to really understand it, especially when they come from traditional project management world of command and control.

In the past couple of days, I was discussing with clients and management about autonomy and self-organised teams a lot. And I thought, I share here a glimpse of a real example of a self organised team. Fresh, hot from today Slack communication of one of the teams I serve happily.

Context:

• This team is 7 people, Let’s call them Team X,
• They work with another team on the same backlog. Let’s call them Team Y.
• Team Y is 6 people.
• Both teams are cross-functional, and they work hard to share knowledge together and learn more about different part of the system.
• They work with Operation Team, who takes care of Production releases and maintaining infrastructure. Operation team is four people.
• They work in a project based company. They develop application for their external clients who act as Product Owners.
• There is a Product Owner Team. Two main product owners, four product owner supporters, and one Chief Product Owner.
• Team X and Y had several changes to their team. Simply, people left to different countries to work or decided to join another company. And new team members joined. There were some challenges at the start, but both teams started to collaborate together effectively very soon.
• There were several process improvements also in place. For example:
• They decided to not commit to their full capacity at the start of each sprint.
• They decided to reduce bugs to Zero, and put Zero bug in their Def. of Done. This was a huge change, as previously they had 100+ bugs unresolved with average lead time of 2 months, and max lead time of one year. Today, and after 4 months, they have Zero. And they resolve bugs when they appear.
• They also work hard to have ready backlogs at all times, at least for the next 3 Sprints.
• They have also adopted pull mechanism. Historically, work was pushed to them by Maintenance Team and Product Owners. They agreed with Product Owners and the rest of the stakeholders that they pull Stories or Work when they are done with in progress ones.
• They have done many other improvements as well. But, it is beyond the scope of this blog post to explain them.

To demonstrate a glimpse of their self-organised nature and autonomy. I wanted to share a conversion that 3 of the programmers had together TODAY (July 20th 2016) on their Slack channel. I have not edited anything here, only names and some sensitive product info changed.

Oh, one more info, They have two weeks Sprint, Their Sprint Review is next Tuesday Morning, and today they were done with committed stories, and were trying to pull in more without any direction or intervention of ScrumMaster or Product Owner. Fully self initiated.

Read it and see a small example of optionality, selection, autonomy, self organisation, respect, commitment, awareness and self responsibility.

3:30 PM

ZM :what about pulling in Story-3104. I think it can be done on time. What do you think @RR and @VA?

3:40 PM

RR:

@ZM and @VA we can, but we should sit and discuss how to do it

3:41 PM

VA

I’m in gov office. What is that story about?

3:44 PM

ZM

Search: Integrate WeeklyAds results on search. Basically new Tab for the Weekly Ads. It will get the content by javaScript (calling external webservice which returns HTML) but there is another service which will return just the number of results.
when are coming back? will you make it today?
so we can look at it tomorrow morning

3:47 PM

VA:

Yes, I looked at it yesterday. From my opinion, it’s mostly about frontend, so I agree to pull it in, but I think that @RR should decide if he has a time. I don’t think that I will be in office today because my appointment is at 16–10pm , now I’m waiting.
So to look at it tomorrow morning would be better

4:11 PM

RR:

it’s ok, I finished all bugs, so I have capacity…we can discuss tomorrow morning then.

ZM went through the backlog, and reviewed all possible Options. And He then Selected one of the stories. Then, communicated it with two of his teammates, they all Respected each other’s availability. Then, they agreed together to talk about it when they all are in the office. There is no need for anyone to intervene and try to set-up a meeting for them :)

Autonomy, Self organisation, Respect, Commitment and Self Responsibility (Real Life Example) was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

It turns out that these two types of beings (logical/rational and emotional/irrational) are in fact the two sides of the same being. They are intelligent and emotional beings with strong logical and cognitive ability, and they belong to a group, tribe or family. They have their own dreams, self-image, self-esteem and ego. With this, they each create their own identify in the society they live in.

Our guy (in above picture) is a human who is emotional with cognitive ability, has unique individual identity and belongs to one or more social groups. When we don’t pay attention to that, then no matter how good your intention is you will encounter a strong passive or active resistance when proposing a change.

Who the hell are you to tell him to leave his mermaid, take the risk of climbing the mountain just to get a box of treasure?! What do you know about his life, and context he lives in? What do you know about his past and future dreams? You know nothing, Jon Snow!

I have tested and experimented different ways of causing change in organisations, teams and individuals (including myself). Every time I caused the change with pure reasoning and logic, it was unsuccessful, had a short life and/or encountered huge resistance. The key was to accept the current reality of people’s lives, see these people as unique individuals who belong to one or more social groups and have compassion and respect for them. And also the people themselves had to want the changes. Only then the changes encountered little or no resistance, were more effective and had long life.

I have witnessed failure in change initiatives, even after passing the rocks of resistance. This was simply because change also requires new behaviour and habit that may cause physical changes to neurones in the brain. The process takes time, it requires individuals to really want to change, and it is evolutionary.

That is why Kanban Change Management principles are designed to frame an evolutionary change:

• Start with what you do now
• Understand current processes, as actually practiced
• Respect existing roles, responsibilities & job titles
• Gain agreement to pursue improvement through evolutionary change
• Encourage acts of leadership at all levels

Even though collocation has its benefits, it is not the necessary condition for a successful delivery team. Collocation as a dogmatic view may hurt you more than you think, and will not necessarily help you to deliver more successful products.

I am neither for nor against collocation, but I have experienced and worked with both approaches. And each sometimes worked very well and sometimes failed. All the variations of teams geolocation (collocated, fully-dispersed, partially-dispersed, or distributed) can work. It all depends on how the collaboration model is setup, what is the context and conditions, and how much the team and organisation are aware of each other, and are aligned.

Having said that, most of the successful teams I worked with were fully or partially dispersed — we were located in several countries and time zones.

One of the best teams that I worked with was fully dispersed. Every single team member was in different location, but we had “mental closeness”. We knew what we are working on, why we are doing it, what quality we must be delivering, to whom we are delivering. We also had direct access to customers, we could interview them, we could test at any time, we could adjust our strategy, we all had visibility to metrics and financial results.

Even though each had different specialisations, we were all aware of technical and non-technical decisions. Of course, we argued and fought with each other, when we did not agree on a solution we tried couple of options to see what works best; but also we respected and helped each other, we shared our feelings, and cared about the work we did and about the well-being of each other. Again, this team was fully dispersed, each member located at different place — 100% virtual and remote work.

At a different time I worked with a team, which was sitting in one location. The team had several conflicts, and political fights. Business and product owners/managers were giving orders, the team had no clue what the business needs or who the customers are. We had no idea why we are building a specific feature, no idea about metrics, business or social impact of our work. Again, this team was collocated in one place.

I agree that a good team may work even better, if they are collocated. However, that is not at all the necessary condition for success. Collocation means sitting in one place, one office, one room, next to each other with product manager/owner with full transparency to everything.

What is not collocation?

• If you are sitting in one building but different floors.
• If your delivery team sits together, but the rest of the people are somewhere else (rest of the people means: business domain experts, product owner/manager, and other immediate project stakeholders).
• If you should travel between places to meet each other.
• If you are not sitting next to each other, or sitting with barriers (walls or cubicles).

What does make your collocated team miserable and ineffective?

• When the delivery team is only “order taker”.
• When delivery team has no visibility on the future work, and they can not participate in planning the future work.
• When they have no visibility on the the result or impact of their work.
• When their family and friends are in another location, and they should travel between places regularly (weekly or bi-weekly). Traveling regularly may be part of the work and life of consultants. It works for them. But that is not an effective strategy for a team that creates things and solves problems every hour of the day (such as a software team).
• When there are organisational barriers and virtual silos, such as Project Managers, Analysts, Testers, and programmers who “should” do what their job title says and nothing else.
• When some team members have access to certain documents and others don’t. Even though they are project documents, and not top secret recipes.
• and many more …

Recently I started to work on a project, which is partially dispersed. Main project stakeholders are in the United States (fully dispersed in the US, so none of the team members sit next to each other). Another part of the infrastructure team is in India. Also there are several 3rd parties who we communicate with regularly, and who are also fully dispersed. And the delivery team sits in one room in Prague.

We set the right culture from the start; there is full transparency on why we do what we do, who we are building the product for, what we are going to build now and what we may do later. The team has the autonomy to make decision and all stakeholders trust the team and are fully aware of the capabilities. There are almost 30 people involved, who communicate daily with understanding and compassion. Our core problems are not geo-distance at all. We do not feel there is a geo-distance between us, because we have “mental closeness”.

So, the moral lesson here is: before wasting time and money on collocating people, think about your organisation’s “mental closeness”, values, behaviours and agendas. Embrace the transparency as a value and stop hiding the dirt of the organisation under geo-distance idea. Make it visible and clean it up, or loose the business to those who do.

Collocation is not the silver bullet for success and agility was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have started and worked on several startups in the past 16 years. When I look back, I find the following patterns appearing again and again in every unsuccessful startup that I was involved in.

Here is the list of patterns, and they are not in order. I wrote them as they came to my mind:

• Giving Up Soon: We gave up soon. Sometimes at the start of success we stopped. At one startup we started to make small amount of money after several months, and then we stopped! To be fair, we stopped, because the team collapsed, but anyway we stopped at the moment that money started to come in.
• Not Putting 100% focus: We did not put 100% effort into it. For some of us it was the secondary job, and for some of us it was the last thing on the daily agenda!
• Not Hustling: We did not hustle. Some of us took care of our comfort instead of hustling.
• Not Passionate Enough: Some of us were not passionate about the problem we were trying to solve, or customers we were trying to serve, and the change we might make to the world.
• Slow Reaction: Although we were much faster than many companies, we were still slow in reflecting, collecting feedback and adapting based on those feedback compared to many established companies.
• Launching Late: Before giving it to users to try, we changed the technology platform 2 times, the design a couple of times, and we we got stuck at working on less important features just because we wanted to make them perfect. We had to launch early and iterate fast, but we did not manage to do that.
• Wrong Technology Choice: We were thinking about millions of users, and went after a technology that can handle that volume. That cost us time, energy and in the process we lost our focus. In the end of the day we had to change the technology, because we were not ready for it. We had to go with minimum and adapt as we grew. We were solving a problem that we did not have!
• Co-Founders did not focus on Sales or meeting customers: Although we as founders made sales, it was not our primary task in the beginning. We hired Sales and Marketing people, so we could focus on Product Development. Instead we had to focus on Sales and face the customers ourselves to learn, learn and learn.
• Did not burn the ships: We all had a backup plan in case the startup would not work. In fact we could sleep well at night, and do nothing during the weekend (at least some of us). These days if I see an early startup founder who is relaxed, I know he or she is just a wishful thinker.
• Location, Location, Location: We did not consider the location we were launching at and the impact that it may have on our sales and fundraising. Maybe we could start from a better location that have higher market capacity and better access to funding.
• Aggressive Sales: We did not go aggressively after Sales. The startups that I am referring to here were B2B, and Multisided Market startups. Sales was very important. By selling, we were not only increasing the chance of success, but also were learning a lot in the process of selling. We had to spend time on sales to learn and earn (or at least proof that we can earn).
• Best Team in Dream: We thought we were the best team, but in fact we were not. We were a group of individuals hoping and wishing for the venture to succeed.

These days when I have the opportunity to start a new startup project, I look at this list and ask myself if I see these patterns emerging, or if there is high chance of them appearing under current circumstances. If the answer is yes, I either defer the decision to start for later or discard the project.

Worth noting:

• None of the above patterns is about product/service idea. As I believe the idea evolves and with the right mindset, right team and the right network you can turn any idea to sustainable business.
• Not giving up soon, having a great team, focusing on sales or any other patterns from the list above will not guarantee success, but they will reduce the likelihood of failure dramatically.

So I try to ask the following questions before starting a new startup. The answers to these questions reveals interesting facts sometimes:

• How much committed will I be to this venture? How much do I believe in this idea? Under what circumstances I may give up? How can I not give up?
• Do I have passion for this idea? Do I think about it 24/7? Am I obsessed with it? How about the rest of my co-founders?
• Can I and others focus on this 100% of the time? How can we handle other obligations? Do I (and my co-founders) have the guts to stay focused, burn the ships and hustle?
• Do I (and my cofounders) have the right capability to build this thing? Or are we are going to be dependent on others? Can we deal with the dependency? How can we handle the risk of such a dependency? How can we remove the dependency risk?
• Are we the right people to work with each other?

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 275,554+ people.

Subscribe to receive our top stories here.

Ingredients of Startup Failure was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.