Toward the end of 2019, I was transferred to a new team at Toyota Australia, the Toyota Used Vehicle Platform. I would be the Scrum Master and UX Designer. We were tasked with bringing an improved experience to our visitors, and look to incorporate financial repayment options for these used vehicles.

The used vehicle site had been suffering from neglect. A product with great potential, but little attention.

I was incredibly lucky, the Product Manager involved gave me, and a super talented full stack developer(Andre) pretty much free reign, under one constraint; all vehicles that would be eligible for a finance option, i.e. a weekly repayment cost, needed to be live by March 2020. Whatever we wanted to do to improve the experience at the same time, we could.

So, Andre and I took huge advantage of this. We story mapped the exisiting site, using the Information Architecture as our starting point. From there, we could easily prioritise the biggest opportunities, and make plans on reducing risk and increasing our delivery speed.

The biggest question on our mind, was, how could we quickly and easily give visitors a weekly repayment option, if not on all cars, but a small subset? There was some complicated criteria for some of the vehicles, as to whether they were eligible, so we needed to find the quickest way to market.

We looked to firstly consider the user journey, make it easier for the user to “window shop” cars. We then considered what the business wanted, which was essentially more email leads being sent from our site straight out to all the Toyota dealerships around Australia. Finally, we thought about how we could pair back the design, only give the user the basic/essentially details, and in turn, make space for the financial repayment data to come into the design.

This was what we started with:

Our main assessment of the experience, was how unclear it was for the user. What were we asking them to do next? Once a user was scrolling, did we want them to click on a car, get their own car valued, or what?

We paired the UI back. We focused on making it clearer what we were asking the user to do. Essentially, we wanted them to enquire about a vehicle as quickly as possible, or look into the details of a vehicle a little more closely.

Once we arrived at the above UI, we got to work on the financing options available for our visitors. We wanted to get this out safely, but fast. We assessed our options and decided, the first release, would have the financing option display only when a user clicks on the “View details”. Through this approach we would test the stability a new API to one car at a time. If we could get that reliably working, we could increase the capability from there.

As we increased the financial repayment options on the UI, we continuously refined the experience, continuously stripping out unnecessary features, making it much more succinet and less demanding.

After testing our approach on a subset of vehicles, and increasing that subset incrementally, we built confidence in our product. If we caught bugs, wrote tests and ultimately released a stable new Used Vehicle experience.

All of this resulted in some amazing analytical results for a team of essentially two. Over a 6 month period, from Jan 2020 – June 2020 we saw a 97% increase in traffic and a 35% increase in user generated enquires as compared with the same 6 month period in 2019.

It astounds me what you can do with a tiny team, some trust from above and autonomy to get the job done.

Stories, users, and the art of slicing!

Stories, users, and learning

