Tag Archives: Agile

Where’s the teamwork when we can’t see each other

I’m an Australian working in the USA coaching highly distributed teams. We speak English but even then there are slight differences, like Australian English and American English and even within America like from South to North.

We find it’s hard to get people to use video cameras. They are cheap however the culture tends to not encourage use of them. It’s always hard to collaborate at the best of times and distribution would be a good excuse not to do that.

Seems most distributed companies can’t get past just the phone and a little screen sharing.  When we use just these, we can’t see each other’s facial expressions and body language.  It’s hard to know how to react to feelings and we have to assume or turn up our intonation sense when listening (perhaps even speakers and listeners can make more us of their voice to relay feelings).  Another big issue is having attention – where I work inattention is called ‘multi-tasking’ and we know that don’t work.

Overall, this is more a problem around the difficulties in collaborating and the fears around that.  We’ll need to work on that to allow the tools to be useful.  Make it safe.  Create the culture and camaraderie of teamwork and reward that.  Highlight even when people are doing things that harm teamwork via a team working agreement.  Realization can quickly occur after that and a team can self correct.

Then there is technology, my friend Agile Bill Krebs, is teaching and coaching on tools to assist the distributed work place.  There are simple tools like join.me which is down the low end of the spectrum through to immersive environments like Minecraft.

The technology is there – it just needs a willingness to try using it and adapting to use it to it’s utmost advantage.

Your last resort is to abandon the distributed model.  That can be avoided I suggest.



The Ladder of Leadership and Kanban

Here’s a comparison of David Marquet’s Ladder of Leadership which derives from his work as a nuclear submarine captain and writing his book Turn the Ship Around and then subsequent workshops and writings and the Kanban Method.

The Kanban Method says start where you are.  Other frameworks require a more explicit transformation to new roles and ceremonies.  The Kanban Method also says Improve Collaboratively and Evolve Experimentally (using models and the scientific method).  Of it’s 9 values it also states Leadership.  Acts of Leadership from every level.

A model that you can use to improve and create leadership from everyone is called the Ladder of Leadership (although not explicitly steeped in the scientific method, it is a model).  It starts where you are.  Everyone, and this doesn’t matter what position one holds, is looking to be told what to do.  This is where mostly everyone is.

The Ladder of Leadership recognizes this.  Everyone can use the model as a frame to help each move up the ladder to become more intentional.  By recognizing where someone is on the ladder whilst in conversation, a colleague can frame a question using the next rung on the opposite side of the ladder.

The Ladder of Leadership – Capt. Marquet

Measurement of success comes via a proxy from other measurements like faster cycle times, better quality (less failure demand) and people should be happier and if they aren’t something is still awry.

It takes some time to achieve this.  One must be prepared to stay the course despite the bumps in the road.  If it doesn’t work on one occasion, reflect upon that.  Realize we are humans, have a laugh and try again using what you’ve learnt.  The ultimate aim is to create leaders not followers.  Leaders can relieve bottlenecks and fix problems quicker and with more knowledge than someone further away from the problem.

Avoid the Workflow Masquerade

Here’s a tip for scrum teams.  You are almost certainly using a task board.  If not start today.

That task board typically consists of the standard TODO, Doing, Done style.  Sometimes you will see the Doing column divided up even further – some mature teams realise that but a lot don’t so here comes the tip.

Simple Board

Typical Simple Board

In doing sprint planning or planning for a User Story the team identifies a number of tasks required to complete the story.  For example, perform detailed analysis, code the UI, code the business logic, perform testing.

It turns out to be quite a laundry list of tasks.  Within that list is always a pattern.  That’s right always.  All your user stories almost certainly involve a component of analysis, coding and testing.

So the tip is to make that visible and stark to everyone viewing your board.  Evolve from the three column format of ToDo, Doing and Done and divide that Doing column into Analysis, Code and Test.

More Workflow Board

Go for this.  Workflow is visible

Whilst your at it, define some common policies for those columns.  For instance for coding – code and test UI, code and Test Business Logic layer and so on so forth.  That’s called your Definition of Done.

What does this do for the execution of the sprint?  Here are several things it can and should do.

  • Sprint Planning becomes more focused on asking real pertinent questions about what’s coming up rather than diversion on getting the laundry list together.  You could really ask the what if questions of the Product Owner and making a deeper start in technical implementation details and discerning the risky parts of the work.
  • Make the flow of work more visible.  This will increase the effectiveness of daily standup.  Speaking to the cards on the board and seeing where they are at, how long they have been in a part of the workflow causes more transparent and focused discussion of the work.  Of course the team should be willing to discuss the reality of the situation and some will refuse to do that even when it’s staring them in the face.  Note:  This is when the real rubber hits the road – the Scrum Master, Agile Project Manager will be willing to seek out help the team discover the causes and deal with the organisation impediments.
  • Show the real time for each part of development.  This can help the team improve on specific problem areas.  Because there is real data for each point of the process, the team can choose where to focus their improvement efforts to decrease the overall time to deliver.

