Stockholm, @ the office
I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. – Maya Angelou
I thought I’d talk for a while about how our product development process relates to learning and continuous improvement. Before we move on though, I will take this opportunity to hint of the larger master plan that is lurking between the lines of all these scribblings:
“The third fundamental element of the model is that learning, quite like change, happens all the time at all levels. I posit that it’s impossible to create change without creating the opportunity for learning. This learning is the force that takes us towards our desired state, as we cannot get to where we want to be without internalizing and applying this potential for knowledge that we create.
If this is valid, understanding how we learn becomes imperative.”
Indeed. How we learn. It matters. If you agree with my proposal that learning is imperative, it follows that we might do well to investigate how we learn and do our very best to learn like pro’s. I would also like to stress that this is but one of several aspects of learning in an organisation.
Now, the theoretical foundations that I lean on here can be found in the work of people like David A Kolb and Kurt Lewin and the concepts of “Experience Based Learning” or “Experiential Learning”. We will return to them further down the road. What follows here in this post is a more practical example of what this can mean.
To accomplish this I thought I’d let you in on a “post mortem” retrospective that we had just a few days ago. While the team had retrospectives continuously during their time together (one of the few non-negotiable practices as the team chooses their own process), I also see great value in looking back at the whole time period that the team spent together and taking a more “big picture” approach to our work than can be squeezed in during the discover/deliver-phase retrospectives.
During this one-day “super-retro” we went through these steps:
1. Timeline of the time spent together
2. Timeline – Happiness Curve
3. Timeline – Productivity Curve
•What does a team need to deliver with quality?
•What does a team need to deliver with speed?
•What does a team need in order to be happy?
•What are the characteristics of a good Team Lead?
•What are the characteristics of a good sponsor?
5. Personal feedback (formalized, written down and delivered orally)
6. Evaluation of the day
We drew a timeline of the whole project, and noted significant events. This helps the team remember their time together and shapes a mutual understanding of what happened. As you know, with memory, every read is a write, so what actually happened is lost forever in the sands of time, but that’s a conversation for another day. Yet, creating a shared mental image of the situation is crucial – even though it can never be “accurate”. This creates a fundament for the conversations that are about to follow. Setting the stage is imperative.
It’s also very important to have a climate in the group where people feel that they can say what is actually on their mind, and not revert to politeness. I mention this because I see general tendencies in several areas to disregard certain set of circumstances that are key factors for success. You can for instance have the greatest set of KPI’s in the world, but that becomes wasteful if decisions are really made by way of power grabs or office politics. And you can have the greatest retrospectives in the world, but if an open culture where people feel that they can speak their mind is not established, you will not get the results you seek. It’s all connected.
Now, we moved on by tracing the general feeling of happiness that the team experienced during the time frame, and drew a curve that clearly demonstrated the emotional “up’s and down’s” of the work. We then did the same exercise with “productivity”. This allowed us to have meaningful conversations about the teams experience.
Then, the Team was asked a set of questions:
- What does a team need in order to be happy?
- What does a team need to deliver with quality?
- What does a team need to deliver with speed?
- What are the characteristics of a good Team Lead?
- What are the characteristics of a good sponsor?
The various “aspects” were then listed by the team, and a few rounds of discussion ensued. The next step was to rank their experience during the whole theme work, using the scaling approach inspired by Solution Focus. The Team Lead exercise was designed so that we could have a look at the Team Lead’s idea of himself (Ideal Self) versus the Team’s perception (Real Self). This provided some clues and was valuable feedback for the Team Lead.
Another dimension of this was that even though we were looking for team averages as they graded their experience, we noted when there were significant diversity in the group experience, which led to interesting discussions and insights.
Below you’ll find the question and the answers that the team came up with.
What does a team need in order to be happy?
- No hidden agendas.
- Being co-located, preferably in the same room.
- Agreement regarding how the group makes decisions.
- Good talk.
- Defined Roles.
- Laugh together.
- Celebrate often.
- A sense of purpose and progress towards the goal.
- Understanding and acceptance of diversity in the group.
- Shared spaces for communication, ideas, progress and checklists.
- Shared understanding of what it is that group wants to achieve.
- Shared understanding for the the decisions made by the group and the sponsor.
- Care about each other as people.
What does a team need to deliver with quality?
- The necessary time, resources and skill to be able to try different alternatives with and without users, and the time to react to the feedback.
- Freedom to chose our own methods and tools that work for us in our context.
- A clear goal.
- Good people.
- All the skills necessary in the team, or adjacent to the team
- Free reigns and focus.
- Reasonable time frame, time frame set by the team.
- The sponsor cares about the result – measurements and quality
- Design towards measurable goal.
- Stability in the team – not moving people around.
- Frequent delivery and short feedback-loops.
- Stability in the environment.
What does a team need to deliver with speed?
- The right skills for the job.
- A good environment.
- No breaks or disruptions during the work.
- Frequent delivery of value and short feedback loops
- A team up for the job (team size).
- No unexpected disruptions during the work.
- A Team that can collaborate and work together well
- Trust from the organisation.
- Focus – one thing at the time.
- Deadlines or rather commitments towards a time frame.
- Small batches of value.
- Clear goals.
- Ability to find problems early.
- A backlog that is properly prioritized.
- The ability to constantly re-prioritize.
What are the characteristics of a good Team Lead?
- Facilitates the group.
- Makes sure that the needs of all group members are met and provides a natural place for each individual.
- Takes care of the planning.
- Protects the team from exterior disruptions.
- Focus on clear goals.
- Is responsible for the group dynamic, and the development of the group.
- Makes the team visible in the organisation.
- Clear take on the user goals – business goals – tech goals triangle.
- Clear take on the time – quality – resources triangle.
- Keep the moral of the team high.
- Makes sure that necessary decisions are made when necessary.
- Communicates needs, obstacles and progress to the organisation.
- Passionate about product quality.
- Has a sense of responsibility.
- Is passionate and committed.
What are the characteristics of a good sponsor?
- Trust that the Team can deal with the task at hand – no micro management.
- Sponsor must be able to set clear goals.
- Sponsor must feel a sense of responsibility for the job, and the goals that they have commissioned.
- Care about the User Experience.
- Understand the difference between wanted outcome, measurements, user goals and business goals.
- Show interest and commitment.
- Understand the consequences of the prioritization’s that they are asked to make.
- Be able to make quick decisions and change course if necessary.
- Be loyal towards their own decisions and prioritization’s.
- Follow up on progress and achievement of goals.
- Be clear on what they are commissioning and why, and communicate this to other parts of the organization.
- Be prepared to re-prioritize and shift focus and allocation of capacity.
Now, what happens if you take these insights, place them on the happiness and productivity curve and create an overlay with the personal feedback?
Interesting stuff, for sure.
Earlier posts on “Not Even Wrong”
- So I’m writing a book
- The model
- About the title
- Reality Check I
- Why this book?
- Who am I?
- How to write a book
- MVU & IF this THEN what?
- A few words on yet another model
- More words on Model II
- A few words on speed – from signal to cash
- The Holistic Product Dashboard
- Reality Check II
- Reality Check III
Pingback: Not Even Wrong – Reality Check IV: Guest Post: Creating a new map search experience | Thomas Talks
Pingback: Not Even Wrong – Reality Check V: Guest Post: The biggest lessons from a successful software project | Thomas Talks
Pingback: Not Even Wrong – Wheelan, Integral Theory and the evolution of organizations | Thomas Talks
Pingback: Not Even Wrong – Thoughts on the organization as family metaphor | Thomas Talks
Pingback: Not Even Wrong – More on levels of abstraction | Thomas Talks
Pingback: Not Even Wrong – Saigon traffic and CAS | Thomas Talks
Pingback: Not Even Wrong – On Simplicity | Thomas Talks
Pingback: Not Even Wrong – A few words on Agile, Pirates and Egalitarianism | Not Even Wrong