Monthly Archives: January 2016

The key indicator of successful Agile transformation

Leave a reply
Beware of cows

Photo: enjosmith, Flikr

Is sustainably faster delivery of customer focused solutions the key measure of a successful Agile transformation?

It’s a great measure, but it is of course a lagging indicator and not a leading indicator. By this I mean that you can’t know if you have achieved faster time to market until you have achieved it.

What leading indicators (or factors that change before a system starts to follow a pattern) can you measure and influence to see success in Agile transformation?

Brad Swanson’s approach to measuring leading indicators that influence sustainably faster delivery of customer focused solutions is terrific. I’ve adapted it here and added more:

Alignment of organisational priorities with customer value

  • How frequently do stakeholders collaborate on prioritisation?
  • How effectively are they collaborating?
  • Is there a standard way to compare the business value of initiatives?
  • Are portfolio priorities highly visible?

Growth of Agile practices

  • How many people are trained in Agile?
  • How many people in teams are coached?
  • How many leaders are coached?
  • How many Agile practices are leaders using?

Alignment and support across the organisation

  • Is there senior leadership consensus on strategy?
  • How frequent are communications on vision and strategy?
  • Across what different forums is vision and strategy communicated?
  • Are short-term wins visibly celebrated?
  • How many hours is the Guiding Coalition working on activities?

Engaged happy people

  • When polled, do people feel things are getting better or worse?
  • Are there defined career paths for all roles?

Culture of continuous learning & improvement

  • What is the average frequency of team retrospectives?
  • When polled, do people feel safe to experiment and fail?
  • What is the number of experimental learnings celebrated?

Transparent empirical view of organisational improvement

  • Are metrics on organisational improvement visible to all?
  • Are results communicated?

Incremental delivery

  • How many projects are running concurrently?
  • What is the average number of concurrent projects per person?
  • How healthy are the program burn up charts?

So if you’re looking to tell the story of Agile transformation on a single slide, by all means map deployment frequency. The rest of the story is of course in measuring and influencing the above leading indicators of success.

The 3 key questions to get a user story to “Ready”

Leave a reply

Sample KanbanCoaching Agile Scrum and Kanban teams, I frequently see bottlenecks when user stories that aren’t quite “Ready” find their way into development.

These three questions confirm if a story is “Ready” to be brought into a sprint, or pulled into the in-progress column in a Kanban flow.

1.  Are the boundaries of the story clear?

A good story statement should confirm where the user story starts and ends. For example: As a user who has logged in and wishes to update my password, I want to see an update password screen, so that I can enter a new password and hit submit. The acceptance criteria for this user story will confirm what the update password screen needs to look like, validation rules for the new password and encryption of the password.

A team reviewing this user story would understand that a response screen is not within the boundaries of this user story and will need to be covered in another user story.

 2. Do we know how to build and test this story?

Ask this question to disclose if the people building and testing the story have complete clarity on how they are going to do it. If the answer to this question is “No”, then the story isn’t “Ready” and the team needs to run a tech spike or research spike.

 3. Is the story small enough?

My (frequently articulated) preference is for small stories. I like small stories for all the reasons above – the boundaries are clear and it’s easier to validate we know how to build them. I also like small stories because you can easily bring them into a sprint or Kanban flow without sizing them.

If you are running Scrum and sizing stories, what’s critical is to ask if the story is small enough to complete within a sprint.

Kanban teams will be acutely aware that any story that is too big will create a flow problem, preventing other stories from being pulled into in-progress. To improve your average lead time from, for example, two weeks to one week, ask the question “Is this story small enough to be completed in a week?” If the answer is “No”, then use your toolbox of story splitting techniques to break it down further.

What Agile Teams Learn from Toyota about Definition of Ready

Leave a reply
What Agile Teams Learn from Toyota

Photo: Toyota Manufacturing UK – Assembly, Flikr

Getting stories to “ready” is crazily important for Agile teams. My recent field trip to Toyota made me think more broadly about what ready means.

By “ready” I’m referring to having stories articulated ahead of a sprint commencing. I usually advise software teams to include the following in their “Definition of Ready” (their checklist of what needs to be done before a story can be commenced):

  • Clear story statement
  • Articulated acceptance criteria
  • Reference to a process map (if required)
  • Wireframe (if required)
  • The team understands the story
  • It has the Product Owner thumbs up

The Toyota equivalent of ready is a self-driving trolley that arrives at the operator’s station just in time to supply, for example, the wheels for the next vehicle on the assembly line. The passage of self-driving trolleys around the factory floor, playing individual music to alert the operator of approach, is in and of itself ridiculously impressive.

