Agile Maturity Checks – Use with Caution!

Agile maturity check

Just saying it like it is. My favourite Agile maturity measure is the one in the picture above! I like to invite a team starting out in Agile to create a histogram of how they as individuals feel about their comfort level with Agile. I know that Agile maturity checks are loved by management, but I think they’re less useful to teams.

At work I put some time and thought into developing a maturity model that spans Lean system thinking, Lean Startup, Agile and DevOps practices. I modelled it on Spotify’s team health check, which I do feel is really useful. This maturity check was only moderately useful. I suspect that if you do use it, you’ll make an early maturity team feel a bit depressed and inadequate.

My thinking behind this model was to set the bar of early maturity where a non-Agile team taking their first steps might find themselves. My scale ranges all the way up to mature, which is good practice and I hope, not too aspirational.

It might be most useful to use components of it, if a team discloses a particular area they want to address. The next step might be to use a retro to generate ideas about how they could get from “not yet” to “on the way”.

Take a look at it and use with caution!

  Not yet On the way Mature
Standups We don’t run standups. We run standups sometimes. Standups tend to run over the 15 minute mark. We can’t always see the point of standups. We run standups every day and stick to the questions: what we did yesterday, what we did today, and what obstacles we need to resolve. Standups never exceed 15 mins.
Team rhythm As a team member I’m either too busy or not invited to attend all the Agile ceremonies – standup, estimation, sprint planning, showcase and retro. I mostly attend those ceremonies that I’m invited to – standup, estimation, sprint planning, showcase and retro. As a team member, I attend and contribute to all Agile ceremonies – standup, estimation, sprint planning, showcase and retro.
Process Our way of working is painful. Process gets in the way of us getting stuff done. We have a way of work that is sometimes easy and sometimes hard. It would be great if our process fit us better. Our way of working fits us perfectly. We have just enough process to get stuff done easily.
Speed We never seem to get done with anything. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies. We get through stories, but there are frequently blockers, or process glitches. We get stuff done really quickly. No waiting, no delays.
Requirements Our Agile stories are place-keepers for the work we do. We use BluePrint to articulate our requirements. We are using Agile user stories, but our stories are sometime technical tasks derived from specifications. Our stories are not consistently small, estimable, and independent Our user stories are not derived from a formal documentation process but are captured as business value. They are always small, estimable and independent. We always include acceptance and test criteria.
Analysis Time pressure usually prevents us from having our stories articulated before bringing them into a sprint. We do this during the sprint. Our aim is to get stories ready for a sprint, but accept that sometimes the work just needs to be done, so articulation of stories takes place during a sprint. We have a clear “Definition of Ready”, so we never bring stories into a sprint unless they are fully articulated, including a story statement, acceptance criteria and test criteria
Sizing We aren’t yet sizing our work before bringing it into a sprint. Several team members get together for sizing. We mostly have stories estimated before we bring them into a sprint. We have a regular rhythm of story sizing and involve the entire team in this process.
Velocity We use the stories in a sprint as a guideline or focus for our work. We never complete the stories we plan to complete in the sprint. We sometimes finish stories (including testing) in the sprint. As a team we always finish all the stories (including testing) we commit to in a sprint.
Sprint planning We aren’t yet conducting regular sprint planning. Several team members get together for sprint planning. Sprint planning usually happens, but we usually carry over stories not completed from the previous sprint. We have a regular rhythm of sprint planning that involves the entire team. We all commit to the work in the upcoming sprint and are confident we can complete it.
Agile wall We don’t yet have an Agile story wall. We have an Agile story wall, but it doesn’t necessarily reflect what we are working on, or what is in JIRA. Our Agile story wall is not hugely relevant for us in standups or our daily work. Our Agile story wall is our key source of truth about the progress in a sprint. Anyone looking at it can see exactly what we are working on and where we are up to. It matches what is in JIRA. We use it both in standups and the daily work we do.
Showcasing We aren’t yet showcasing. We showcase when we have something tangible to show stakeholders. This can be between every second and fourth sprint. We have working software to showcase after every sprint. We invite key stakeholders to this showcase and our developers run through what has been built.
Retrospectives & Learning We aren’t yet running retrospectives. We never have time to learn anything. We are too busy for retros and cross team showcases. Time permitting, we run retrospectives. This doesn’t necessarily happen after every sprint. We’re learning lots of interesting stuff all the time. We run retros every sprint. We initiate and participate in cross team showcases.
User experience support
We are struggling to understand what role User Experience designers play in defining our product and where they fit into the lifecycle. We sometimes tap into the skills of User Experience Designers, but often time pressure prevents us from working closely with them. We have complete clarity on the role of user experience designers in our product development. We integrate their work into stories across all product builds.
User experience integration
We often find we don’t have time or resources to integrate qualitative (through UX testing) or quantitative (through integration of analytics) customer learnings. We integrate some qualitative and quantitative customer learnings into what we build, but we rarely have an opportunity to run another iteration to further improve our product. We integrate qualitative customer learnings (through UX testing) and quantitative (through integration of analytics) into every feature/initiative we build and deploy.
Testing Testing is owned by the QA/Tester. Functional, non-functional and integration testing is performed at the end of the lifecycle, not necessarily within a sprint. Testing is shared by the QA and Dev. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Testing is owned by the QA, Dev and BA. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Developers practice Test Driven development (TDD).
Build Build is manually performed custom or repeatable, but still manual. Build is performed infrequently. One member of the team owns build. Build is repeatable and automated, but doesn’t happen with maximum frequency. Build is the responsibility of the team. Functional Testing tools (Watir, Selenium, etc) are integrated as gatekeeper events to the build. Integration tests with external tools and products.
Releasing Releases are extremely difficult. Our preference is to release at the end of the project. Releasing is tricky, so we aggregate as much work as possible before releasing. We have a regular rhythm for releasing. It is fast and painless
Collaboration & Communication We consistently find it difficult to get answers to our questions, or resolve issues in a timely way. It is sometimes difficult to get someone in our team to help us out, or resolve a problem when we need it. If we need somebody in the team’s opinion or assistance, we can freely ask that person either at standup or throughout the day and expect a prompt response.
Empowerment – ways of working It’s the job of leadership to suggest how we can work better. It’s sometimes difficult to get traction on improved ways of working, but we give it a go. We feel empowered to suggest how we can work better. Our suggestions translate to real improvements in the way we work.
Empowerment – product We don’t have any understanding of how the customers are responding to the product so we can’t calibrate it. We sometimes hear feedback about our customers’ responses to our product, but incrementing the product in response to this only sometimes happens. Our regular cycle it to respond to learnings from customers. It shapes our backlog.
Contribution We complete our work, but it’s not always clear how the tasks we are performing are critical to the success of the team. We know that the tasks we are performing are critical to the success of the team, but sometimes it doesn’t feel so – . Every day we are at work, we know how our work contributes to delivering a great product. We own creating a great product.
Fun &
Boooooooring. We do not celebrate successes. There are some smiles about, but celebrating success isn’t something we really do as a team. We have great fun working together. We find ways to celebrate our success.

