Sunday, November 26, 2017

My Coaching Philosophy: Feel the Learn!

Feel the Learn!

I'll sum up my personal coaching philosophy in three words: "Feel the Learn!"

Physical trainers are apt to say "Feel the burn" as a shorthand for training at a sufficient intensity to challenge muscles and force an adaptive response.

Through my Agile coaching I don't expect your muscles to burn — that would be a surprising and probably unwelcome side-effect! — but you should be burning fresh neural pathways as you learn and improve.

The intention of the snappy phrasing is to act as a reminder that while a wide variety of practices and principles can be brought to play as part of an eclectic coaching approach, they should serve the higher purpose of helping people to actively learn, and to value learning.

Why?

In a fast moving world, the fastest learners win. The coaching profession exists to help people learn and perform effectively. Ideally, we teach people to learn independently, and collaboratively: to think for themselves and to play well with others.
Coaching can focus on achieving external goals or developing personal capability. Of course, the two are inter-related: strengthening capabilities makes it easier to achieve external goals, while setting explicit goals help us to focus.

Personally, I lean somewhat to the learning and capability side rather than the goal-focussed side of the coaching coin. With improved insight and capability goals become easier to achieve, and the confidence in one's skills and capabilities tends to be transferrable to new goals, especially meta-skills like knowing how to learn.

What?

How do you know that you've really learned something? I believe a good test is what you fall back on when you are distracted, or when the going gets tough. Then you find out what you've internalised.

For example, when I discovered that (like most people) I had learned to tie my shoes incorrectly and resolved to fix this I ran into a problem: unlearning is typically more difficult than learning. While I only needed a small modification to my shoe-tying routine — loop under rather than over —it took me over a month of conscious and frustrating practice (frequently catching myself in the old habit) before I was able to switch over to the new routine automatically.

Good learners (and coaches) are humble. Not because "they have much to be humble about", but because there is always so much more to learn. The best sportspeople in the world have coaches who the athletes can out-perform at their given sport, but their coaches bring other attributes — typically around, technique, conditioning, and mental training — that help their charges rise to ever-greater levels of performance.

How?

I like to model the coaching engagement on the Tuckman model, also known as "forming, storming, norming, performing".

The forming stage is about getting to know each other and sense-making: where is there room to learn and improve? What are the strengths that can be harnessed? Where are the weaknesses and blindspots that need recognition?

In the storming stage I challenge some pre-conceptions and maybe this is resented: after all hearing that you're not perfect is typically a bit of a blow to the ego. Or maybe we disagree on where the work needs to be done. If I believe that what I'm going to raise is particularly challenging I may prepare the ground by asking, "Would you like to hear the truth, or the comforting lie?". So far people have always asked for The Truth, but this does help them steady themselves!

Having navigated the storming stage we can start to set some norms about how we're going to work together: different people learn differently, and a nice aspect of bespoke coaching is that we can tailor the techniques and style more so than in a mass-production, get with the program style.

Finally: performing. Having built up rapport and established some norms we are set up to engage in the serious business of learning and improving.

My actual coaching cycle looks a bit like this:
  1. Identify an area for improvement
  2. Engage in some targeted learning
  3. Relate that learning to on-job-work, with coaching support
  4. Practice, practice, practice, correct, practice, adjust, practice, practice, ...
  5. Reflect and improve more, maybe identify another area to improve
  6. Profit!

What Else?

One of the great lessons I learned from undertaking a Diploma of Education is that learning should centre on the learner and pretty much every style of teaching works for some (but not all) learners in some (but not all) contexts.

Therefore I aspire to have a wide variety of tools at my disposal, plus the judgement to pick a suitable approach for particular learner(s).

This jibes nicely with my personal desire to keep learning, improving and exploring, both for my own benefit, and to help serve my clients. A few key areas of personal learning that inform my coaching approach are: martial arts (25 years and counting), improvisational theatre (past), Integral Facilitation (current),  and — of course! — parenthood (ongoing ;-).

Key take-aways

In my coaching approach I emphasise
  1. Capability development over fixed goals
  2. A bespoke approach over one size fits all
  3. Reserving sufficient time for continuous improvement (including learning)
  4. Deliberate and repeated practice to internalise new skills
  5. Building self-coaching capability
Or, in three words: Feel the Learn!

Tuesday, November 21, 2017

Getting Started with User Stories

Why User Stories?

In Agile (software development and otherwise) we need suitable items to populate and pull from our backlogs. Well-constructed user stories balance the needs of stakeholders for valuable and meaningful pieces of functionality with the need of development teams for contextually relevant, but not overly prescriptive work items.

Relevant Agile Principles

Effective use of User Stories contributes to mutiple Agile Principles:
  • Continuous Delivery of Value
  • Welcome changing requirements
  • Business people and developers work together daily
  • Continuous attention to technical excellence
  • Simplicity is essential
