Get your #agileaus fix

Whether you want to build new habits for lean learning using Kata, acquire new approaches to Agile leadership, want to accelerate your innovation using a design sprint, or learn how to keep the cost of change lower for longer then get your Agile squad together to watch these new videos. Presentations from Agile Australia 2016 are now available on the InfoQ website.

Choose from:

Kata – habits for lean learning with Håkan Forss


Agile leadership: an approach for leaders in large-scale and start-up companies with Lisa Frazier


Using a design sprint to accelerate innovation with Rob Alford and Rob Scherer, SEEK


Event Sourcery – Keep the cost of changer lower for longer with Sebastian von Conrad and James Ross, Envato


All Agile Australia videos are available online at InfoQ.

Posted in Agile Australia 2016, Education, InfoQ, Kata | Leave a comment

Fixing Apple’s Fingerprint Login in 12 hours


Today Agile Encore speaker, Emma Carter joins us with another insightful guest post. Emma will be presenting at the upcoming Agile Encore on Thursday 10 November 2016 in Sydney.

Fixing Apple’s Fingerprint Login in 12 hours

Setting the Scene

My team and I were excited by the prospect of adding fingerprint login to the iOS version of our banking App. It was something our users had been asking for. As a team, we wanted to try out the new technology and create a more user friendly and quick way for customers to login and access their bank information.

As a team (comprising of Developers, BAs, QAs and myself for XD), we’d considered different user scenarios and security issues for fingerprint login. We’d researched how other Apps had implemented this  functionality; but the more we delved into how Apple required us to implement their API, the more I questioned the usability for the end user.

The functionality was fairly new in the marketplace. Although users were familiar with unlocking their phones using TouchID, I was skeptical if they would find the process of logging in to the banking App with their fingerprint (over a pin) intuitive.

Our App was receiving great reviews and had won awards for the user experience it provided. Although we had time constraints, I didn’t want a third party API to undo all the hard work that had gone into creating a great experience.

[When comparing Android and Apple, we had found that Android had solved the concerns we had with Apple, but the actual scanning mechanism on the button was better on Apple. Ideally, for the optimum experience you need to combine both solutions.]

Your Time Starts Now!

We release an updated version of the bank App every 6-8 weeks. With each release we not only add new features – fingerprint login or eStatements, for example; we also needed to ensure that it created the best experience for the user, met stakeholder requirements and was within the budget. Therefore, user testing couldn’t be a drawn out process which lasted several days. I had one day to user-test the fingerprint login.

Who to Test?

Although the main target audience of the App is the baby boomer generation, the app does have a lot of users in the lower age brackets.Taking this into consideration, we conducted our user testing across different age groups, some of whom were already TouchID users. Having a good mix allowed us to understand if problems were consistent across the board, which would, in turn, allow us to create a better experience for all users.

Morning session

Luckily, for the user testing, we already had a production build of the App. This allowed the user to experience the entire process of registering and scanning a fingerprint. We started by asking them to register their fingerprint on the iPhone (the App would allow users to set-up a fingerprint login only if their fingerprint was already registered on the device). Taking them through this process allowed us to create an ‘as real to life’ experience as possible, under the conditions. They were then asked to login to the App and complete the flow to setup the fingerprint login for mobile banking. Users passed this process without any concerns.

Apple TouchID example

It was in the next process that we asked users to complete which validated our concerns. After registering their fingerprint on the device and completing the flow inside the App, they had to login with their fingerprint. We asked them to log out of the App and log back in using their fingerprint. Once they tapped the ‘login with fingerprint’ button, the standard Apple TouchID modal appeared. At this point, the user is meant to scan their fingerprint. Instead, we saw the user instantly getting confused and quickly frustrated as they tried various ways to get it to work.

Problems with Apple TouchID

What was so confusing?

I had concerns that the restrictions and style of the modal would confuse users. On observing users and chatting with them, these concerns were proven.

Once the modal was activated, people saw what they thought was an error message, even though they had been shown a similar modal when unlocking their phone. In this new context, they panicked and pressed ‘cancel’, which meant that they had to start the login process again.

From regular user testing that we do for every release of the mobile App, we’ve noticed that people, particularly a younger audience, simply don’t read lengthy text. They dismiss information in the screen or inside a modal, and simply click the ‘ok’ button during onboarding flows, rather than reading what they are doing. After several failed attempts of trying to login with their fingerprint, they finally read what little copy was available inside the modal, but this just confused them more. Most gave up and logged in with their pin.

