Information choking - Leads to project arrests

-
In general many projects fail because information is not properly distributed among team members. Customer's intent is not known to the team. This is a major project killer.

Everyone agrees it is good for project team to know all the information about their work. But practically it is not the case. Why does information is blocked? There can be multiple reasons for this. Way to hell is paved with good intentions?

1. Work more efficiently:

Lean theories explain this in a very nice way. Many times product owners start to think making everyone work is more important than completing the sprint. It is myopic vision but people to succumb to it many time. Who is ready to contest the theory 1 + 1 = 2. So if a person is idle for a day then that effort is wasted.
Why waste time with a team meeting discussing the sprint. People will spend time on items which they are not going to work. Isn't it waste of time?

But this results in rework. As lean ideas tell concentrate on the goal. What is deliverable? Deliverable is the sprint. Project team knows best how to deliver. As a team member I know what are my strengths and how fast I can deliver the promise. When I know the plan for the sprint I also know how to plan my activities.

Efficiency bug bites the product owner and then instead of pull things gets pushed to the team. Based on some logic product owner starts assigning tasks. This results in drop of efficiency.

2. Distracted Product owner:

This is a dangerous situation. Based on the customer demand project team is expanded. Now product owner is not able to spend enough time with the team. Some people will identify the situation quickly. But others will notice the situation when things start going down the drain.

3. Fear of loosing control:

Even product owner is a human. Many times job situations threaten them. Unconsciously they start keeping information to themselves. They start giving justification why they kept some information hidden. This is another scenario which is difficult to identify. Project team does not know there is some information missing.

This situation can be identified in the retrospective. If the issues identified are due to missing information it is better to make product owner conscious about it.

Comments

Post a Comment

Popular posts from this blog

Greedy computing with API

-
Image
 We all know computing resources have a cost. Memory, long term storage, transportation and computing all have their own costs. There are lot of scenarios where your API end point won't be able to respond in time. These are scenarios where you need to use more resources to provide a response. Let us be greedy with our resources and explore different patterns which can solve this. Polling  This is a commonly used pattern where the caller initiates a process. Then keeps on checking if the process is complete. If the process is complete then the caller reads the data needed.  This is a good pattern when both systems are part of the same organization. At least developers of caller and callee should be able to discuss this implementation.  Call back This is an improvement over polling pattern. Here the caller supplies a call back URL to the long running process. Once the process is complete it calls the callback URL and informs the caller that process results are availabl...
Read more

ChatGPT for cavemen

-
Image
I heard a lot about ChatGPT and thought to come out of my cave to find out what the hype is about. Is it going to eat all my lunch or eat me for lunch?  Like any product I gave it all my details and signed up. I asked it about quantum computing an it gave some answer. So far so good. Next day I wanted to check its blogging skills. So I opened chatGPT and I got this . I checked throughout the day and it is still down. So it won’t eat me till it is fed few more servers.  Continuing after it was up.  I asked it to write a blog about itself. Here is what was generated by chatGPT.
Read more

Event driven architecture for micro services

-
This is a work in progress. I am designing an event driven architecture to be used in systems using micro services. Micro service architecture is popular because it solves few problems in development process. While it solves some problems it also brings in new problems to the table. Bad designs impact micro services harder than monoliths. But this is thought is for another time.  How micro services talk to each other. In a monolith you have one gigantic database, or you can easily call another component to process the information. In a microservice you can use a Que (or event bus) to pass the information. This is the problem I want to discuss. Main issue with que is it is not designed for this scenario. There are few products which give a good solution by providing a subscription-based approach. But these are large implementations. Using these is similar to bringing an excavator to plant a sapling in your garden. Yes, many people go with using these large implementations to resolve...
Read more