This month I had the pleasure of spending some time with Neil Killick(http://agilemelbourne.neilkillick.com/) and a few others learning all about story slicing. 
It was incredible. Yes, I realise, that’s a fairly strong statement, but I don’t think I’ve been in a situation before, where I’ve been able to apply so quickly what I had just learnt. 
I’m very fortunate to work for the best company in the world, literally, Salesforce.com has been ranked #1 by a whole heap of evaluators around the global. That means, I’ve got the space to try new things, and my colleagues are open to working in different ways.
Within hours of this session, I was able to take what Neil had taught us to work and apply it. Where once I had struggled to know what to do with a story, I feel I can now take it to the mincer and slice it in several ways to make it more feasible for everyone.

The following Monday following the session with Neil, I was sitting down with my team running a sprint planning event. During the session, we considered several “user stories” to take into the sprint. Having Neil’s guidance, I could, within moments, look at a story write it up on a whiteboard and apply Neil’s magical “Seams” approach to story slicing. I could quickly help our team break down our work into manageable chunks. By doing this, we could then focus on conversations about where we would be trying to add value. 
Not only could I help our team look at a story from a capability perspective, but when it came to implementing a solution, I was able to slow the team down from jumping behind the first solution that made sense. Thus, slicing the story from a functional and technical perspective. This allowed us to instead, do something Intuit are renowned for; going broad before going narrow.
Following on from reading Eric Ries latest book, The Startup Way, I did some Google hunting for Intuit. They have this approach to ideas. Rather than getting behind a single approach, they spend time thinking up as many possible ways of solving a problem before going deep on just a few. From Neil’s session, I was able to initiate a level of discussion that didn’t end abruptly by everyone getting behind just one option. We took some time to consider alternatives, which in the end actually led to a completely different solution being implemented then was thought of beforehand. This has saved us a least a week of time if not more, as I’m confident, if we hadn’t considered as many options as possible, we would have been a week or more into building a solution, only to realise a better way! We found this better way much sooner, or at least our degree of confidence in the way we are building out the solution now is higher and ultimately more considered.
Inside of learning about functional and technical slicing, Neil taught us a technique he refers to as the Hamburger method. It’s a simple approach to functional and technical slicing. I won’t go into too much detail, as you can experience it first hand by attending a session(here), but it’s a great tool for getting your team to hold off on jumping straight into one solution and to consider a multitude of alternatives. 
Since this session, I’ve noticed an improved confidence to take a statement or vision that an executive has for their project, and slice it up. This will help our team to start looking at quick ways to deliver value. I have found in the past that getting the backlog into a healthy state has been hard. One of the specific problems I’ve faced is initiating a backlog and getting it to a point of being “ready” for a build. I’m not saying by any means I’m all of a sudden perfect. But the ability to slice has helped take a statement/assumption and show how we might leverage it to give the development team something to look at and work with. This, of course, has meant, we can more quickly establish our priorities and build something. The benefits for me are huge, it means we’ll be at a point sooner rather than later where our team can inspect and adapt what we are building. 
Thanks, Neil!

Growing Pains

I’ve recently been reading up on Richard Feynman and watched a number of his lectures hosted by Microsoft. Bill Gates is a big fan and at some point, he came across a great lecture series of Richard Feynman’s(click here). Thankfully he’s made them publicly available through  Microsoft website.
From what I have read, the source is questionable, but Richard did not have the typical noble prize winning crazy high IQ. Which, is now a blessing for anyone who has an interest in self-development, as he had a number of famous methods employed to better understand a topic. From what I have read, he was clearly a very hard working, charismatic and disciplined individual.
One of the “techniques” he regularly employed was utilising a notebook to record all the topics, sub-topics and generally, things he didn’t know or understand. He furthered this process when learning a challenging topic, like Quantum Mechanics with his deliberate and brilliant process of simplification, he would continuously re-visit what he didn’t know about a topic and update his notebook overtime.
This is something I have been working on. Frequently I come across things I know little about but feel I should. At the moment I’m finishing up writing a business case for a Digital Customer Engagement project I’m lucky enough to be leading. Concerningly, my “I don’t know” note which I keep in Evernote, was getting larger and larger, given I need the paperwork ready soon, I’m somewhat relieved as I start to get more and more across the document. Mind you, this is mainly due to the great support I receive from the projects team I’m part of.
Through this process, I’ve started to see this large list as a good thing, almost like a marker that I can re-visit and track my understanding. A few weeks ago, if I was to sit down and detail what I don’t know about writing a business case it would have been very brief. A one-liner, simply and broadly stating “I don’t know where to begin”. Now after a little while on the topic, the areas I don’t know about are starting(emphasis on starting) to become more specific. I figure as you tackle a new topic, process, concept, theorem or in my case, a business case the more specific your “don’t knows” become, the further you’re probably progressing.
Unconscious incompetence, conscious incompetence, conscious competence, unconscious competence( Abraham Maslow – thank you, Katie). The Maslow framework springs to mind, in helping me understand the process, to some extent that I’m going through. A few days ago, I had no idea what I didn’t know. Now, I’m becoming more and more familiar with what I don’t know. If I was to offer some emotion around this point, I would feel right now, as I build a big list of what I don’t know,  is the scariest point. It can become overwhelming, and usually the point wherein you have to dig your heels in and fight to make progress. My mind is constantly trying to pull me out of this discomfort, as it’s a process that highlights how much I don’t know, so why not send an email, check twitter or jump on Instagram. I can do that, I’ve done emails before and checking social media is child’s play, I know how to. As much as I try to distract myself and protect my little ego in the moments of unknowing, it’s not going to get my business case done.
I would stagger a guess that this heightened discomfort, would commonly be the point where most get discouraged and make some attempt to not go any further. This is where Jack Dorsey or Mark Zuckerberg start sitting on my shoulder, reminding me how fun it would be to just check out some social channels. If they win, it can snowball into one hell of an unproductive period, and potentially worse, make a crap of my day.
Why is mindfulness important, because it’s at this point, I’ve found, I need to be the most self-aware I can be, to fight the urge to slouch, and muster some grit to fight for some tiny bit of progress. I’m sure reading/watching the latest hilarious act some cat has done would be fun, but it won’t give me much in the long term.
The stoic philosopher Epictetus comes to mind here:
“In life our first job is this, to divide and distinguish things into two categories: externals I cannot control, but the choices I make with regard to them I do control. Where will I find good and bad? In me, in my choices.” – Epictetus 

New Horizon

It’s been some time since I’ve had a clear path forward. From March 2017 until the end of August I’ve been working in my first Government position but only in an Acting capacity. The role has been interesting, having a team and in particular not having a project of my own. It has been a big learning experience, working for others rather than a project, offering where I could, some of my insights and prior experience to help. Some have been really appreciative, others not so much. Part of me feels I failed somewhat, for not creating a noticeable legacy. Another part of me feels I set things up so I could transition into my new role, overall I’m still not clear how I’m leaving that position.
My new job is excitedly the best role I’ve ever had, the potential is huge. I’m truly fortunate, I get to step back into the project world, working under an experienced highly accomplished project manager, now program manager, it’s my first project manager role in a truly agile delivery, and needless to say, I’m super pumped.
How can I say we are truly agile? Since mid-June, I have been on the job market, knowing the acting role would come to an end and not knowing that transitioning across to a project management role within Parks Victoria was possible, so I was all over seek.com.au. I was, of course, wrong and am indebted to Tim Tunbridge, Neale Tayler and Jen Rebeiro for making it happen. However, I digress, through the process of hunting for a job and discovering yet again “agile” is a hot topic, but still realising from an I.T. project management perspective mostly/largely misunderstood. A number of companies and jobs have talked to an “agile” environment, but probing a little deeper, discovering a traditional culture still prevails when it comes to projects.
In tech projects, a traditional approach would be referred to as a “waterfall” method, Prince2 and PMBOK are renowned methods in this type of delivery. Basically, waterfall lays out the work of a project sequentially(mostly), wherein; scope, time and money are fixed, but consequentially quality is variable. Agile is by-enlarge seen as the way projects should be operated, but when you start to get a feel for whether or not scope is variable, as would be the case in a truly agile project, companies, supervisors, program managers get highly uncomfortable.
Part of me understands that as project delivery goes, you must inform the business on what you will do, but there is a distinction that needs to be made here. Ideally a team would talk about requirements with an asterisk next to it, something along the lines of “we are not able to predict the future, however, from our analysis we believe addressing these organisational problems will return value to the business and we believe we can get X amount of work done in X amount of time. However, as we progress we will learn more and re-assess what we have delivered against our initial thinking and how much we have spent. From here we can make an informed decision on how we progress and even whether the project is still viable.
During my formal education(albeit a one week course, I’m an expert now!!!) on agile project management (DSDM), I was blown away by the concept that during a project, at key releases/milestones, the project control board, would actual re-assess whether it was worth continuing. This can often, at least at first, seem like a negative thing, but it ties back to Pareto’s 80/20 principle. With functional releases of a project you will realise benefits along the lifecycle of the project, but there very well could be a point wherein 80% of the benefits are realised and the remaining 20% is likely to have less of an impact. At this point, it’s potentially worth considering if that money required to deliver the remaining 20% is worth it, or perhaps better utilised re-investing into anther project that might have a greater impact with the same money.
Coming back to my earlier point. We are in an agile world now, wherein scope is variable, time is fixed, cost is fixed and quality is fixed. Other organisations and projects are possibly impeding their success before even beginning by fixing every aspect of a project. Lately, I’ve thought about it like quadratic equations, solving for X, while all your other elements are unknown
Even though based on the elements of the equation, we can assess what X is worth relative to the other we don’t come away with a distinct value. You could say the quality of our answer is compromised as it is dependent on others. A project, I believe must have distinct benefits, independent of others.
I’m not naive to think there will not be challenges ahead, however, at least I know that there is hope to deliver something great without compromising quality. I.T. has an extraordinary poor delivery record, (RE: Standish report “CHOAS), some 16% of all IT projects deliver, all the others fail in some manner. I’m hoping to work hard and diligently to be in that 16%.