Issues with Apple TouchID

  • Everything about the modal design looks like an error message
  • The icon is red. Red represents danger or error in a majority of countries
  • The hierarchy of the text is incorrect. The name of the App and the ‘cancel’ button are more prominent than the call to action or localised reason as Apple refers to it .
  • Restrictions imposed by Apple:
  • Apple only allows third parties to edit the localised reason, resulting in the App name being more prominent.
  • The number of characters for the localised reason is also restricted, resulting in the instructions being very vague and unhelpful for the user.
  • The modal activates a dark screen, which prevents us from adding any useful information or directional arrows that say ‘scan here’.

Throughout the testing process, only one user instantly understood what was required. On further questioning, she revealed that she had used the same functionality with another bank. She said that she was initially frustrated, but eventually understood how it worked.


After we’d finished the morning session of testing, we decided we had enough information to confirm our concerns, even though we’d only tested a small number of users. To fully maximise the time we had, we felt it was best to spend the testing session in the afternoon trying alternative solutions.

Adding a simple set of text instructions above the login button would be very quick to implement; however, we knew that our users seldom read text that was more than a few words long. This made it a less than ideal solution. Adding a simple arrow below the modal to say ‘scan your finger here’ would have been more intuitive, but this was prevented by the Apple API.

I sketched two paper prototypes to test:

Paper prototypes to fix the Apple TouchID problem

Prototype A: We gave the user a set of written instructions. This would be the quickest to build, but knowing our users, we weren’t convinced this was the best solution.

Prototype B: We used a visual graphic with very short text.

Afternoon Testing Session:

We went through the same process of registering the fingerprint and setting it up within the App on the device. We then moved to the paper prototype flow to test our new versions. We conducted these tests with a new set of users. We also managed to ask some of the users from the morning session which of the new prototypes they preferred.

The Results:

Very quickly, we realised that our users preferred the visual graphic approach. By visually showing them the action rather than explaining it, we made it far easier to understand.

Late in the Day and Running out of Time!

We had validated our concerns and tested two options. The more complex option was the preferred one, but did we have the time to implement it?

Although the team had been kept informed of our findings throughout the day, and the main stakeholder had been involved in the user testing, we still needed to decide as a team what we were going to do, given the time it would take to implement this on iPhones, iPads and then test it.

We gathered the entire team together to share what we had discovered and the two possible solutions. Although option A was far easier to implement we decided that option B would give the best experience.

We were up against the clock. I paired with our lead developer which meant he could start building the page, while I created the graphics. By the following morning, the new flow had been implemented across all iOS devices which had TouchID capabilities.

Final Solution for Apple TouchID app

Final Solution

For any onboarding flows, we usually present the user with large ‘Ok’ or ‘Cancel’ buttons. However, for our new help screen, we wanted to change this usual behavior (of tapping a large ‘OK’ button to proceed), to ensure that they looked at the instructions. Replacing the large ‘Ok’ button with the familiar ‘close’ icon (X) in the top right, not only changed their usual behaviour by ensuring their eyes spent enough time looking at the graphical instructions before proceeding, but, also used an icon they were familiar with from using other applications.

Mission Accomplished!

Soon after launching the fingerprint login, the App reviews from customers started rolling in. And they were good!

What can we learn from this?

Why should we care about testing the user experience on a third party API?

Many Apps in the market use the ‘default’ from Apple and have just accepted what they’ve been given, rather than thinking about its usability and the frustration that it causes users. But, why? It’s the quicker option, but how does that help your brand give a better user experience? The user won’t know the constraints you’ve been given by Apple. They’re just tapping on your App icon, looking at your brand being displayed and not enjoying the experience. Ultimately, if they become frustrated, they will blame your brand.

We wanted our App to ensure a great user experience. Especially, when we could solve the problem.

What could Apple have done better?

When you’re dealing with third party APIs, there are inevitably constraints. It appears as though Apple’s focus was skewed more towards launching the new feature as quickly as possible, overshadowing the user’s experience. Whether or not they had the time or money, if they’d considered ‘real users’, they could have created something that was more intuitive. As Steve Jobs once said:

“You’ve got to start with the customer experience and work back towards the technology – not the other way round.”

Hopefully, the next release will be more intuitive and have some of the refinements that Steve Jobs might have demanded.