What we can learn from our Lean cousins at Alcoa


A few weeks ago I visited the Alcoa rolling stock facility at Point Henry. The facility has been successful in producing high quality product and keeping market share in production of rolled aluminium of the sort used in the blanks for drink and food cans. A year ago though, predicting that it would be unable to keep pace with mega production facilities rapidly coming on line in China, the US parent company decided to close down the facility.

I was expecting my tour to be a somewhat depressing experience, given that we were just seven weeks away from the shut down. This couldn’t have been further from the truth. I was introduced to a bunch of highly motivated, highly skilled individuals, who not only knew their stuff about Lean, but who had developed a unique and effective approach to quality – one that us folk in the Agile world can learn from.

Alcoa introduced Lean at this plant in 2006. It was a top down, not negotiable introduction of this methodology. Lean experts from Toyota were brought in to provide consulting advice, but it was the effort of those on the ground who worked to transform culture and develop brilliant quality methodologies, that lead to the successful outcome.

The cultural change focused on:

  • Developing self-organising teams
  • Getting close to customers to understand quality
  • Reducing waste
  • Encouraging everyone to voice great ideas

It was in this environment of openness to great ideas, that the safety team, and then the quality team embedded an understanding that there are three ways that quality fails occur:

1. Automatic (or knowledge based)

When we complete a task which we have done many times and which we are highly familiar with, we are effectively on auto pilot. If someone were to ask you which red lights you stopped at on your way home from work, you’d most likely be unable to recall, because stopping at red lights is part of your automatic mindset. The quoted figure for individuals failing an automatic tasks is 1 in 1000.

2. Rule based

When we complete tasks based on a fixed rule, we mostly adhere to the rule. When driving home from work in the early hours of the morning, rules tell us that we should stop at a stop sign and not treat it as a give way sign. However the likelihood of an individual always adhering to this rule is reduced by comparison to automatic functions. The quoted figure for individuals failing to adhere to rule bound tasks is 1 in 100.

3. Unfamiliar (or skill based)

Where an individual is embarking on a new and unfamiliar task, the likelihood of error is obviously much higher. Driving on the other side of the road when travelling overseas is an example of where a familiar task is suddenly unfamiliar. Coming back to work after a break and finding that something such as the code base, has changed, is another time we are likely to make errors. The likelihood of quality failures in this situation is very high and is estimated to be at between 1 in 2 and 1 in 10.

The teams at Alcoa specifically respond to this by flagging during standup, whether tasks they are embarking on that day are automatic, rule based, or unfamiliar. Not only do they flag this, but the whole team actively identifies the likely error traps and discusses mitigation for these.

This struck me as an incredibly useful model for Agile teams eager to improve their quality. Before embarking on development tasks, encouraging the whole team to put their heads together to ask a bunch of questions. Are there any tasks we are embarking on that could adversely affect our code base or architecture? Will what we are doing today impact others in the organisation? What level of preparatory work might be required to reduce defects? Is what we are doing going to generate an unreasonable amount of waste? Have we taken into account lack of knowledge of any individuals about to embark on this task? Do we have all the information we need to commence this task? What are the likely error traps? How can we mitigate these? I’ve included a screen shot of the Alcoa pre-task checklist.

A bunch of other impressive quality measures also jumped out at me from the visit to Alcoa. During the transformation to Lean, the local implementers immediately recognised resistance to change as the key blocker to success. However as some people came on board with the new way of working, that involved clarity of roles, a huge degree of cross skilling and encouraging continuous improvement, what also emerged were individuals who showed initiative to lead the cultural change as “Champions”. Leveraging off the initiative of these individuals, quality champions became embedded in every team. It wasn’t their job to take sole responsibility for quality, but to keep abreast of best practice, teach the team and nurture initiatives and activities of those in the team. It’s true that in Agile we expect everyone to take responsibility for quality in every phase and in every build, but utilising the passion of someone who is a quality champion can help embed ownership of this within a team.

