If a donkey is not willing to drag the cart, you pull it’s tail. It will resist the pulling and start dragging the cart.
The suggestive question “Why retrospectives”, might create pressure to conform, or to give the right answer. I have used the controversial question successfully a few times. Asking the opposite:
- Is actually the important question: “What is blocking you?”
- Everyone is working for the same goal 🙂
- Is often fun and creative
- Breaks the expected or established roles and games. Makes people change their position or perspective, even for a moment.
Feel free to use for any topic.
At Scan Agile we got the following list of reasons why not. Some advice between the lines.
- The value of retros is not perceived
- No experience of the benefit
- Actions are not done
- Experience of superficial retros
- Assumption that retros are “feeling stuff”, with no “real” benefit. People are not used to it
- Teams are (feel) unempowered
- Too many meetings even without retros
- Culture of conflict avoidance
- Fear of blaming
- Misunderstanding retrospectives
- Cost of delay is a good argument for actions
- Scrum does not resource retros explicitly
Some advice to use 2% to formal retros. 1% (hour/2 weeks) for iterations, 1% (1 day/quarter) to full product.
- lack of facilitation skill, person (with identity), role
- some people just don’t like to talk
- people have not learned to recognize their own feelings
- we don’t have the time
- boring, boring, boring (defense mechanism…)
- feelings are disconnected from the work context and identity
Technocrats may turn surprisingly talented in emotions. Just give them a thinking tool, a rational systems model, with which they can connect feelings with work. I have had success with Nonviolent Communication. Is frustration or anger a feeling? Significant? Is disappointment significant at work? Or joy of success?
The conclusion is, that we have not tried retrospectives, because we don’t have a positive experience. Kind of logical…
The advice would be to give it a try with good enough sponsoring and facilitation.
I use this opportunity to publish another list with the same theme… very similar findings.
Understanding why NOT retrospectives at the International Retrospective Facilitator Gathering UK 2007
Post-it’s by Ari (host), Eshter, Sandra, Sal, Gabby, Linda
- Poor facilitation
- Bad facilitator
- Only the strong get their thoughts come through
- Time zones / distributed team
- Chaotic retrospective
- We blame or action people not in the room
- No or poor facilitator
- Facilitator has favorites
- Everything is going well !
- Threatens illusions that reduce anxiety
- “they” are not doing their part (mgmnt team)
- no honesty
- too positive. Hard to be honest and burst bubble
- no-one tells what really happened
- everyone lies
- problmes are too big
- if we admit there’s a problem, we may have to d osomething about it
- not seeing your own part in the problem
- Im minority, so my contribution isn’t worth anything
- Team does not take it seriously
- (Fear of) losing control
- We just bring up the same old things
- Actions agreed upon does not come through
- Ae can’t do anything about it
- Uncover managemtn’s powerlessness
- Our action plans will be over-ruled by management anyway
- Culturally inappropriate (taiwan vs china)
- Too touchy feely
- It”s whacky stuff
- bringing personal issues to the job isn’t proefssional
- short term ebefit culture – ony this project matters
- you can’t express the benefit in hard numbers
- gap between management and team; no real knowledge nor/or understanding of significance
- power is elsewhere command & control
- no meeting rooms available
- developers can’t possibly understand what we (mgmnt) have to face
- it has not worked earlier
- sipmplistic retros that don’t uncover anything significant
- cultural differences (no common language?)
- I am leaving so I don’t care
- people feel powerless
- I’m not creative
- I have nothing to contribute
- I am ADD
- I have asberger syndrome
- I already have another forum (“Honest talk time at japan)
- Managers mistake system problems with individual problems
- retrospectives may discover unconventional solutions, which can’t be supported by management without their safety net. “What others did”
- 80% of problems are management problems… and they don’t want to deal with them…
- We’ll do it later
- Doing my real work is more important thatn going to meetings
- something more urgent came up
- we don’t have time!
- Takes too much time
- takes time away from real work
- Don’t want to look bad in front of..
- It disempowers me as a manager
- retrospectives may uncover bad (management) decisions
- fear of being blamed
- “what is my role” if they do decisions on their own.
- fear of criticism
- fear of conflict
- fear of admitting problems
- Im not comfortable expressing my feelings in a group
- we have to change. That’s scary.
While looking around in any organization, you most probably recognize the Gap between the product management/PO and the R&D/Teams/designers. It is significant in surprisingly small organizations.
This becomes obvious when starting Scrum. The Gap has always been there. Why? What have been the workarounds earlier? Why is it important to understand the root cause? Actually there are more gaps on the value stream…
Have you ever heard the following, when taking Scrum into use:
Team: Scrum says Give us the prioritized backlog.
Product manager: Yes, but we don’t know about tech, you do. Here You have the 5-liner. Just start working.
Team: Yes, but we need to know where to start.
PM: Yes, but we can’t prioritize technical items, you have always done it.
Team: But we can not work if we don’t know the priorities for the next sprint.
PM: What’s wrong with you?
And so on…
The Gap means simply that there is too little knowledge power, too few people who would understand both technology and business. I have many many times experienced how drawing this picture on a flipboard will stop the blame war in the room, when people realize that it is the system, not us.
Read the rest of this entry »
I have seen product development projects used as tool to extract results from the organization. It has been chosen to solve an organizational problem. It worked in certain conditions, but when the organization grew and outside competition became harder yesterday’s solution became today’s problem.
I try to explain my point with a lifecycle of an imaginary organization. My real life example companies vary from 15 people to thousands.
Once upon a day a group of engineers started to develop a product. In the beginning everyone knew each other and there was fluent informal communication. The techno-cultural foundation was laid. The business started to grow.
Growth and the first coordination crisis
Money comes in and the organization grows. There is more coordination work, so some developers become managers. The organization develops “naturally”, creating specialized roles and competences. There are more customers and releases. Ownership of the product gradually becomes scattered. There are bottleneck resources.
At some point the “professional project management” steps in. It is solving the coordination problem, one project at a time. The project manager has permission (by role) to demand results. She becomes powerful member of the organization, getting credit for creating order and bringing money in. Often the personality of the project managers support this specialization. Portfolio management still works or is less important. Business does well.
This is a critical bifurcation point, a leadership crisis of unrealized significance . There is still an opportunity to start a Lean evolution. My example goes to the mainstream way. From the psychological perspective this is the easiest solution. It requires least personal change from the most of the people.
Gradual Scattering of the organization
Eventually there are several parallel and sequential programs going on at the same time. Each project is re-built and re-learned every time, because they surprisingly are different from the previous one. The projects becomes a separate powerful dimension of the organization.
The projects become a kind of device extracting money out of the complex and uncontrollable organization. The business management alienates from the R&D, because the real value seems to come from the project device – the development can be replaced, off-shored, outsourced. Long term development of the R&D is seen risky and difficult. Frustration and distrust grows at both sides.
You may recognize one or more of the following characteristics:
Short term rules. Quick fix. Avoid conflict. Nonproductive feedback. Gap between business, customer and development. Continuous reorg. Exploit development. Specialization and separation of responsibility. Cling to nonfunctional ERP. Clear social classes within the organization. Big power differences. Command and control. Waiting. Big plans. Wish for predictability. Slow and vague feedback. Learning and improvement don’t work. Projects compete of resources. Cost management. Number management. Measure hours. Maximize resource utilization. Knowledge and power seems always to be elsewhere.
Market saturation and the productivity crisis
Now the product (family) is growing old. And there is competition. The business management is facing a situation where the portfolio management is very difficult because of the complicated product and organization; lack of transparency and flexibility.
Even in this situation, I have seen the management to grab the tool that used to work, trying desperately to improve the project management. This is very painful for the project managers.
My point here is, that in product development you may do excellent “conventional” projects, and fail. Even fail because the projects have been successful.
My vote for the one word root cause would be overspecialization.
Please comment and share experiences, I have not emptied this subject.
Why do people and organizations do what they do? What is the wisdom in the stupidity? Making sense of this helps to find primary questions, root causes or basic assumptions. Knowing those helps to make synthesis and applicable new solutions. And it helps to be merciful towards oneself and others. I will be blogging about models that I have found useful.
First I want to present two jewels of organizational thinking, real diamonds. They point out sources of knowledge waste in product development organizations. Originally they were presented in the book Ward, A., 2006. Lean Product and Process Development, Lean Enterprise Institute. The book contains really careful and valuable thinking. It is mandatory reading for anyone working with organizations.
1. Sources of knowledge waste are:
- Wishful thinking
2. In relation to Scatter Ward explicitly mentions:
- Whenever you separate Knowledge, Responsibility, Action and Feedback, there will be knowledge waste.
These are easy to keep in mind – you will see them everywhere.
Wishful Thinking is of course wasting knowledge, resources and money in huge lumps. It also makes you to choose organizational models, that cause Scatter. Scatter in time and space is causing Handover, which is the massive observable source of knowledge waste. And Scatter makes you loose the ability to decide – real power is always elsewhere.
Obviously wishful thinking comes from ignorance, complacency and fear; not knowing or not admitting, increased by loss of knowledge. A vicious circle.
From this perspective, doesn’t it seem obvious that learning together is the medicine? Seek wisdom, go and see. Having yet another strong management role, separate, does not solve the problem. Power lies with the knowledge!
Please check how Vasco Duarte’s blog PMI and the meta-planning process looks from this perspective.
Just to give some food for thought I list the specific knowledge wastes under the three major ones (italics my brainstorming).
- Wishful Thinking
- Discarded knowledge
- Testing to specification. (Interesting explicit mention by Ward!)
- Physical, social and skill Barriers
- Distance, time differences, data formats
- Culture, language and organizational culture
- Busying oneself
- High power differences – “classes”
- Continuous organizational change
- Overspecialization – narrow roles and competencies
- Poor tools and processes
- Mechanical or narrow information channels
- Manual duplication
- Poor communication tools
- Physical, social and skill Barriers
- Useless information
- Extraneous documentation and communication, Lost knowledge, False information
- Milestone, investment decision, technical decision, …
- Meeting scheduling, resources, …
- Plans, specs, information, comments, permission …
- Test results, bug fixes, dependent components, integration, service from tool provider/IT, …
- Useless information
Clearing some mess around project in Agile context. Thanx for Glen B. Alleman in his blog for the impulse and discussion.
A project “is a temporary endeavor, having a defined beginning and end.”
In SW development the development work, the actual knowledge creation, design decisions, stories, whatever, is best to do in flow, small batches. The work is complex in nature and benefits from really tight feedback and conversation, including the end user. Does not sound a typical project.
However, a release in most cases fits a definition of a project. Especially when we draw the system envelope so that it includes the paying customer. The new SW to be taken into use is causing a one-time change in the socio-techno-economical system of the customer and end user. It will be considered carefully before the investment decision. In some cases this can be a sequence of improvements, a flow. In most cases, I argue, it is a big change, definitely a project. (In this perspective every project is an organizational change project.)
Now, what is so bad about the concept of a SW development project? It comes from the experience of doing it in a stupid way:
– command and control projects, bad interaction, “resource management” approach
– focusing to a one time solution in a messy org, ignoring long term learning and portfolio management
– wishful up-front planning, ignoring the complex nature of SW development
Agile, look at the values, is a counter-argument against this stupidity. I think the question how much value PMI and other institutions add, is how the learn and cope these experiences.
In other words, a “traditional” project is a bad metaphor and practice for creating software. A project done wisely is often a good way to manage customer requests and releases.
I hope to blog soon why we have messed up with projects in the course of organizational evolution. People always make wise decisions in their local context.
Then the worry of the people and the organization; What to do with the project managers. Scrum does not mention a project manager. Clearly, based on the above, the product owner does that work. But the work of the PO is increasing, a natural place for the ex project managers’ contribution. They might be called customer project managers.
I often hear a suggestion that the project managers would become Scrum Masters. Dangerous generalization. In most cases I have seen, the project managers move naturally to some kind of a product owner role. Some human oriented PMs become good Scrum Masters. Then also the organization needs to relearn the role of these persons.
What is clearly disappearing in both cases is the resource coordinator/management role. So the ex project managers will be working more with the product substance. One overspecialized role less, provided that the whole organization is improving.