What can brands, developers and user experience designers learn from this?

Mobile phone developers need to understand that people are not just using their phones to access Apps developed by them. They’re downloading third party Apps. If you truly want your mobile device to provide a great experience, you need to allow third party Apps to integrate seamlessly with your software. Apple is known for restricting users from integrating with their software. In today’s world, this is not something you want to be known for.

When you’re developing a new product, don’t just look inwards. Look at the wider picture to stay ahead of the game.

If you’re building an App that uses an third party API (like many Apps need to), consider the restrictions imposed by the API. Sketch out the path that a user will take when performing a task and think about how you can make the process as easy as possible. Then, look at restrictions imposed by the API or even a third party library that you’re using, and consider what impact this has to your user flow. Follow this up with user testing to find an ideal solution which best fits with the user experience and the effort it requires.

Remember your user will judge your brand on the experience that you give them.

This article originally appeared on the ThoughtWorks blog

To find out more about Emma’s Agile Encore presentation, visit the website.

Posted in Agile Encore, Education, Guest Blogger | Leave a comment

Are you a DevOps fan?

encore-2016-speaker-kiru-and-william-1A new workshop on Docker has been added to the Agile Encore workshop line-up!

If you’re a DevOps enthusiast, you will want to gain an insight into a new form of app development, that literally builds a ‘container’ around everything you need to run an application or cloud system. This makes sure that software can run seamlessly, regardless of the environment. You can learn how at a new workshop on Docker, being held as part of the Agile Encore Workshop Day.

At the workshop, you will gain an understanding into the Docker process, and how to deploy it into any system. The workshop covers a variety of topics from Docker 101 – an overview of core concepts, to security considerations, and ‘how to handle stateful applications and services in Docker’.

Check out the new addition to the Agile Australia 2016 workshops, ‘Docker beyond buzzwords’, a half-day workshop presented by Kiru Samapathy and William Garcia, both senior consultants at Thoughtworks.

For more information about the Agile Encore workshops and to book a limited place, please visit the website,

Posted in Agile Encore, Workshop | Leave a comment

How to implement hypothesis-driven development

International author and consultant Barry O’Reilly today discusbarryses ‘how to implement hypothesis-driven development’. Barry is coming to Australia in December for a series of exclusive workshops on Lean enterprise: creating high-performance organisations. Barry is also the co-author of Lean Enterprise: How High Performance Organisations Innovate At Scale.

The Lean Enterprise workshops will kick off in Sydney on Monday 5 December, and will be followed by Adelaide on Friday 9 December and Melbourne on Friday 16 December.

How to implement hypothesis-driven development

Remember back to the time when we were in high school science class. Our teachers had a framework for helping us learn – an experimental approach based on the best available evidence at hand. We were asked to make observations about the world around us, then attempt to form an explanation or hypothesis to explain what we had observed. We then tested this hypothesis by predicting an outcome based on our theory that would be achieved in a controlled experiment – if the outcome was achieved, we had proven our theory to be correct.

We could then apply this learning to inform and test other hypotheses by constructing more sophisticated experiments, and tuning, evolving or abandoning any hypothesis as we made further observations from the results we achieved.

Experimentation is the foundation of the scientific method, which is a systematic means of exploring the world around us. Although some experiments take place in laboratories, it is possible to perform an experiment anywhere, at any time, even in software development.

Practicing Hypothesis-Driven Development (Jeffrey L. Taylor) is thinking about the development of new ideas, products and services – even organisational change – as a series of experiments to determine whether an expected outcome will be achieved. The process is iterated upon until a desirable outcome is obtained or the idea is determined to be not viable.

We need to change our mindset to view our proposed solution to a problem statement as a hypothesis, especially in new product or service development – the market we are targeting, how a business model will work, how code will execute and even how the customer will use it.

We do not do projects anymore, only experiments. Customer discovery and Lean Startup strategies are designed to test assumptions about customers. Quality Assurance is testing system behaviour against defined specifications. The experimental principle also applies in Test-Driven Development – we write the test first, then use the test to validate that our code is correct, and succeed if the code passes the test. Ultimately, product or service development is a process to test a hypothesis about system behaviour in the environment or market it is developed for.

The key outcome of an experimental approach is measurable evidence and learning. Learning is the information we have gained from conducting the experiment. Did what we expect to occur actually happen? If not, what did and how does that inform what we should do next?

