Read More
An Outdated Principle?

Time for a Change in Principles?

As Agilists, our principles and values underpin the way we work and decisions we make. A good principle should be timeless and non-prescriptive enough to be valid across many contexts, but specific enough to add practical value and help us make decisions.

 

I feel that one Agile Manifesto principle in particular has frustratingly failed to stand the test of time:

 


“Working software is the primary measure of progress”


 

I disagree strongly. Working software is only a measure that more software exists, which is not the same thing as progress!

Read More
Customer Interview Cartoon

Is Talking to Users Enough?

Recently a friend of mine formed a startup with a goal of making the One-On-One Meeting an easier and more valuable process. Their aim was to help managers and their direct reports easier handle the goals and issues that arise from these sessions. The assumption they made was that their customers (primarily managers of developers and testers in IT companies) would pay a subscription fee to use their application, which would allow them to avoid manually recording, tracking and sharing all of these in spreadsheets.

 

My friend (an experienced and passionate Agilist) first decided to talk to potential customers to test the viability of the idea and to determine if they had achieved a Problem/Solution fit. As it happened, two of the potential customers she interviewed work for a client of mine. After the interview, my friend came away positive that her product would solve a problem for these two potential customers at least, and that they’d pay for it. So far, so good right?

Risk registers and meetings are boring – try a project premortem instead …

What is a premortem?

A premortem is a project postmortem that’s run before a project. During a postmortem people analyse and discuss what went wrong, what went well and what could be improved.

While postmortems are very useful the problem is that by the time we run them the project is usually over and not much can be done about success and failure.

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.

Evolving the Story map

I can’t say enough about how useful story maps are and how essential they are on any Agile project. Jeff Pattonis the undisputed (certainly in my mind) master of the story map and it’s well worth looking at the materials on his site. Jeff summarises a story map as, “A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do.

 

Agile Project Inception with a Press Release

I really like Jonathan Rasmussen’s project inception deck as a simple, quick and cut-to-the-chase way of kicking off projects. Overall, I pretty much stick to Jonathan’s content and flow, but sometimes, I use a press release exercise instead of a product box. The idea of refining a product vision through writing a press release has originally been used by Amazon.com as a mechanism to determine whether a product or service should be built.

Business Modelling

The team from Bright Ideas Challenge have put together an excellent resource list for anyone starting off on the great startup journey. Last year I was not quite prepared enough to get through their process, hopefully this year I’ll have my plans in better shape. They were extremely helpful in the brief interaction I did have and look to provide valuable support to entrepreneurs and businesses getting underway.
 
I have to say though I struggle to get past the sheer awfulness of this presentation from one of their experts – in terms of layout, design and conveying information it’s hard to give credibility to someone who so blatantly misses the mark of how to present information. To be fair he does a better job in person than via powerpoint … but still.
 

A template for the sprint review

Conducting an interesting and engaging end-of-sprint review is an often overlooked art: Not only do we want to show what we have built during the last sprint and collect feedback and good ideas for what to build next; we also want to give our audience a good experience. 

At my workplace we always invite the entire company and often have more than 30 people in the room. As they claim to be happy and to enjoy the fortnightly experience I thought it might be useful to share our template and some guidelines for what is working for us.

A Scrum Product Owner checklist

After my last post on the role of the Scrum Master I have been asked if I could write a similar role description for the Scrum Product Owner. 

Here’s my view of the role: 
 

The Product Owner

 
The product owner is a visionary who can envision the final product and communicate the vision. 
 
The product owner is also the person who sees the vision through to completion. This includes describing features, collaborating and communicating with the delivery team, accepting or rejecting work results, and steering the project by tracking and forecasting its progress. 
 
The Product Owner points the team at the right target, the Scrum Master helps the team get to the target as efficiently as possible. In other words: The product owner is the what-person, the Scrum team are the how-people.
 

In general the Product Owner …

 

  • is responsible for that the team builds the right product
  • manages ROI and makes sure to deliver business benefits

Agile undercover – when customers don’t collaborate

The other night I attended Rashina Hoda’s totally awesome presentation “Agile Undercover: When Customers don’t collaborate” at the Wellington Agile Professionals Network.

Rashina presented the research she had conducted on the basis of interviewing 30 people across 16 organisations in New Zealand and India. Having delivered a steady supply of Agile teams and individuals over the years I was excited to see the results of Rashina’s research.

Her chosen method of research was grounded theory which basically means that instead of testing a pre-conceived theory the researcher gathers data and generates a theory based on the data collected. A bit like Google Flu Trends …

How story points work

One of my clients is a small software development house that does custom development in the form of development projects for clients . I helped them to successfully introduce Agile (Scrum with XP) and both the team and business managers are really happy with it. 

As they liked our methods of planning and estimating (story points and velocity) the account managers and sales team were discussing the options to relate story points to dollar values. 
 
To explain why I think this is very risky and not advisable I wanted to give them some background.
 
“How big” vs. “How long”
Story points are units that are used to size a piece of functionality or work. Sizing in this case means that story points indicate “how big” a piece of work is. 
 
This is often confused with “how long” it takes to implement it but in fact “how big” and “how long” are very different things:  

  • The “how long” is highly dependent on which developer is performing the work 
  • The “how big” bears no relationship to who is performing the work