Kaveh Kalantar's Blog

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 th

 To collocate or not to collocate? Most companies that are new to agile have been "consulted" by a "Scrum" Agile Coach, who suggested that they must break their organisation and have cross-functional teams to sit together in one location. Is that the recipe for success?.. Is it really? 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.

At Fundamentals of Change Management post   I described four key concepts of change management that any logical and rational being can agree with immediately. But when it comes to applying those concepts and causing a change, the model breaks and the change agent encounters a bunch of emotional and irrational beings. They see proposed changes as an attack to their existence. 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 goo

For many new to Lean and Agile, the concept of self organised teams or self managed teams is very hard to understand. They simply can not comprehend it.  Because they have never experienced it and never thought it is possible. This includes not only senior leadership and managers, but also programmers as well. 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

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to Kanban From High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important.  Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate.  Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while,

Elliot Goldratt suggested a Strategy Tree for project based companies. While that may work for some companies, it will not work for knowledge based workers or Software Development Companies, or Digital Agencies. On the other hand traditional resource planning and resource allocation is also not effective despite all the effort one put into it to make it less of a command and control model - Here I assume we know who are knowledge workers and how their productivity works, Peter Drucker has a fantastic article about Knowledge Workers that I highly recommend you to read, if you have not read it yet:  http://www.forschungsnetzwerk.at/downloadpub/knowledge_workers_the_biggest_challenge.pdf   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