In order to learn we need to use the scientific method for investigating phenomena, acquiring new knowledge, and correcting and integrating previous knowledge back into our thinking.

As the software development industry continues to mature, we now have an opportunity to leverage improved capabilities such as Continuous Design and Delivery to maximise our potential to learn quickly what works and what does not. By taking an experimental approach to information discovery, we can more rapidly test our solutions against the problems we have identified in the products or services we are attempting to build. With the goal to optimise our effectiveness of solving the right problems, over simply becoming a feature factory by continually building solutions.

The steps of the scientific method are to:

  • Make observations
  • Formulate a hypothesis
  • Design an experiment to test the hypothesis
  • State the indicators to evaluate if the experiment has succeeded
  • Conduct the experiment
  • Evaluate the results of the experiment
  • Accept or reject the hypothesis
  • If necessary, make and test a new hypothesis

Using an experimentation approach to software development

We need to challenge the concept of having fixed requirements for a product or service. Requirements are valuable when teams execute a well known or understood phase of an initiative, and can leverage well understood practices to achieve the outcome. However, when you are in an exploratory, complex and uncertain phase you need hypotheses.

Handing teams a set of business requirements reinforces an order-taking approach and mindset that is flawed. Business does the thinking and ‘knows’ what is right. The purpose of the development team is to implement what they are told. But when operating in an area of uncertainty and complexity, all the members of the development team should be encouraged to think and share insights on the problem and potential solutions. A team simply taking orders from a business owner is not utilising the full potential, experience and competency that a cross-functional multi-disciplined team offers.

Framing hypotheses

The traditional user story framework is focused on capturing requirements for what we want to build and for whom, to enable the user to receive a specific benefit from the system.

As A…. <role>

I Want… <goal/desire>

So That… <receive benefit>

Behaviour Driven Development (BDD) and Feature Injection aims to improve the original framework by supporting communication and collaboration between developers, tester and non-technical participants in a software project.

In Order To… <receive benefit>

As A… <role>

I Want… <goal/desire>

When viewing work as an experiment, the traditional story framework is insufficient. As in our high school science experiment, we need to define the steps we will take to achieve the desired outcome. We then need to state the specific indicators (or signals) we expect to observe that provide evidence that our hypothesis is valid. These need to be stated before conducting the test to reduce the bias of interpretation of results.

If we observe signals that indicate our hypothesis is correct, we can be more confident that we are on the right path and can alter the user story framework to reflect this.

Therefore, a user story structure to support Hypothesis-Driven Development would be:

hypothesis-driven development

We believe <this capability>

What functionality will we develop to test our hypothesis? By defining a ‘test’ capability of the product or service that we are attempting to build, we identify the functionality and hypothesis we want to test.

Will result in <this outcome>

What is the expected outcome of our experiment? What is the specific result we expect to achieve by building the ‘test’ capability?

We will have confidence to proceed when <we see a measurable signal>

What signals will indicate that the capability we have built is effective? What key metrics (qualitative or quantitative) will we measure to provide evidence that our experiment has succeeded and give us enough confidence to move to the next stage?

The threshold you use for statistical significance will depend on your understanding of the business and context you are operating within. Not every company has the user sample size of Amazon or Google to run statistically significant experiments in a short period of time. Limits and controls need to be defined by your organisation to determine acceptable evidence thresholds that will allow the team to advance to the next step.

For example if you are building a rocket ship you may want your experiments to have a high threshold for statistical significance. If you are deciding between two different flows intended to help increase user sign up you may be happy to tolerate a lower significance threshold.

The final step is to clearly and visibly state any assumptions made about our hypothesis, to create a feedback loop for the team to provide further input, debate and understanding of the circumstance under which we are performing the test. Are they valid and do they make sense from a technical and business perspective?

Hypotheses when aligned to your MVP can provide a testing mechanism for your product or service vision. They can test the most uncertain areas of your product or service, in order to gain information and improve confidence.

Examples of Hypothesis-Driven Development user stories are:

Business Story

We Believe that increasing the size of hotel images on the booking page

Will Result in improved customer engagement and conversion

We Will Have Confidence To Proceed When we see a 5% increase in customers who review hotel images who then proceed to book in 48 hours.

It is imperative to have effective monitoring and evaluation tools in place when using an experimental approach to software development in order to measure the impact of our efforts and provide a feedback loop to the team. Otherwise we are essentially blind to the outcomes of our efforts.