So you may ask.  Is this Kanban.  The simple answer is no.  A Kanban System has more components – most importantly WIP limits on workflow steps.  However use of a these ideas more readily found in Kanban systems will still create visibility.  Evolution to more flow based systems could be an end result or perhaps just a hybrid like Scrumban.

So avoid the workflow masquerade.  Make those tasks into workflow and get on with real work.

Scrum Shortcuts the Video Series from Ilan Goldstein

Aussie Scrum expert Ilan Goldstein has made the perfect accompaniment to his handy book of scrum tips called Scrum Shortcuts without Cutting Corners.  It’s very handy reference to anyone wanting to get through those tough episodes we all experience in product development with its slant clearly on Scrum – I find the tips to have a universal appeal as well.  Here’s a bit of a summary and teaser for you to try the video series yourself.

On FrontRowAgile Ilan talks us through his tips and experiences by diving them up into five broad categories.

  • Planning and Protecting
  • Requirement Refinement
  • Establishing Estimates
  • Monitoring and Metrics
  • Reviews and Retrospectives

Planning and Protecting

Here we get tips on Sprint Planning.  Scrum tells us to do this to set up a goal for a team to deliver value to their customers.  There is important psychology that backs this up.  To quote Tim Lister and Tom DeMarco – ‘Providing lots of satisfying closure, one of the key elements of a chemistry-building strategy for organisations’  Maintaining a rhythm via sprints and the ceremonies within helps teams achieve results.

Visual representations help a lot.  The brain processes visual information 60000 times faster – from what I hear 🙂  So it follows that it would aid human psychology.  It’s more stimulating and we gain information just from passive observation.  So the task board is a central part of Scrum – actually the Scrum Guide tells us to use any visualization that makes sense and the task board almost always does.

In addition to this other visual artifacts help us like the sprint burndown and a prominent display of the Sprint Goal.  It becomes part of the team’s rituals.  Place them near the board.

A sprint is never without hurdles.  Visualize these (risks) as well.  A memory peg helps to CONTROL your issues.  The acronym helps as follows:

Confirm, Triage, Remove, Outline and Learn.  – Ilan explains more in the video 😉

Requirement Refinement

It’s important to divide stories into tasks.  A mistake is divide stories on a technical basis.  It’s common to see UI, Business Logic, Data Logic splits across an entire story.  Find a split that delivers a slice of functionality that cuts through the layers of technology and deliver that.  For example username/password of a Login story.

Sometimes we do need to deal with a technical requirement.  Try and fold those into something that is useful to the customer.  The use of user story format for technical stories is a bit of square peg in round hole.  Don’t sweat that if it happens.

A word on completing those stories and tasks with the well known definition of done.  That checklist that a team uses to ensure that when they say they are done they are done.  The team creates and owns this, but we do expect to see similar items across many software teams. Examples like unit tested and peer reviewed.  The DoD operates at task, story and release level – have one for each level.

Establishing Estimates

We learn about using story point estimation.  It’s useful to factor three planes into the estimation, namely Complexity, Repetition and Risk.  We don’t need detailed specs, rather other items to compare against – that is benchmarks from historical performance (or fake it til you make it – i.e. till you create history, use your best guess).  We learn about the approach to Planning Poker – a big take away is to incorporate diversity and it’s a common pitfall to assume experience is all that counts.  Some tips are provided on planning poker – rather than repeat them all (you should watch the video for that) some are re-estimate classes of stories when discovery of a wrong estimate occurs and to facilitate respectful debate on differing sized stories as opposed to a deconstruction.

Monitoring and Metrics

Metrics need to matter – rather than metrics matter.  They are a guide to inspect and adapt and not a tool or wedge against individuals.

Many teams find the sprint burndown chart to be useful as a guide on progress.  Used honestly it will highlight issues visually that a team can use to correct itself during a sprint (i.e. we aren’t going so well) or for when more work can be pulled in (we are doing well).  The same can be applied at the release level as well.

The daily scrum is an important monitoring ceremony. An effective standup is pivotal to being able to move tasks do a done state through the three questions (What I’ve been doing, What I intend to do and What is blocking me).  Keep it short and on topic and agree to fix issues outside the event.  To keep it interesting try by energising the event like throwing around a toy and change that up when it starts to wane.

Early and continual walkthroughs during the sprint are important for feedback from the PO and from others.  It will make the Sprint Review more of a tick and create a more valuable experience when that event occurs because it can focus on outcomes and looking ahead.  A walkthrough is a checkpoint that keeps us within the sprint goal and on track.

Reviews and Retrospectives

The Sprint Review is a momentus event and should be handled as such.  Be prepared with Demo Data and a real staging environment and not smoke and mirrors – the PO could say to roll forward to production with the increment.  Let the attendees know beforehand with an agenda and ensure the location is booked and setup with all that is necessary like a whiteboard and the hardware.

