I’d suggest two things.

– the surface issue is seldom the underlying problem
– you have a team that lacks the skills to be collaborate effectively

Technical skills only take a team so far. A high performance team has significant non-technical skills that allow creative conflict, effective communication and rapid decision making.

What would you do if it was obvious your team was lacking technical skills?

If their lack of non-technical skills are limiting their professional effectiveness as a team, what would you suggest?

I general start teams off with a working agreement; as part of that we look at Amy Edmondson’s Ted talk on psychological safety (and refence Google’s Re:work blog on effective teams); it;s about 10 minutes.

I’d also show “Locating Yourself” and “The Drama Triangle” from the Conscious Leadership group (both under 4 minutes)

This starts to create a conversation about what behaviours are effective (and which ones are not) in a team setting. That can lead to a working agreement.

Of course, that’s not all. The team needs better skills at “courageous conversations” , conflict resolution, effective communication, all of that stuff. Either provide that skill training and mentoring yourself, or bring in providers.

If you are not convinced, look at Ron Westrum’s paper on organisational culture (which the DevOps movement references) and note that in a high performing organisation “messengers are trained”.

TLDR; If the full stack developer wants to be a highly effective professional, then they’ll need to learn some non-technical skills. Raise the bar on behavior with the team, and coach into the gap.

Links :

Amy Edmondson Ted-X

Conscious Leadership Group:

Does the team want to be high performing? Then they need to

I think the devil is in the details; or rather

– expressing gratitude to people is good
– awarding and competing for “status points” tends to be not-so-good

And of course, context is king.

In terms of a “coaching hook” this is perhaps a way to unpack key communication and messaging skills for the team. To that end as with any retro feedback it can be a good idea to dig a bit deeper, as a team, to find the underlying systemic issue:

– what’s the problem that “Kudos points” solve?
– if that’s the surface issue, what do you think the root cause is (Ishikawa fishbone?)
– with that root cause, what does the restated problem statement look like?
– is that something the team owns?

If the team owns it, then it’s their job to think about what success might look like, potential negative consequences of their solution, and leading indicators for their success and failure conditions – and then run the experiment…

I tend to use a problem-statement format that is a bit like how we construct risks, with a triggering, contributing factors and a negative outcome that can be quantified.

WHEN AND THEN

I guess the core thing is “what do you want out of a career?”

I’ve been working in technology businesses for 30 years or so. When I started out I wanted to “climb the ladder” as part of my career, through technical roles into leadership ones where I made decisions.

And to some extent I did that; after about 8 years I was into line management roles with operational and strategic leadership within my domain area. That included being “product manager” and running a small software development product team where we embraced agility for the first time.

I’ve been the line manager for larger groups – like 50+ people in a department with a wider range of functions – but at a point I was in meetings I disliked talking about stuff I didn’t care about. I had done a bunch of leadership development programmes of different types at that point, all of which were built around the same “Theory-Y” approaches that align with agility and so on. I also had HSE as part of my role (teams in remote field areas) and so the links between DevOps and HSE were very solid.

So when my org restructured I took redundancy, and doubled down on agility. I did a lot of self-directed study – like reading key texts back to back and so on – while doing an ICF-accredited coaching course and getting a PSM-1 certification.

At that point I started to get fixed-term and contract Scrum Master positions, but kept up the study and learning, doing some Kanban courses and so on.

At a point I’d suggest:

– job titles don’t matter; it’s about what you are good at, what you love, and what you get paid to do. Scrum Master accountabilities should extend to the wider org going down an evidence-based continuous improvement approach

– what you want now out of life might not be what you want in 5 years, or 10 years. Plan, for sure, but be prepared to respond to change

– focus on the skill/competency areas where you are weakest. For me that was coaching. Then train and study in those areas. Invest in yourself – don’t wait for companies to do this.

– leadership, leadership, leadership. Learn about leadership, how to teach it to people, and how to be an effective coach so they grow new perspectives

– don’t limit your learning to “agile” stuff. read about business, business strategy, change management, finance, product development, marketing all that stuff. Mostly “agile” books are regurgitated fluff – even better if you go to the underpinning stuff.

– data analysis and statistics matter; if you are weak in these areas then build it up. Empiricism means being able to analyse hard data in a way that is useful for decision making.

I think that’s about it for now?

Apart from “being a better Scrum Master” I don’t really know.

Currently I’m planning to get more into Kanban, with a course I’m looking at in March to take that learning forwards.

I have a couple of collaborations ticking over that might lead to a book, or a business, and I’ll carry on fanning those flames.

My current Scrum Master gig runs out in March. There maybe more work , but then again there’s also a lot of agile coaching roles that look good.

At the end of the day, I realised my driver is helping people to achieve. As long as continue to get paid and have an impact, I’m happy.

I’d suggest you move away from the idea of a “template” and focus more on what a User Story is, and how to employ them effectively. You can torture any opinion or idea into a standard format, but that’s not going to help you create great products.

So back to basics –

– a user story is created with the user(s). No user in the room? It’s not a user story.

– a user story is a placeholder for an ongoing conversation. In Extreme Programming (where user stories came from) you’d have an onsite customer you’d collaborate with during the development process. The best product owner’s I have worked with can serve as an onsite customer

– a user story is like a vacation photograph; it reminds the people in the room about what was discussed. If you can’t remember then take more pictures (ie split the story), and maybe record the conversations and keep the whiteboards.

– a user story is only ever a hypothesis about how you will create value; until it is being used and you have feedback, that hypothesis is untested

I’d strongly suggest readding Jeff Patton’s book on User Story Mapping; without that you’ll just get trapped in project-o-scrum with a huge backlog full of requirements-in-a-user-story format and fail slowly and expensively.

Of course you don’t HAVE to employ user stories. It’s okay not to be exploring the product space in an innovative way, if that’s not your business model. If you are rolling out infrastructure to meet a compliance requirement then maybe you *have* requirements, known upfront. If that’s the case, don’t waste time with a template (or indeed Scrum); get onboard with the Kanban Method, go lean, and deliver high quality with low cost…