What impressed me most at Alcoa was the understanding that every Operator had about the customer who was buying their product. The guys knew where the rolled aluminium would be used, for what purpose and most importantly what level of defect would be tolerated in that product. In discussion with the Operators, I was reminded of the principle of trade-off sliders often used in Agile inceptions. Achieving a high level of quality is going to require a high level of input. In Agile inceptions and beyond, we aim to reach agreement on a time versus output scale. Perhaps we should also be asking what level of quality can we deliver for the time and cost? Do we need to discover more about our customer, to decide on the level of tolerable defects? Are our developers informed about who our customers are, or is it just the product people who understand this?

When Eric Reis in The Lean Statup talks about early adopters tolerating a higher degree of inconvenience given the often rudimentary nature of first implementations, should we too be asking questions about just how slick, defect free and seamless every implementation needs to be? Perhaps we should be asking – where does this drop sit in the implementation lifecycle, or how does return on investment fit with increasing our defect detection and remediation?

Being a typical Lean environment, there’s heaps more measurement at Alcoa than in the average Agile environment. Every morning, representatives across the entire production process meet in the “8:30 room”. It is of course named “the 8:30 room” because at 8:30am representatives from each team come together after their individual team standups, for a Scrum of Scrums. The 8:30 room is a glassed in area on the factory floor, which is home to the most massive and the most effective information radiator I have ever seen. Casting my eye over it, I could immediately see where specific teams were up to that day in terms of production, risks and issues. The focus of this communication is to validate dependencies and risks across the whole production process for that specific day. Targets versus actual output is discussed, as are quality and safety issues. Most importantly, with representatives from each team present, blockers can be immediately resolved.

Scrum of scrums is a practice I’ve seen implemented across various workplaces, but with varying degrees of success. It needs rules, and a rhythm, just as standups do. The scrum of scrums I’ve been involved in could have benefited from introduction of more measurement to validate where there were blockers affecting other teams. Keeping a greater focus on interdependencies and quality traps is something I’ll be much more likely to do after seeing this in action at Alcoa.

Finally to some cultural quality initiatives at Alcoa that really made my heart sing. I’ve previously blogged about the step in the product lifecycle at, which is simply called “Thinking”. At Alcoa “Bright Ideas” are an encouraged part of the quality lifecycle. The fun bit is that each week, the person who has suggested the best bright idea, gets to spin a wheel of fortune style wheel, with various dollar amounts on it. The winner also gets to nominate the charity to which the money will be donated. Some of these bright ideas go on to become Kaizen, or continuous improvement initiatives, while others are acknowledged as great ideas, but with lesser business value.

In the same way that flagging potential improvements is acknowledged, staff are also rewarded for “pulling the help chain”. An equivalent to Toyota’s Andon cord, the help chain is the signal to cease production. It’s a fundamental safeguard to protecting output quality. In Alcoa waste is easily quantifiable. Waste has to be re-smelted and go through the whole production process again. Once rolled aluminium is colour coated, re-smelting is even more expensive and it has to go to a specific smelter that can manage the toxic output of burning the colour coating.

In Agile we value quality at every stage of our production too. We acknowledge that quality at every step produces a quality end product. How could we do better on this though, by learning from our Lean cousins, not just to identify, but to quantify waste? If we implement an interface that hasn’t had the eye of a User Experience Designer caste over it, and the interface is not fit for purpose, the cost of this in the development lifecycle can easily be quantified. How much better would we do if we quantify the cost in our projects of not pulling the help chain when we spot code that will potentially break the code base, or activities that will introduce technical debt, or implementations that will adversely affect other teams!

Alcoa pre-task briefing

Alcoa pre-task briefing checklist



Teaching fun: the great pancake cookup


I recently attended a workshop on developing effective teams. The university I work for is in the earlyish stage of Agile maturity. I’m not. That’s why they’ve hired me. To introduce Agile and transform their digital team.

The workshop facilitator asked us to think about the most successful team experience we’ve had across our career and what made a successful team. The answers to this question came hard and fast – a great leader, enough resources, clarity of roles. I shouted out my answer along with the other participants – FUN! Silence descended on the room. All other participants looked at me. The facilitator responded, “no one has ever used that word to describe why a team was successful.

I discovered in that instant that in this organisation, needed to learn that work could also be fun.

I quickly devised a way for us to combine both an activity to embed a better understanding of story articulation, with teaching the team to have a bit of fun. This project, which in the planning phase I ran with the utmost seriousness, was labelled The Great Pancake Cookup.

The team was invited to an express project inception where we fleshed out our elevator pitch:

For the Digital Team
Who need to have fun through an inclusive team activity
The Great Pancake Cookup is a lunchtime event
That will allow us to enjoy a delicious meal we prepare ourselves, actualise how well we collaborate AND make all other staff insanely jealous as the delicious smell permeates the office.
Unlike other teams, our lunchtime event will not consist of soggy veal parmas or limp burgers, but express our inner Masterchef through both creative savoury and sweet pancakes.

The scene was set. We got right down to discussing our trade off sliders.

Time: We decided on one hour from prep to consumption – preferring to slightly supress our inner Masterchef in favour of having enough time to enjoy our meal.