It is Toyota’s lean approach to managing the whole supply chain though, with offsite manufacturers producing, packaging and dispatching the various wheels in the correct order, that takes ready to a whole other level.

What can Agile teams learn from this?

Remember that you are part of a system – seek to include your stakeholders in getting to ready

Ask yourself, who in Legal, Product, Marketing, Learning or Architecture needs to understand, or be involved in defining the story before it is considered ready?

Value your suppliers – they are critical to your system

Toyota understands that their success depend on their suppliers. They provide clarity of expectations.

Influence your ecosystem – educate as required

Do all your stakeholders or suppliers understand their role in Agile product development? If not, find a way to explain it to them and support them as they come up to speed.

Listen to your Developers – they understand ready better than anyone.

At Toyota, if wheels don’t arrive at the right moment, fitting them cannot be completed within the takt time. Our takt time is a sprint. We should have no lesser sense of urgency than Toyota’s 90 second takt time. Ask Developers ahead of a sprint, “Do you have everything you need to complete this story?”, and listen to their response.

Make your team’s model “ready set flow”

Emphasise the connection between ready and overall sprint flow. Encourage Product Owners and Business Analysts to make the workflow of getting stories to ready visible on an Agile wall. Get them talking about these efforts at standup, so everyone in the team feels empowered to flag obstacles to ready.

How small Agile teams succeed – & win wine of the year!

Leave a reply
How small Agile teams succeed

Photo: Tim Williams, Flikr

Late last year, Australian wine critic James Halliday, selected a micro winery’s 2014 Shiraz Viognier, as Australian wine of the year. Asked on radio, how the tiny Serrat winery’s $40 bottle of wine, could compete with big wineries, he responded, “it’s attention to detail”. That of course got me thinking about how small Agile teams create quality.

James Halliday expressed better than I, why small creates greatness.

“You have to get the vines absolutely performing at maximum, in terms of quality, not in terms of yield. Because they are by their very nature, small, you can move very quickly. There’s just a very small number of people in the decision making process. There’s no chain of command, or stuff like that. So they decide… let’s pick tomorrow, and no one’s going to say otherwise. Whereas in a big company, you get log jams of grapes coming in from all over the place.”

Small Agile teams succeed because with small there is big communication:

  • Decision making about how to build is by the team
  • The Scrum Master knows where each team member is at, and supports individuals achieve excellence
  • Handoffs are conversations that focus on what’s happened before, and what happens next
  • Each person cares about quality
  • Small can move fast and flex as required

Is small better than big? Well, in terms of wine, it’s certainly cheaper than the $875 a bottle Penfolds Grange that was runner up!

Easy Peasy Agile Leadership

Leave a reply
Easy Peasy Agile Leadership

Photo: D Sharon Pruitt, Flikr

I work in Agile transformation, and the truth is, it’s not so easy peasy teaching leaders to change their style. The thing is, the effort to change leaders’ mindsets is worthwhile – it enables Agile teams to thrive.

Traditional managers think like this…

  • I am the manager of my people
  • My team looks to me to solve their problems
  • I shape how individuals and teams work
  • I reward individuals and teams who do whatever it takes to get over the line
  • I expect individuals to develop a learning plan, and if time and budget permit, I support them achieving it
  • I endeavour to reward team achievement at the end of a project, and individual achievement at performance reviews
  • I encourage individuals and teams to innovate, but there’s rarely time to do so

 Agile leaders think like this…

  • I lead through vision, but support as a servant
  • I set the mission, but decentralise problem solving
  • I trust individuals and teams to shape how they work
  • I reward individuals and teams who work at a constant sustainable development pace
  • I am a driver for development of learning opportunities, and make time for my people to achieve their goals
  • I acknowledge the achievements of individuals and teams spontaneously, and encourage celebration of success
  • I foster an innovation culture of cooperation, risk sharing and acceptance of failure in order to learn

What case do you put to leaders to make their mindset Agile?

Agile Leadership:

  • Supports teams working Agile, so we build better products and release more frequently
  • Emphasises continuous improvement, so teams become more productive
  • Increases sharing of best practice, so we keep upskilling our teams
  • Gets teams working at a sustainable pace, so there are fewer absences
  • Enables happier, more autonomous humans, so we retain our people
  • Builds an engaging workplace, so potential employees choose to work for us

If leaders in your organisation still aren’t convinced, then think about quantifying the benefit of better products more frequently, more productive skilled teams and retaining great people!