In Agile software development we define working software as the primary measure of progress. By combining Continuous Delivery and Hypothesis-Driven Development we can now define working software and validated learning as the primary measures of progress.

Ideally we should not say we are done until we have measured the value of what is being delivered – in other words, gathered data to validate our hypothesis.

Examples of how to gather data is performing A/B Testing to test a hypothesis and measure change in customer behaviour. Alternative testing options can be customer surveys, paper prototypes, user and/or guerrilla testing.

One example of a company we have worked with that uses Hypothesis-Driven Development is The team formulated a hypothesis that customers are only willing to pay a max price for a hotel based on the time of day they book. Tom Klein, CEO and President of Sabre Holdings shared the story of how they improved conversion by 400% within a week.


Combining practices such as Hypothesis-Driven Development and Continuous Delivery accelerates experimentation and amplifies validated learning. This gives us the opportunity to accelerate the rate at which we innovate while relentlessly reducing cost, leaving our competitors in the dust. Ideally we can achieve the ideal of one piece flow: atomic changes that enable us to identify causal relationships between the changes we make to our products and services, and their impact on key metrics.

As Kent Beck said, “Test-Driven Development is a great excuse to think about the problem before you think about the solution”. Hypothesis-Driven Development is a great opportunity to test what you think the problem is, before you work on the solution.

This article originally appeared on Barry O’Reilly’s blog.

To find out more about Barry O’Reilly’s full-day workshops in Sydney, Adelaide and Melbourne this December, visit the website



Posted in Agile, Guest Blogger, Workshop | Tagged , , , , , , , | Leave a comment

Why Your Company Should Adopt Innovation Days


Agile Encore speaker Emma Carter joins the Agile Australia blog today with this guest post. Emma spoke at Agile Australia 2016 and is encoring her highly-rated presentation on Thursday 10 November 2016 in Sydney.

Why your company should adopt Innovation Days

An Innovation Day is typically a 24-hour event in which employees form small teams to try and solve a problem relevant to the business. The teams have to present their ideas back to the business with a strong business case and working prototype. Many companies have their version of an Innovation Day.

What can a company gain from an Innovation Day? How can you successfully take an idea, put it into production, and ensure it resonates with your customers?

Never underestimate your staff

Traditionally new ideas for products or digital direction are filtered from the top down within an organisation, unless you’re Google or run a flat management system.

This traditional style of idea generation can sometimes stop the best ideas from coming to fruition. It’s the companies who are willing to take the leap and try something new that become the success stories of tomorrow.

Sometimes the best ideas are generated from those who work ‘in’ and not ‘on’ the business. These people see problems that customers and colleagues have on a daily basis that could be fixed from a simple bit of technology. Or identify a gap in the market based on something they would find useful as a consumer.

Decision makers at the top can sometimes be paralysed by running the business, whereas staff are more open to think freely, as they don’t tend to think about the constraints of an idea. Mars Celebrations, for instance, was the brainchild of an ordinary Mars worker in the UK, and has since earned millions for the brand.


Seemingly old-fashioned brands are embracing innovation

Banks are stereotypically seen as having an iron-fronted, non-innovative approach to business, and although many claim they put their customers first, many fail to practice what they preach. While this might be the stereotypical response, one of Australia’s banks have embraced user-centred design and team Innovation Days. They ditched the cumbersome waterfall approach in favour of a continuous-delivery methodology when it comes to their digital products.

An idea is born

An Innovation Day at a well-known bank, for example, inspired an idea to solve the issue of friends sharing the cost of bills. It would become a feature within the existing banking app and allow users to share group bills and send texts to their friends—telling how much they owe, their bank details, and providing them with a unique reference number that could later be used to track when a friend has paid them.

The feature would target a younger audience who, from the research, share bills on a frequent basis. The new concept was seen as something that no other bank was offering and would allow the brand to target a new audience.

Can’t justify 24 hours?

If you can’t justify taking 24 hours out of the ‘usual’ working period to run a Innovation Day, you could try an ‘innovation sprint’. Staff can post ideas or problems they want to solve up to a week before (the same as an Innovation Day). Individuals can then choose which idea they’d like to solve, and rather than building a working prototype, they could brainstorm the idea and develop a solution. The sprint would be limited to a normal 8-hour day.

Running Innovation Days, sprints, or even weekends, can not only help empower staff and help with team building, but can also create new initiatives for your brand.