Budget: We agreed to each kick in about the equivalent of what we’d normally spend on eating out for lunch.

Quality: This wasn’t something we were prepared to compromise on, as we had clarity on our customer base’s expectations – nothing less than scrumptious. We did agree to compromise on presentation though, given our time constraints.

Scope: As Product Owner, I really needed to temper scope creep. Yes – a choice of 10 savoury and 10 sweet toppings was attractive – for the breakfast buffet at the Hyatt Hotel, but could the consumers still feel delighted with perhaps 4 or each? I surveyed them and they thought there would still be good uptake.

The day of the event arrived. As Product Owner, I was busy approving stories so they could be moved into the done column:

As the Digital team, we want to have all the correct equipment available for cooking pancakes, so that we can successfully prepare our meal.

Acceptance criteria:

  • mixing bowl
  • power whisk
  • three electric frying pans
  • two broad blade spatulas (a link to an image of a spatula had been thoughtfully inserted into this acceptance criteria)
  • power board

As the Digital team, we want to have all the correct ingredients available for preparing and cooking pancake batter, so that we can successfully prepare our pancakes.

Acceptance criteria:

  • Self-raising flour
  • Back yard chook eggs
  • Lactose free milk
  • Oil for frying

The Devs were standing by about to plug in the three electric frying pans and ramp them up to 200 degrees. “Wait”, I yelled, “we may have forgotten to articulate one particular story:

As the Digital team, we want to ensure the electrical items we are using are tagged, so that we can comply with the university’s safety standards and so that we do not create an electrical failure, or worse, in the staff kitchen.

A quick consultation and we agreed that the risk of shorting the staff kitchen and leaving everyone else without the use of a microwave was outweighed by the benefit of pancakes. We compromised on using two frying pans.

The event was a huge success, on many fronts.

A team fairly new to Scrum, learnt the rudiments of project inception and story articulation

The team moved from what would be called in the early childhood education arena “parallel play” to “group play”.

We had fun!

We showed those around use that work can be fun.

Most importantly – The pancakes were super good.

What next?

We decided that soggy parmas and limp burgers are sometimes nice, particularly on a Friday when you can get a $10 deal at the local pub.

We also decided that when we do team lunches, we’ll take it in turns to bring in a bunch of moderately healthy stuff we can assemble ourselves. The foodies in the group bring home grown heritage tomatoes, sometimes it’s burritos or bagels and dips.

But it’s the “assemble it ourselves” part that’s important. The interaction of chopping veggies together, chatting while we wait in the queue at the microwave and sitting down to enjoy what we’ve prepared.





The Agile Manifesto updated


Image of Agile Manfesto courtesy of TWG

Despite loving it, I am uncomfortable with The Agile Manifesto. I get that it has come from the software development world. I get that it sought to drive better ways to create product and to create better product. I understand that it advocated for a new way of working not bogged down by processes, tools, contract negotiation and following a plan. I applaud that it advocated for individuals and interactions and customer collaboration and responding to change. What doesn’t work for me is that it makes a whole bunch of assumptions based on the software development world, that just aren’t right for the world in which Agile could now be applicable. So what could an Agile Manifesto for output that’s broader than just software development look like?

First to the assumptions. “Individuals and interactions over processes and tools” is the first statement in The Agile Manifesto. This has of course been the most controversial of all the manifesto’s statements. It was never the intention of the authors of the manifesto to throw the baby out with the bath water. The manifesto explicitly states that “while there is value in the items on the right, we value the items on the left more.” So, while processes and tools were seen as having value, individuals and interactions were seen as having more value. The assumptions in this statement are threefold:

  1. that processes and tools may not necessarily support the efforts of individuals
  2. that processes may be unwieldy, or that they contain ambiguity
  3. that tools introduce overhead and work for the sake of work, rather than contributing to working software, or output.

Agile doesn’t dismiss process. The use of a Kanban board, which at its most rudimentary level contains a “To Do”, “In Progress” and “Done” flow, is in fact a process. Put simply, it is a defined and agreed upon workflow process that creates a common understanding of how work is going to get to done.

Is there a way that the value of individuals and interactions could be articulated so as not to fuel critics of Agile who imagine that an Agile workplace is staffed by individuals doing their own thing, in the absence of a common understanding or common process?

With respect to tools, Agile seeks to disclose where the use of a tool serves no useful purpose in contributing to the output of a team. We know though, that in both the software world and beyond, there are a whole bunch of tools that are incredibly useful in creating more fit for purpose output. Using a Wiki as an information sharing tool has saved me hours of time. Google Analytics is a tool that has provided insight into how customers are using digital products, in a way that conversations about how we think customers are using products haven’t. Automation testing has helped fulfil on the Agile Principle of “simplicity – the art of maximising the amount of work not done”. Individuals and Interactions drive the best use of these tools, but tools certainly provide value. The Agile Manifesto was written in the pre app world, does it’s deprecation of tools over people and conversation align with our today environment?

How about “Working software over contract negotiation”? This statement is loaded with the frustration of software developers dying to get cracking on writing code, but being hampered by extended contract negotiation. We know of course that what this statement is really trying to convey is that Agile measures the value of what has been delivered in terms of the actual output. So, how could we remove the software development assumption from this statement, to ensure the message of delivering value through output is stated loud and clear and that the time involved in discussions that are not effective at defining what needs to be built, is flagged as waste?

