Read More
img_2508

Giving teams the best start

How you kick-off a team is important!   In fact it’s so important, that when you get it right your team can perform up to 30% better. That's what research by J. Richard Hackman tells us and it’s certainly consistent with my own observations.   What exactly is a kick-off? A kick-off...

Daily stand-up with a goal

Why your daily standup should be driven by a daily goal

Let’s face it, the daily standup can be a boring affair. I’m not talking about abominations with 16 people or half-hour long status reporting meetings. I’m talking about the ones that are kind of okay and adhere to the rules but nonetheless are a bit boring and lack focus and enthusiasm.
 

Personal Kanban as a Coaching Tool for Product Owners and Others

A while ago I wrote about Personal Kanban at Snapper. Personal Kanban, or KanbanFor1 as we call it, has supported Snapper’s Agile adoption and has proven an excellent training ground for the team to develop good habits and behaviours.

As in all Agile adoptions the delivery team aren’t the only ones affected by the change and in this post I describe how I have used personal Kanban as a co-coaching tool to help a Product Owner adapt to the challenges of his new job.

Interview with a newly-minted Scrum Master

Six months ago SilverStripe, an open-source Content Management System provider and Wellington web agency approached me to help them improve the way in which they deliver client and open source projects, increase employee happiness and, in general, just do the best possible job. To achieve this, we decided to move away from the existing Agile-like (fixed scope/fixed price) approach and introduce Scrum with its focus on client-driven iterations, early feedback and continuous improvement.

Silverstripe have asked me to interview some of their staff about the transition to Agile. The original posts can be found on Silverstripe’s blog (Sam MinnéeAleksandra Brewer), below are selected highlights from the interviews. 

When the coach needs to go

“When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.”
— Nanny McPhee (via Lyssa Adkins

 
I am an Agile coach and the goal of my job is to put myself out of a job. 
 
My mission is to teach people Agile and to make sure they understand and correctly apply Agile values, principles, frameworks and techniques. This is quite a big deal as Agile often forces us to change the way we work on a daily basis; how we organise our work, how we collaborate, which tasks we perform and how we communicate with each other and the rest of the organisation.
 

Even done is never done

A “done” definition in an Agile project is a statement that the team use to measure whether they’ve met all of the requirements for completing a userstory / feature (and in some cases completing an iteration or release). Done is one of the major shifts from doing Agile to being Agile.
 
So, what is “done”? Is it the quality mantra for the team? Is it the way we communicate completeness to the customer? Is it a process for eliminating waste? Is it about how we would like to work to bring about that “potentially shippable” product? It’s all of this but crucially belongs to the team, is created by the team, and is used as a measure of success. A “done” definition may look similar between teams but is never the same.