If you find that your User Stories aren't helping with these aspects, some reflection is in order!

What are User Stories?

User stories are ideally small chunks of functionality and have become the de facto standard for backlog items. When they aren't small we call them epics or features, and do out best to split 'em down.

The ideal user story satisfies the somewhat famous INVEST criteria (due to Bill Wake):
  • Independent: user stories can ideally be developed in any order, allowing prioritisation of the backlog
  • Negotiable: not over-detailed so as to allow co-creation between customer / stakeholders / product owner and the developers
  • Valuable: it needs to be valuable to the customers or end-users
  • Estimable: a rough sense of size (as well as value) is needed to prioritise the backlog
  • Small: small items can be completed relatively quickly, enabling flow
  • Testable: we want explicit criteria for completion, so we can tell when a story is "done"
Tip: Don't get too hung up on INVEST at first, but keep coming back to it as you build your intuition for what makes a good user story.

How to Create User Stories?

Old school user stories were fairly informal and followed the 3Cs:
  • Card: Written on a 3" x 5" index card, by sticking to one side of a card they were necessarily brief
  • Conversation: "The card is a placeholder for a conversation". The description on the card was intended to be elaborated through conversation between developers and the customer representative or product owner.
  • Confirmation: The back of the card would sketch out minimal acceptance criteria or tests of completion.
Pros
  • Rapid, lightweight, and tacticle
  • Easy to sit down as a group and write cards individually, then combine and re-write
Cons
  • The Conversation aspect practically mandates high domain knowledge and constant access to a customer representative or Product Owner
The newer school, arising from Behaviour Driven Development (BDD), is more formal. The User Story now describes Who?, What? and Why? to give more context, or (more formulaically):

"As [a] ... I want ... So that ..."

And the acceptance criteria are typically specified in Given [current state] When [event] Then [effect] format.

"Given ... When ... Then ..."

Pros
  • Seems to work better for less experienced teams
  • Lends itself to test automation (especially the Given When Thens)
Cons
  • De-emphasises the Conversation aspect, which aids co-creation and iteration
Use whatever works. Try both (and try the other style periodically).

Who writes user stories?

User stories should be written collaboratively by the development team, the product owner and stakeholders.

Often it is delegated to Business Analysts, but their role should be more around facilitating and editing.

What else?

Small stories may be decomposed further into technical tasks, if this is useful for the development team.

Sometimes there will be a piece of work that is meaningless to end users and stakeholders, but makes sense as a cross-cutting piece. These often represent so-called non-functional requirements (NFRs) and that's ok. Often these pieces are referred to as technical stories or architectural epics. They should be the exception rather than the rule.

Other items can appear in product backlogs:
  • Defects
  • Spikes: short investigations
  • Learning and improvement items
Rather than putting user stories straight into a backlog, they can be organised into a user story map. And that's a great move!


Thursday, November 9, 2017

Getting started with Scrum

Here are some notes I've made to act as a prompt for new or newish Scrum Masters to look over ahead of a coaching session with an experienced Coach. The crux of the matter is that Scrum is designed to reveal problems and encourage certain useful patterns of behaviour, while setting the stage for ongoing improvement via inspection and adaptation.
  • What are you doing? How's it going?
  • Are you experiencing any of the common challenges listed below? Or other challenges?
  • Let's talk about it!
Further reading:
* * *
“Scrum isn’t a silver bullet; it’s a silver mirror.”
“Teams that finish early accelerate faster.”

Keys
  • Think of Scrum as a system for delivering and improving, that can itself be improved.
  • Understand the intent behind the practices; don’t just follow them ritually.
    • Ask “Why?” and don’t be satisfied with simplistic answers.

Scrum in a nutshell*
  • Set a sprint length of 1 to 4 weeks (and stick to it)
  • Start of sprint: Set a meaningful goal; pull an amount of work from the Product Backlog into the sprint backlog that you can reasonably expert to finish in the sprint, while reserving learning / improvement time, and saving some capacity for urgent, unplanned work
  • During the sprint:
    • Hold a daily stand-up
    • Hold a set number of refinement sessions during the sprint to help the Product Owner prepare the upcoming items nearing the top of the Product Backlog
    • Check completed work against your explicit Definition of Done
  • End of sprint: Review / demo, hold a retrospective

*This is a process view, and doesn’t get into the roles or finer points.

Some common challenges

  • Unfinished work at the end of the sprint
  • Learning / improvement time gets squeezed out
  • Coping with “surprises”
    • Unplanned work
    • Unexpected absences
    • Unexpected work item complexity
    • External blockers
    • Other impediments
  • Poorly defined work or acceptance criteria
  • Difficulty in breaking work into small chunks
  • Team members with “nothing to do”, and lacking the skills to help others
  • Uninspiring sprint reviews / demos
  • Retrospectives feel like a waste of time
  • Lack of follow through on retrospective actions