The final item in the Agile Manifesto is “Responding to change over following a plan”. This statement has been used by critics of Agile to suggest that Agile doesn’t believe in planning. This couldn’t be further from the truth, as breaking features down into user stories with defined Acceptance Criteria is a more useful form of planning than typical Business Requirements Documents. We know of course that this manifesto item refers to acknowledging that as we learn more through developing a product, testing it in market and validating how users interact with it, we value adapting future iterations over sticking to the planned rollout. So how can we reflect the value of adaptive planning, pivoting, and planning only as much as you need, into an updated Agile Manifesto?

In my organisation we’ve embarked on a task to adapt the Agile Manifesto not just for a broader base than software developers, but also to remove some of the ambiguity in the manifesto and embed lean startup principles that closely align with Agile practice. This adaptation was the brainchild of my colleague Tim Hetherington, and to be perfectly honest I was a little sceptical about it at first. I didn’t mind explaining stuff to critics of the manifesto because I always found this to be an interesting conversation that lead to unpacking the manifesto’s values. But when Tim started articulating some reinterpreted manifesto principles, I was quickly convinced. Tim worked with Megan Capicchiano on the new manifesto statements below. It was my job to articulate each statement into a set of value dot points to describe what this looked like in day to day behaviour.

We’d love your feedback. Does this stuff resonate for non-software developers as well as software developers? Have we lost the essence of the original manifesto, or reinterpreted it for today? Are these principles accessible enough for organisations to accept? Could these new principles create cultural change in your organisation? Feel free to comment.

1. People and conversations over ambiguity and assumptions

  • We seek to understand requirements, resolve problems and collaborate through conversations, not emails or IM.
  • We recognise that conversation is the most effective way to disclose assumptions, clear ambiguity, share information and create common understanding.
  • We speak up when we perceive a simpler way of doing something.

2. Partnership collaboration over hierarchy and silos

  • We create partnerships between groups to work on customer centric solutions.
  • We use collaboration as a way of ensuring we are delivering the right outputs.
  • We commit to both stakeholders and delivery teams being involved for the duration of projects.
  • We strive to achieve organisation-wide strategic solutions that deliver shared value, rather than specific purpose implementations.
  • We trust individuals tasked with completing work, regardless of where they sit in the organisation’s hierarchy.

3. Quality and value of work over quantity

  • We recognise that limiting the amount of work in progress is the most efficient way for us to manage throughput.
  • We use a limited work in progress approach to prioritise delivery of the most valuable work within resource availability.
  • We ensure that we deliver the desired quality output by limiting work in progress and reviewing progress with stakeholders along the way.
  • We analyse our output to ensure our productivity and quality leads to continual improvement.

4. Delivering iterative business value over big bang roll-outs

  • We deliver incrementally to reduce the risk of big bang delivery that no longer aligns with customer expectations, current technology or market conditions.
  • We use iterative delivery to validate our assumptions, learn, and recalibrate as required.
  • We iterate to quickly deliver a minimum viable product, knowing that what we learn from this will ultimately create the most customer centric solution.

5. Continuous planning over inflexible planning

  • We prioritise planning the most important components, so we can deliver them first.
  • We see high value in targeted planning of the components being delivered first.
  • We accept that planning of subsequent features needs to happen once we have customer response to rollout of initial components
  • We see less value in planning components that have less certainty of being developed.

How we can work smarter

question markDeakin University’s CIO William Confalonieri’s paper The CIO Reborn. Emerging from a profound identity crisis to seize the future sets a number of challenges for enterprises, including the following:

  • How do we pioneer new customer engagement strategies?
  • What delivery models best fit the challenge of digital disruption?
  • How can workforce enablement make us more able to adapt to this new, still forming digital environment?
  • How do we build a culture of sustainable enterprise change?
  • How can we assist the business to reinvent itself from the front-end?

I would add to that list, how can we offset the financial risk associated with predicting our digital future?


An Agile Lean model sees enterprises utilising the following principles:

  • That business value based prioritisation will get rigorous consideration into planning
  • That self-managing cross functional teams are the engine room of adaptive delivery
  • That embedding a build-measure-learn cycle allows more attentive response to customers
  • That a mindset of continuous improvement will drive enterprise change
  • That incremental delivery will offset the financial risks of big bang delivery


New delivery models = better engagement with business

The key strength of Agile methodologies is intensive business engagement. In traditional projects the business provides requirements and then exits until the project is delivered. Using an Agile approach, the business works hand in glove with technology teams. The business is available on a daily basis to plan, answer questions and approve the incremental delivery of work.

Incremental delivery = offsetting financial risk

The risk of the big bang approach to technology delivery is twofold:

  1. Digital disruption may have changed the landscape by the time the project delivers
  2. Return on investment is not realised until the end of the project

Agile incremental delivery offsets these two risks by:

  1. Providing early delivery of features to fit an ever changing market
  2. Immediate return on investment through deploying the most highly prioritised features first

Improved customer engagement strategies = success

The following Lean Startup principles closely engage customers to enable enterprises to succeed:

  • Validated learning through testing our assumptions about our customers
  • More innovative accounting to set the right milestones and measure progress
  • Implementing a build-measure-learn cycle to understand how customers respond, and then learn whether to pivot or persevere. This accelerates the customer feedback loop.

Workforce enablement = greater engagement