Taking the idea to production

The concept was successfully pitched at an Investor Day, giving the team a small budget to explore the idea further. Once this phase was complete, it was handed to the mobile app team to build into the existing banking app.

Innovation Days were a new concept within the bank and – like with any new process – it was a case of trial, error, and improvement. The bill sharing concept was the first Innovation idea to go into production.

It became apparent early on that the new feature couldn’t simply be added within the existing app’s code base. Due to the short time the team had to work on the idea, there were a lot of areas left unanswered in terms of the user experience, functionality, and technology.

Get it ‘out’, then get it ‘right’

Launching with an MVP version of your innovation is a great way to ensure it hits the market before your competitors launch something similar. Many brands feel they need to spend time refining until it’s perfect before they launch. Working with an Agile methodology and getting an MVP version out as fast as possible allows you to test your idea with real users, refine, improve, and implement. While you can refine and improve your MVP version, your competitors are having to start from scratch to try and catch up. By the time they have caught up, you will have market share, along with a more advanced product and more in-depth user knowledge.

The bank’s bill sharing concept wasn’t initially going to have an MVP version. It was, however, going to receive a large marketing campaign; something the app had never received even when first launched. Although the app is always being refined to improve the user’s experience using the continuous delivery approach, launching a new feature with the backing of a large marketing campaign requires ensuring that the customer is centre of mind to avoid jeopardising user confidence and the brand’s reputation.

It’s important not to make user-assumptions. This can not only risk wasting time building something users find confusing, but can also waste valuable time designing a user interface that doesn’t resonate with the user.


To avoid the risk of jeopardising the concept, the team, which consisted of ThoughtWorkers and bank staff, built a case for justifying a soft-launch of the product. This allowed the team time to get user feedback, incorporate learning, and launch with a more user-friendly feature.

The product owner fully supported the decision to ‘get it out, then get it right’ approach. Having the product owner’s support speaks volumes for the great team relationship.

Making the idea better for the end user

Whatever new innovation you’re launching, whether it’s a new type of confectionery like Mars Celebrations or a new banking app feature, getting into the minds of your customers is key to its success. You may have the best technology, but if the design and experience of interacting with your idea does not resonate with your audience, you’ve failed.


With the bill sharing concept, we selected a group of users that met our target profile and conducted face-to-face user testing, which was invaluable to the project. This allowed us to confirm the following:

  • The new flow we wanted to implement was the correct approach. Validating this before we started re-coding saved time and money.
  • The younger audience does not like to read detail! Finding this out helped us write the correct onboarding messaging and prompts.
  • 50% of users paid attention to adding the reference number, as requested in the text message. Finding this out helped us avoid wasting any more time refining the messaging and thinking of alternate ways to improve it.
  • Removing what I believed to be unnecessary text to give a cleaner design, was proven to be something users preferred; they still understood the context.

It’s essential for a brand to engage consumers and take them along for the journey. The younger audience likes to get involved and the users of our app are very vocal; embracing this not only improved our new feature, but also made our younger customers feel valued.

Along with conducting face-to-face user testing for the ‘soft launch’, we also wanted users to give us feedback on the new feature. This would help us improve it in time for the official launch, which would coincide with the marketing campaign.

A small message that wouldn’t intrude on the user’s experience of the app was added. It simply read: “Hey, we’re building this new feature that we think you might like. It would be great if you can help us out, try it and give us some feedback.”

Unsure if we would gain useful (or any) feedback from our users, we felt it was important to try. Within a day of the ‘soft launch’ we started receiving great feedback. This enabled us to prioritise our ‘wish list’ of improvements allowing us to avoid wasting time implementing the wrong items, and ensured we gave our users what they wanted, rather than what we thought they wanted.


Design can make all the difference to your new innovation

When launching a new product, not only do you need to ensure it resonates with your customer, gives a great user experience, and technically works, but it must also ‘know its place’ within your brand architecture. Ask yourself the following:

If it’s a new feature within an existing product:

  • Does it still reflect the brand guidelines?
  • Are there ways you can still improve the design, without going away from guidelines, to ensure the customer gets a new experience but still recognises the brand

If it’s a completely new standalone product, which doesn’t need to rely on the main brand name to support it:

  • Does it resonate with the target market and stand out from other possible competitors?

How did we achieve it?

