Monthly Archives: August 2014

How we can work smarter

Leave a reply

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?

ADOPTION OF AN AGILE LEAN MODEL

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

HOW THIS MODEL SUPPORTS TACKLING CHALLENGES HEAD ON

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?

Leave a reply

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

Leave a reply

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

Leave a reply

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

Leave a reply

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.