Agile teams are self-managing and more productive than non-Agile teams. Teams are comprised of the following roles:

  • Product Owner – who defines what is going to be built and is the conduit to the business, primarily responsible for prioritising delivery of assets based on their business value
  • Scrum Master – the servant leader, who removes obstacles on behalf of the team, monitors in-build activity and manages the flow of reporting information
  • Developers – the engine room of the team who are empowered to suggest improvements to product features or team processes

Agile is a pull model, where teams commit to sustainable delivery of work, rather than a push model, where a Project Manager delegates work. This model of workforce enablement leads to greater engagement, idea generation and ability to respond to a still forming digital environment.

Building a culture of sustainable change = continuous improvement

Building a culture of sustainable enterprise change is a mindset change for many organisations. Organisations can foster change by:

  • Supporting teams in adopting the Agile practice of reflecting on how to become more effective, then tuning and adjusting accordingly
  • Creating opportunities for individuals and teams to learn about Agile best practice through brown bags and guest speakers whose ideas may rock our own
  • Encouraging continuous improvement, and investing in the technology and expertise to support it

Supporting business reinvention = creating new job roles

Enterprises need the right level of support to introduce the Agile Lean practices that will see them tackling challenges. Agile Lean Methodologies cover many concepts and principles and are not something simply learnt by attending a course. Key to supporting business reinvention is creation of job roles that fill the following gaps:

  • Provision of Agile coaching, to support practitioners in the delivery rhythm, until they become self-organising to deliver independently
  • Support for the Senior Leadership team on coming up to speed with Agile practices
  • Identification of gaps and opportunities for improvement in Agile practices
  • Development of an Agile framework that will fit both operational and project delivery teams
  • Examination of what program management means in an Agile context
  • Investigation and implementation of a model for scaled Agile delivery
  • Adoption of a successful model to encourage practitioners to share ideas through communities of practice within win outside of the organisation
  • Support to develop a greater emphasis on building the ability to measure into everything we build


How Lean can a pizza be?

lean-pizza_croppedThe other week a diverse group of Agile, Scrum and Lean practitioners from the Geelong area got together at the Waterfront Kitchen to figure out just how lean a pizza can be!

Lean startup is a method for developing businesses and products first proposed in 2011 by Eric Ries.  Based on his experience working in several US startups, Ries claims that businesses can shorten their product development cycles by adopting a combination of business hypothesis driven experimentation, iterative product releases, and what he calls validated learning.  The concept has wildly taken hold outside of the startup arena, as it promotes enterprises reducing market risks by iteratively building products or services to meet the needs of early customers, thereby sidestepping the need for huge initial project funding and expensive product or system launches and failures.

Lean startup aligns really closely with Agile, which harnesses an iterative, rather than extended development cycle to better fit product, system or process development to what users need or want.

Geelong Lean Coffee, the community of practice I founded some months ago to get Agile practitioners in Geelong meeting to share ideas, organised the event.  We teamed up with another newly formed community of practice, Geelong Entrepreneurs, to bring together likeminded professionals invested in using Agile, Scrum and Lean startup to succeed.  The evening was sponsored by Deakin University as a means to contribute to building economic, social and human capital and facilitate conversations about Agile in the Geelong and Deakin community.

The guest speaker for the evening was Simon Cuce, the Software Development Manager from Xero Accounting Software. Simon told the great story of how Xero have grown from a startup in 2006, to a globally successful enterprise using Agile, Lean and common sense. Topics covered included how best to manage the product backlog, good conduct at the daily standup, how Xero uses a variant of the Spotify “tribes” model, and much more.

What really impressed us was Simon’s description of the enabling culture at Xero.  It’s an environment where staff are empowered to do a great job and where innovative ideas easily bubble to the top.  At Xero, business value is equated with customer value and coupled with the Agile framework, teams can quickly pivot to get great features to market.

The benefit of events such as this, is that Agile practitioners can learn from others in the community and contribute their knowledge to building a Digital Geelong.  Some of the conversations on the night saw Geelong professionals collaborating with the guest speaker about spinoff ideas that utilise APIs to develop new products collaboratively with Xero.

We are enormously grateful for the university’s support of this event.  Being able to have access to the wonderful Waterfront Kitchen after hours provided a central venue for all to attend, and if you measure value based on the calorific content of the incredible salami pizzas served on the night, then all who attended could attest to the enormous value of the evening.

Applying Lean Startup thinking to product development

railway_station_500x377This morning on my way into work, I was traveling from a different train station. Totally unfamiliar with the station layout, I was for a moment, confused about which end of the platform to stand on. I would be exiting the train at Southern Cross station, and I wanted to be at the Collins St end of the platform when I exited. Another passenger must have registered my puzzled expression and asked me if he could help. I explained that I needed to commit to waiting for the train at one end of the platform, or at the other end, and that I would either be very wrong, or right. At that moment the thought struck me that this was a good analogy for Lean Startup thinking in product development. If I was right, then I’d have only a short walk to catch my next train. But if I was wrong, then I’d know just as soon as I arrived, and I could correct my path.

In his 2011 book, The Lean Startup, Eris Reis proposes that key to the success of new product ideas is testing your assumptions. Rather than launching with a fully-fledged product, on which you have expended huge amounts of effort and money, he advocates for pushing to market at least some features, to test your assumptions about what would be useful or attractive to customers. This allows you to fail early and inexpensively, or succeed early too!

There are a few approaches to this. One is what he calls “smoke and mirrors”, which is more an approximation of a product than the real thing. It provides some functionality for customers, but this is not necessarily driven by the end state processes or software. Instead it simply approximates the end state, so that you can test if the end state is going to meet customers’ expectations, ahead of investing in building the end state.