The bank we were working with targets the older generation, whereas the new feature was very much for the younger generation.

The younger generation within the mobile world is very passionate and vocal about being an ‘Apple’ or ‘Android’ follower. Both platforms have very different user interface designs and interaction, yet the majority of native apps, particularly Bank Apps, tend to use an iOS style across both App platforms.

We wanted the new feature to give the user a true native app experience, along with still feeling like the same bank. We only had a few weeks to implement and test both UI designs, which required prioritising for the maximum effect. Both iOS and Android style icons were implemented, along with appropriate layouts meeting material design and iOS guidelines. We were also able to integrate some native interaction gesture animations.


Why different departments should work as one

If your new innovation is digital, such as an app, wearable, or piece of software, it’s important that all the teams involved – from creation to production to launch – all work together and are kept informed.

Many companies keep digital, branding, and marketing teams apart, thinking neither understands the other, which causes complications. Marketing teams may be misinformed, or perhaps not understand the unique selling point; the digital teams might not be given the correct brand position for the product, or know correct deadlines.

Having all the teams working together avoids ‘middle men’ obstructing the flow of information and leads to a much better outcome.

With the bank’s new concept, we kept the marketing team informed with the improved features, latest UI designs, and insights from user testing, which we felt would help with their FAQ webpage. This strengthened their PR efforts. We were also kept up-to-date on the progress of the campaign concepts and media schedule. Having a direct relationship avoided ‘middle men’ passing messages and created one large team working towards one goal, rather than several teams heading in different directions trying to meet the same goal.

What can we learn from this?

Listening to staff from all areas of the business can not only generate remarkable innovations to transform your business, but also makes staff feel more valued. If you employ a large number of Gen Ys, holding Innovation Days is a great way to encourage their personal growth.

“58% of Gen Y want pathways to personal growth and want this closely tied to recognition initiatives.” – Huff, C, 2006

To reduce possible production problems, ensure you get everyone who would be impacted involved from the beginning. This will not only help you better estimate the effort, but the wider team might have further ideas on how best to build the product.


Don’t be afraid to refine and test your new product throughout the build cycle; ensure your target audience is always centre of mind. Ensuring your product not only resonates with your audience visually but also functionally (solving a problem) is a sure-fire way to ensure its success.

This article originally appeared on the ThoughtWorks blog.

To find out more about Emma Carter’s presentation at Agile Encore, visit the website.

Posted in Agile Encore, Guest Blogger, innovation | Tagged , , | Leave a comment

Weekend viewing sorted – new #agileaus videos!

If you’re interested in the neuroscience of human agility, how to smash the monolith, or how to scale as the tide turns, then your weekend viewing is sorted. You can watch presentations on all these topics from some of the presenters at Agile Australia 2016.

Choose from:

Scaling as the Tide Turns with Cameron Gough (Australia Post)


Smashing the Monolith with Leonard Garvey and Louis Simoneau (REA Group)


The Neuroscience of Human Agility in Organisations with Melissa Casey (Monash Health)


All Agile Australia 2016 videos are available online at InfoQ.

Posted in Agile, Agile Australia 2016 | Tagged , , | Leave a comment

Agile Encore comes to Sydney!

Some of the most highly-rated speakers and workshops from Agile Australia 2016 will come to Sydney this November for Agile Encore.

Taking place over one afternoon on Thursday 10 November, Agile Encore features 6 speakers from Agile Australia 2016, including:

  • Emma Carter – Experience Design Lead, ThoughtWorks
  • Jo Cranford – Lead Developer, Culture Amp
  • Adrian Fittolani – Program Director, Envato
  • Ben Hogan – Visual Management Mentor, AgileBen
  • Dipesh Pala – Agile Capability Leader – Asia Pacific, IBM
  • Richard Weissel – Senior Developer, REA Group

Richard Weissel at Agile Australia 2016

Session topics include practical design, visual management, lean thinking, and shaping culture and leadership.


Jo Cranford at Agile Australia 2016

More info about the speaker sessions can be found here.

This year Agile Encore also offers a suite of workshops:

  • Introduction to Agile – with Lachlan Heasman
  • How to lead by enabling growth mindsets – with Peter Heslin
  • Visual management masterclass – with Ben Hogan
  • The essentials for success as an Agile business analyst – with Jody Podbury

workshop image

For more information on Agile Encore please visit the website.




Posted in Agile Encore | Tagged , , | Leave a comment