Tag Archives: Lessons Learned

Lessons Learned from (Scrum) Coaching sessions

Working at a customer in recent months I was on the receiving end of a Scrum coaching project. Unfortunately this ended early. And I started thinking about what I could learn from my angle as a team member. I came up with the following cases and hope they can be helpful for you as well.

Stick to your role and deliver value

If you take the role of coach in a certain expertise field, stick to the that role. This will give you focus and a higher probability of success in the field in which you perform really well. In addition to that, this is the thing/trick you are hired for. It is great if you can deliver additional value, and get the team of organization you are coaching to a higher level, only after you are delivering what you should deliver.

For example you’re coaching in SCRUM, and there is loads of work to do to get the Product Backlog in good shape, getting the documentation up to par, and help the people with the SCRUM way of working; it might not be the time to debate all kind of possible coding issues, try to remove commit hooks from SVN (requiring an JIRA issue number) and other stuff like that.

Should you as a coach decide to be a part of the team, you also have to commit to results delivered by the team (that now includes you). After you check out the code it doesn’t shown you value individuals if the only thing you do is place remarks and object without not delivering anything yourself (let alone things perceived as value by the product owner).

Stick to your role.

Focus

Focus on your assignment and the results you have to deliver. In the case you are coaching a team in the world of SCRUM it is not necessary to start a debate on all design, technical, technology and frameworks choices that are made in the first week. When valuing individuals and interactions over processes and tools, also keep in mind that it is the team of those individuals that made a range of choices. Some of them could very well be the result of much (heated) debate.

Focus on your assignment and the results you have to deliver. Don’t (re)fight every battle.

Motivating without money

Some of the RSA talks are distilled by the folks at CognitiveMedia into abridged animated versions – RSAnimate. Here is one om motivation and drive:

There are loads of examples in litterature but also in more popular books like Freakonomics that:

People respond to incentives

In the animation you’ll see the kind of incentives that work well for tasks that go beyond mechanical skills and that require rudimentary cognitive skills (like conceptual and creative thinking). These incentives include the following aspects :

  • Autonomy – Which demands engagement instead of management and control.
  • Mastery – It is great fun to learn things and sometimes even be (really) good at something!
  • Purpose – Humans are purpose maximizers even more than money maximizers.

Please note that money isn’t one of them. So motivating without money should be possible. In short for organizations and managers it boils down to:

Treat people as people!

Let me know what you think on this subject in the comments….

Group Development and a Lessons Learned session

Yesterday I attended a Lessons Learned session for a Software Development project where I’ll be involved in the upcoming phase. All participants shared their opinion on the negative and positive experiences. What went well and what needed improvement. Putting all these opinions expressed on Post-It notes in perspective I realized that the major part of the negative experience where from the early days of the project. Whereas the positive experiences seemed to be from the most recent period. This brought me back to one of the models I was taught on Group Development while taking training and coaching courses. It suddenly made sense to me that there had to be a relation with the Tuckman’s Group Development Model.

Tuckman’s Group Development Model

Tuckman Group Development ModelThe Group Development Model that was proposed by Bruce Tuckman in 1965 has four phases:

  • Forming: Individual roles and responsibilities are unclear. Lots of questions about the team’s purpose, objectives and external relationships. Processes are often ignored. Members test tolerance of system and leader.
  • Storming: Clarity of purpose increases but plenty of uncertainties persist. Cliques and factions form and there may be power struggles.
  • Norming: Agreement and consensus is largely forms among the team. Roles and responsibilities are clear and accepted. Commitment and unity is strong. The team may engage in fun and social activities.
  • Performing: The team knows clearly why it is doing what it is doing. The team has a shared vision and is able to stand on its own feet with no interference or participation from the leader. There is a focus on over-achieving goals.

More in this PDF on Forming, Storming, Norming and Performing.
So in which phase do you think the most fun, excitement and productivity is? And as you guessed this was reflected in the Lessons Learned session mentioned: The negative experiences were during the Storming, and the positive experiences during the Performing phase.

Note that:

These phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.

It is important to realize this because sometimes a group of people in a meeting go through these same four phases. And if your a real goal oriented person you could try to skip the first two of three steps. That in will have a severe impact on the buy in of the group / team.
The teams that don’t get out of the Storming phase usually deliver no or very low quality software…