The advantage of taking this approach is pretty clear. You can validate your assumptions before investing the resources to build the end state. In the university, this type of model could apply if we were building a new online form to replace an existing process. Our product vision might be an end to end process that collects the information required from students and manages cross faculty exchange of information. Taking a Lean Startup approach, perhaps we could build an interface that collects the information, simply to validate that it will be compelling for students, but retains some manual manipulation of data, just until we validate we are collecting the right data and have created a form that is compelling enough for students to engage with. Obviously the “smoke and mirrors” manual part of the process can be replaced with a digital solution once we have validated our assumptions, and perhaps pivoted to find the optimal way to collect the initial information required.

Another way that Reis suggests arriving at an optimal product is through releasing something that may not entirely constitute a minimum viable product. He argues for putting aside our deeply held beliefs that we can only launch an end state high quality product. Where a product provides new and exciting functionality for users, assumptions about if it will be useful and compelling for users, also need to be tested. By launching with just one feature, instead of a planned 10 features, users can still interact with the product and provide feedback and requests for additional features that can be built in response to this.

In my work environment, this might look like us responding to some website feedback about a certain feature that users would like to see on the website. We might develop the beginnings of this feature and then advise the users who requested it to have a go at interacting with it. By engaging in a dialog with users around the beginnings of the feature, we are most likely to be able to shape it in such a way that it best fits users’ needs.

Resisting the urge to hold back until a fully featured version is available can be a huge mindset change. Essentially though, this type of scenario is typically played out with early adopters, who are the intelligence behind driving future features and pushing the boundaries of the Internet of Things. These users tend to be heaps more tolerant of early prototypes and appreciate engagement on development of product features.

My first scenario in this post was about being right, or very wrong. Obviously the stakes aren’t very high, when all I’m doing is choosing between which end of the train platform to stand on. The idea in Eric Reis’ Lean Startup model, accords with this though. Test your assumptions early and always, when the stakes aren’t high. Users will appreciate it, and so will those holding the purse strings to your product!

The “What’s next?” of Agile – Business value part 2

what-next-300x188Having covered some basic concepts of business value based prioritisation in my previous blog post, this one is for those who want to take the next leap into backlog grooming.

Prioritising initiatives based on business value makes sense, because it helps you see return on investment. But what happens when you have a whole bunch of initiatives that all contribute to something that is highly valued, such as improving user experience.

My team was recently in this situation. Scattered throughout our backlog were a whole bunch of stories that loosely fell under the umbrella of optimisation activities. Many of them didn’t have sponsors in the business, so there was no one to plead their case. Some of them couldn’t demonstrate a huge improvement in user experience, but would deliver efficiencies for our internal workflow, and hence help free up our time to deliver other initiatives with high business value. Some resolved what we call “technical debt”, which refers to the eventual consequences of poor system design, software architecture or software development within a codebase.

So, it was clear that these stories had business value, but how would we decide “What’s next?”.

I decided to go back to a classic Agile technique that sees you measure the business value of a story against the ease or difficulty in actualising it. My approach is always to involve the team, so I ran a workshop where we gave these stories their own time in the sun. We looked at each of the stories and rated their business value on a scale of 1 (low business value) to 3 (high business value). Then we rated the stories on 1 (easy to deliver) to 3 (hard to deliver). For each story we were able to derive a priority rating by dividing business value by ease of delivery. For example, we decided that creating reusable form assets had a business value of 3, and an easy of delivery of 3, so its priority score was 1 (3/3=1). Another story had a business value of 3 and an ease of delivery of 1, so its priority score was a 3. (3/1=3). This allowed this story to be prioritised above the reusable form assets.

When we ordered the stories we’d been grooming by their priority rating, the prioritisation felt pretty right!

This technique was useful for us, both because it made us really consider the stories and their business value, but also because it helped us truly prioritise pieces of work in our backlog. What we also learnt was the power of putting our heads together to make the assessment around “What’s next?”.

The “Why are we here?” of Agile – Business value part 1

why are we here questionI recently delivered some lectures to Deakin University undergraduate and graduate project management students on Agile. To get an idea of who was in the room, ahead of starting the planned presentation, I asked the students what they were studying. There was a smattering of business students, some computing students, a law student here or there and a bunch from diverse fields such as event and arts management. What would my message be to this assortment of students who would be working in fields so diverse from each other? That Agile is driven by prioritising delivery based on business value, but that business value looks very different depending on where you are!

I like to use examples drawn from my real world business experience, and in this case, it’s kind of obvious that when you are prioritising user stories within a backlog at Telstra Digital, you’ll be looking for those that will lead to increasing sales of products online and reducing costs of servicing customers through online self-service. User stories that accord with this business value will bubble to the top of the product backlog and within any epic, you’ll decided just how many stories deliver enough business value, before tackling the next epic that again delivers this business value.

I really liked the approach we took to assessing business value at Australia Post. Increasing revenue and reducing cost were on our menu of business value criteria, but we further categorised this into significant increase to revenue, or minor increase to revenue. We did likewise for cost reduction. This allowed us to prioritise a significant cost reduction initiative above a minor revenue increase initiative. We did take into account customer experience improvement initiatives, but these were always quantified in terms of how they would impact revenue increase or cost reduction.