When running it consider it more like a collaborative workshop rather than a demo.  A two way exchange is therefore encouraged. Keep the meeting on topic with off-topic conversations acknowledged and agreed to be parked for later.  The development team gets a feel for what’s coming next and is able to ask questions around that.

Those receiving the product increment get a feel for how the team went about the delivery fostering an empathic view of the effort.  An enjoyable review is an indicator of success.

With the retrospective, the team has it’s all important opportunity to reflect and celebrate it’s wins and also to think deeply about where it can improve (invite the PO as well).  Ironically when the pressure is, is when it’s most useful.  Scrums values really do come into play in this event:

Scrums Values

Scrum Values

Some popular topics for focus are around communications, process, scope, quality, skills, environments with an aim to have actions that can be delivered in an upcoming sprint (don’t do them all if there are many – rank them).  Keep those actions visible near your task board.  A couple of interesting retrospective techniques are represented (circles and bubbles) with these suiting newer teams – with mature teams, just shooting the breeze works well.


Doing Scrum is more than going through the motions.  Ilan conveys throughout the videos this ethos.  Look deeper, be prepared for the hard stuff and learn from the experiences and everyone will be winners.  This video series will help with great tips to aid in your scrum and agile journey.

Edits to my Personal Manifesto

I documented my personal manifesto originally in this link.  It was useful to get it down on paper rather than a tacit understanding.  I think I should sharpen it up a bit.  It’s the same mostly – some wording has been modified.  I’m asking people to call me out when I err.

G(enuine) – Be honest, forthright and fair rather than vague, fake and invulnerable

R(espect) – Actively listen and respect (not necessarily agree with) the views of others rather than jump to hasty conclusions

I(ntegrity) – Uphold good human values and principles and avoid situations that are opposite to these

T(ransparency) – Be open about why, what and how rather than obfuscate, obscure or opaque

S(incere) –  Mean what we say via actions rather than being glib, hollow and lack of follow through.

Whilst we try and be all things on the left we sometimes recognize we fall into the poor behaviours on the right and seek to correct that.

Ok to be Mediocre, Ok to want to Improve

Last week I posted the following to twitter, somewhat inspired by Margaret Heffernan’s TED Talk on the Pecking Order and also by my own experiences in being interviewed and interviewing applicants for jobs (some ideas captured here in a earlier post/rant on broader dysfunctions).

Elitistism preventing New Hires

Some questions in interviews are valid but when it takes a demeaning, condescending tone – that’s when you know you’re in trouble.

Friend and colleague, Ryan Musgrave, in response, posted this video from Jacob Kaplan-Mosson (a self confessed mediorce programmer), which is related to the subject.  Those 10x programmers that some dream of hiring just aren’t as thick on the ground.  In fact hiring them could also reduce the through put of your team (read Five Dysfunctions of a Team to get a real life account of this).

We mostly fall in the middle for talent

We mostly fall in the middle for talent

We mostly fall in the middle of a normal distribution as the video explains.  It’s time to stop dreaming of hiring superstars and look to develop the skills of high potential applicants.  They needn’t know the Agile Principles off by heart or recite every little bit of Object Oriented doctrine that could easily be memorized anyway.

Look to test applicants on more meaningful questions about how they deal with technical problems, how they learn, how they deal with people problems.  Again these need not be perfect answers but should give you a feeling of potentiality.  Ultimately a good applicant wants to develop mastery in what they do.  Think of questions that will give you clues to this and give you a feeling of genuineness.

Ultimately Values, Principles and Philosophy should align best they can.  If your own Vision is strong then finding those who want to follow should not be hard.  As those looking to hire, perhaps starting there and looking inwards is the place to start.

Those feeling belittled by by the superstar programmer, take solace, also look inward and look to get the best out of yourself.  If your a superstar programmer and maybe not as generous to others in the team, you can improve as well by helping others to improve technically.  Collaboration is hard but does reap many benefits personally and for others and for the bottom line.

Knowing who your Customer Is, Is Useful

Most people involved in the development of solutions, be it software or otherwise, don’t get exposed to the customer or get a view of the customer that is filtered through someone else’s eyes like a Business Analyst or Product Manager.

Agile methods recognize that involving everyone in the process is useful to gain insights and empathy toward the customer.  For some not used to this it can feel ‘weird’.  Who needs this soft stuff.

However knowing the soft stuff is going to help deliver the hard stuff with greater accuracy (not precision).

A tool that assist is the Customer Empathy map that I have attendees to my Fundamentals of Agile course undertake.  They don’t feel confident about it, they feel like it’s ‘weird’.  However during the course of the exercise they soon pick up on the idea and find out things that they probably would not have thought of otherwise.


Even if the answers feel wrong, persist in this exercise.  That feeling of uncertainty or ‘weirdness’ will build to confidence and a feeling that we know more of the purpose of the product that we want to produce.

Hopefully we all feel happier with the end result, customer and supplier alike.