In a university environment business value can be harder to quantify. At Deakin our measures are closely tied to our LIVE the Future 2020 Agenda. Learning relates to offering a brilliant experience where you are and where you want to go. Ideas relates to making a difference through world class innovation and research. Value relates to strengthening our communities, enabling our partners and enhancing our enterprise. Experience relates to delighting our students, our staff, our alumni and our friends.

So how do you truly evaluate if the products and features you are delivering add business value?

I like to ask the “Why are we here?” question. DeakinSync is Deakin University’s flagship online portal that allows students to access what they are likely to need in one place through a single logon, be it timetable, access to their school or faculty, email, industry placement info, or other important information. Students can even access the learning space, Cloud Deakin, to view lectures, interact with other students and submit assignments. The customer experience of DeakinSync as a single personalised experience for students is incredibly high, but once again its business value relates to how it aligns with the LIVE the Future Agenda.

The DeakinSync team know that the product’s rationale is to aggregate services and provide a fabulous experience for students, something we value very highly at Deakin University. By asking the “Why are we here?” question, it reminds the team that features still in their product backlog can be prioritised based on how closely they will align with product’s ability to enhance customer experience, drive retention, reduce costs associated with providing great experience and support Deakin as a sustainable enterprise. The message about business value then, should be that you need both to align with your enterprise’s core business drivers, but also to look at what your team individually contributes to this bottom line.

When playing pool in the kitchen is just that!

The other day, I was copied on an email at work. It was from the IT lead in my organisation.

It went something like this:

Last week, Katrina Kolt (that’s me!), took me on a tour of the facilities at the accounting software company MYOB. I was astonished to see at 10am on a Friday, two young guys in the kitchen, playing pool! No doubt, what they were actually doing, was collaborating on a difficult IT problem!

I responded:

I’m so glad you enjoyed the tour at MYOB. I did too. It is correct that it was Friday, and it was 10 o’clock, and there were indeed two guys in the kitchen, playing pool. I’m not sure though that they were collaborating on a difficult IT problem. I’m guessing that they were just playing pool.

What is true though, is that two team members who work hard, and then take time out to play pool together, will no doubt be able to collaborate on solving a difficult IT problem.

Agile values individuals and interactions and Agile processes promote sustainable development. When you saw two guys taking time out to play pool in the kitchen you saw both these principles in action.

When this guy, albeit in astonishment, referenced an Agile practice in that email, what he was really doing was acknowledging his learning, as a result of a field trip!


While it’s nice to turn up, look around a groovy office space, say thanks and depart, if you do that, then you won’t be making the most of a great opportunity.

First up – don’t take someone on a field trip, unless you have a clear vision of what outcome you want to achieve.

I’d worked really hard to get the IT lead to come out on a date with me. We were in the throes of designing our new office space, and I needed this guy to understand how an Agile office fit out could support Agile practices in our organisation. Things like no desk partitions to allow better communication, break out spaces for collaboration, large white boards with video conferencing facilities installed, to allow stand ups between distributed teams and a large area to hold spontaneous celebrations,


Make sure you provide background info to tour participants to help achieve your goal. In the case of this guy, who had no Agile knowledge ahead of meeting me, I put together an Agile primer. I engaged him in conversation about Agile ahead of the tour.

Your preparation also needs to include talking with the people who are hosting you, ahead of the day. Explain the purpose of the trip to them. Discuss a suggested agenda. Tell them heaps about who is going to be attending, what their understanding of Agile is, or is not, what level of detail to provide to the guests.

Explicitly check if it is Ok to stop the tour guide to ask questions, or to point something out to the people on the tour.

Check if it is Ok to take photos.

Playing on the day

On the day. Make sure you introduce the people who have come along. Don’t just say. Hi guys, this is my team from [insert organisation]. Make sure you make the tour guide aware of who’s who. This is John, he’s the  IT lead for my company. Use this as an opportunity to remind the people attending why they are here. John’s curious to see how you’ve set things up to support Agile because we are going through this process right now.

This is Paul, he’s our architect, and he’s designed a terrific office space for Envato. It supports Agile practices, but he’s keen to see how you’ve done it here in a much more scaled Agile environment.

When you see people “pairing”, then point out this behaviour to the tour participants. Don’t interrupt a stand-up, but listen in as chickens at a couple of different stand ups.

A good host will arrange for you to be able to chat with the Scrum Masters after the stand-ups, so that you can be walked through how different teams do stuff.

Use the different information radiators on the wall to initiate conversation. That’s what they are there for!

Make sure you thank your hosts and ply them with heaps of extremely unhealthy treats (in the proper Agile fashion) so that they can share these between the teams you visited.

The debrief

Immediately after an awesome tour, you’re going to need and want to chat about what you saw. Allow time for a coffee or lunch to have an informal conversation and compare notes.

But don’t just let the experience of the tour end there.

The learning bit

Make sure that you schedule some time to take staff offline for a couple of hours, so that you can do something with the learnings from the field trip.

After our trip to MYOB I collaborated with the IT lead, to design our new office space.

If you are taking an Agile team on a field trip, think about a workshop that asks three key questions:

  1. What Agile principles do we utilise in our workplace?
  2. What Agile principles did we see in action at MYOB?
  3. How can we adopt some of these to improve the way we do things?

You can create large visual charts with this info to display around the place, so that other teams can learn too.

The wrap

So, back to the IT lead – there have been a few wins:

  • He now knows my name!
  • I got to be involved in designing our new work space!
  • I now have an Agile champion in the organisation.