Insights Workshops

10 Tips To Workshoppin’ Like A Pro.

Along with words & the predictability of stupidity, never underestimate the power of a good workshop. In fact, I’m a firm advocate of replacing (often pointless & frankly irritating) meetings with them altogether. Why? I hear you say. Strap in for some truth bombs.

Why workshops are better than meetings:

  • Rather than a vague discussion, they have clear & defined goals/ objectives that you are trying to solve during the session & create clear actions.
  • They are structured in a way that benefits from each person’s skills & encourages ‘outside the box’ thinking.
  • If run correctly, they can solve problems in the shortest amount of time. Problem to tested prototype in just 5 days? Oh, go on then.
Design Sprint process on a wall

Running a good workshop, however, can be hard, & if you’re not careful can descend into the futile wasteland currently occupied by meetings. Following a process is simple enough but controlling the team, managing the content & ensuring you hit the goals/ objectives can be tricky. Here are some quick tips to have you running workshops like a pro.

1. The 6 Ps Of Success

Proper planning prevents piss poor performance. Some prefer ‘fail to prepare, prepare to fail’ but I’ve always been one for alliterative acrobatics. Prepare the agenda, practice (even into a mirror) & get advice from others you work with to agree a structure for the session.

  • Set a timeline
  • Set your clear focus objectives (remember, we’re here get sh@t done)

2. Think About The Logistics For The Meeting

Yes, this sounds bleeding obvious but you don’t want to be wasting valuable time scrambling around looking for things.

  • What do you need for the meeting (pens, white boards, post-it notes….)?
  • Do you have a room booked with the right number of chairs and enough space?
  • Do you understand your audience (names/positions)?
  • How will you get to the workshop if it’s offsite and you have a lot to carry?

3. Communication & Attendance

Almost as important as remembering to bring pens… The last thing you want is for the wrong people to turn up or, more realistically, key decision-makers not attending. Although everybody contributes, they get the final say.

Make sure you send out a confirmation email to everyone confirming:

  • Their attendance (provide the full list if appropriate)
  • The purpose of the workshop,
  • the goal of the day
  • and the agenda

4. Trust The Process

You’ve followed Rule 1 meticulously & are on course to prevent piss poor performance. You know what your goals & objectives are & you have chosen the right workshop process to match the outcome needs. Trust the process.

From the Workshopper Playbook by Jonathan Courtney

Don’t let people in the room make you deviate from the stages you need to go through to get the end result. If people challenge this, be open and honest about the needs of the process and inform how it will achieve the end result. Communication is key.

5. Use Ice-Breakers.

We’re embarking on a creative process so use ice-breakers to get the juices flowing. It helps to break down any barriers & encourage collaborative thinking within the group. Ice-breakers are also darn good at waking people up after a long morning or resurrecting people from a lunchtime food comma.

If the workshop is particularly long then use them intermittently to break up the day & keep everyone thinking. I’ll be releasing a free Ice-breakers eBook in the near future filled with jovial jaunts. Ninja, Tiger, Grandma, anyone?

6. Set The Rules From The Start

Anyone participating in a workshop should be just that, participating. We’re really on collaborative input to solve a problem quickly. Some rules I like to follow are:

  • No laptops or mobile phones (yes this is a tough one for people to accept)
  • Don’t talk over other people (common courtesy)
  • Never ever any name-calling (this ain’t the playground)
  • No question is a bad question (within reason
  • No one is wrong (the earth isn’t flat)

7. Utilise A Car Park

No, not to settle disputes. Sometimes conversations & ideas pop up that are not constructive to the process. Well, not this process. We don’t want to lose these ideas. Take note of them in a separate place on the wall and let the team know that you’ll come back to these ideas separately.

8. Focus On People & Don’t Make Things Up!

One of the best bits of advice I was given for managing a workshop was to remain mindful that it’s not all about you (the facilitator), it’s about the people in the room and how they feel.

Make people feel appreciated for their questions: “What I’m hearing is…..? Is this right?” & thank them. Never get defensive; appreciate what they say and table the question.

And be honest with the responses. If you don’t know the answer, don’t try and make it up. Trust me, the audience will see right through you & you’ll instantly lose all credibility (& look like a %@3*)

9. Dealing With The Trolls…

Ah, the troublemakers. Unfortunately you will have people occasionally have people that just don’t want to be there. They’re either not paying attention, talking too much or acting inappropriately. So how do you deal with these people? Straight to the car park, I jest.

Not Paying Attention: These people are annoyingly rude but are also the easiest to deal with. In these instances here are some things you can try:

  • The whole room is your stage (as the facilitator). Walk & talk. All eyes are on you as you present & will also be on the person *&@£ing around on their phone as you stand behind them. That usually does the trick.
  • Remind everyone (without calling out names) the rules about devices and attention.
  • Sometimes you just need an earlier break to keep attention.
  • Between breaks politely ask to have a private conversation with them & talk about how you can help them be more present in the room.
  • Go full highschool teacher & ask them to share what they’re doing with the room.

Loudest Person In The Room: This is very common when you have a room with potentially “junior” team members and a few “senior” members. Unsurprisingly it’s often the senior leadership that talks the most. So how do you deal with this?

  • As the facilitator, sometimes the easiest thing to do is to ask them to deliver their thoughts. So if someone isn’t saying much, give them the confidence & opportunity to speak.
  • You can utilise a talking stick. So only people with the stick are allowed to say anything. As the facilitator, make sure the stick is passed around the room.

Inappropriate Behaviour: Probably the hardest situation to deal with. You’re all adults & the expectation is that everyone behaves like one. Unfortunately there are some people that still struggle to do so. So how do you deal with these difficult situations?

  • Shift the process from conversations to quiet actions/note-taking.
  • Call a break & ask to speak with the person about their behaviour (politely).
  • End the meeting all together as it could be causing more issues than good.

10. Feedback! Always.

You never improve if you don’t learn from what you’ve done. Always ask for feedback at the end of the workshop. Every workshop you run is training for the next one you run. If it didn’t go as well as it could have, don’t take it to heart, explore why, & understand how you can do better next time.

7 Mistakes People Make When Facilitating a Workshop

  1. They try to be an expert on a topic
  2. Let people in the room take over the narrative
  3. They don’t trust the process
  4. Don’t time keep
  5. Write with small handwriting so no one can see
  6. Lacked any preparation or communication
  7. Didn’t invite the key decision maker
Agile Digital Transformation Insights

How to go from problem to solution faster than ever before!

Whether you’re a start-up, small business or established enterprise, the need to move fast, fail faster and adapt in today’s market is crucial. Design Sprints allow you to solve complex problems in just five (or even four) days and unlock the benefits of Agile.

Agile methodology is an iterative, incremental response to the inadequacies of traditional software development and allows companies to move faster and meet the requirements of customers. The principles of Agile and the wider application of organisational agility (there is a distinction) have swept throughout Silicon Valley as businesses continue to race from idea to market.

Although I wholeheartedly think if you’re not adopting the methodology (at least somewhere in your innovation process) something is wrong, Agile is not a “silver bullet” solution… nothing is. Testing and cooperation are integral to the customer-centric principles of Agile and validating an idea can be, well, time-consuming.

Cue Design Sprints.

Developed by Jake Knapp out of Google’s Venture division, The Design Sprint is a pressure cooker, collaborative process that can take you from idea to tested solution inside of five days. Yes, really. In fact, organisations like AJ&Smart have released a 2.0 version that streamlines the process to just four days.

By the end of the Sprint, you have a tangible, tested prototype that you built together. Think of it as a crystal ball into the future: you’re able to gain valuable customer insight without committing the time and capital of building a real product. With a little bit of experience, you can also utilise the process to develop everything from complex marketing strategies to kickstarting a new business.

So what does a Design Sprint look like?

First things first, you need somebody dedicated to driving his new way of thinking. You need a facilitator. Regardless of their involvement in the business, they are able to provide an outside perspective and guide you through the discovery process. The ideas are in there, they just need to be extracted and ordered.

Next, you need the commitment of your team for the intensive (but short) process. Dedicating time can be one of the biggest challenges for any business, big or small, but consider the potential wasted months developing the wrong product.

Day 1 // Definition

Kick off the first day by unpacking the problem space and validating the idea. These structured conversations are the foundation of the Sprint as we define your “North Star”. This unwavering definition of purpose will be a constant point of focus to ensure you’re solving the problem.

Who are your customers? What do they need and what drives this need? Begin to build out a simplified customer journey and kickstart the magic of the sprint process. Using a simple “how might we…” process you can begin to source opportunities and create the basis of your new idea. Through voting and a process of elimination you’ll decide which ideas to take to the next stage.

Ideating, utilising post-it notes

Having considered your customer segments, now is the time to start organising your 4-6 test subjects for the final day. Remember, the aim of the Sprint is to have a tested prototype so subjects are crucial to the process!

Day 2 // Sketch & Decide

Firstly, we want to make sure we’re happy with the idea we’ve chosen. Validation throughout the whole process is crucial to success so key decision makers must be in the room (or can drop in and out as the days progress.

We all see things differently. In fact, the collaborative effort and combined creativity of Design Sprints make it such a powerful tool when building new ideas. Lightning demos are a great way of inspiring creativity and gaining the most from the ideation stage. Take time to find things relevant to the idea that inspires you and share with the group.

It’s time to bring the idea to life. Utilising the process of Crazy Eights, everyone in the room will begin to turn their ideas into written (or drawn) product pieces and share them via a personal two-pager storyboard. Another round of voting begins…

Design Sprint - sketching
Design Sprint – sketching

The team reviews all the ideas and ultimately votes on which one to take to prototype. Make sure the ‘decision maker’ is in the room as unsurprisingly they have the final say. Decision made.

Now start to visualise the solution and transform the personal storyboards into blueprints on the wall. A facilitator will begin to draw out the idea, frame by frame, as everybody discusses how it should look.

Day 3 // Prototyping

With the blueprint complete, it’s time to create something tangible that can be tested with real customers. It doesn’t need to be a complete solution, just enough to take the potential customers on a journey and communicate the idea. The team can utilise pieces of paper to develop the prototype, or if possible, translate it using tools like Miro and Figma.

Figma prototype example

Day 4 // Test & Learn

Your customer was defined at the start of the process and should now be in the room with you. It’s the moment of the truth. Present your idea with the prototype and gather feedback. Was the feedback positive? If so, great! You can start developing the project utilising the agile methodology previously mentioned. Was the feedback average? Is there a way to pivot the idea and refine the solution? Hopefully so.

Running a test with potential customers

Was the feedback, let’s say, less than average? Maybe it’s time to scrap the idea and try something different. Trust me, it happens. But at least you didn’t invest months into R&D to discover it wasn’t what the customer needed!

Chris Sinclair is a Digital Experience Designer & Strategist responsible for working with start-ups and organisations to develop products and go to market strategies utilising agile & design sprint methodologies.

Connect with Chris.

Agile Digital Transformation Insights Lean Startup

Time to pump up the tyres on Agile — without a budget blow-out

by Paul Scott, Director and Board Advisor at Digital Village

Photo by Henry Perks on Unsplash

The fall out from COVID-19 has yet to be fully understood, but one thing’s for sure; enterprises will be seeking fast, efficient and flexible ways to solve their problems with digital solutions. Projects have been backing up during the lockdown and now’s the time to begin clearing the backlog. It’s likely to lead to an uptick in demand for skilled resources, but will they be able to deliver fast enough and to quality?

The announcement this week of the budget blow out at the Australian Digital Transformation Agency’s son-of-Mygov project hows just how quickly things can get out of control without a laser focus on solving one problem one at a time.

The methods used to build solutions with software haven’t changed significantly for 30 years. And even though we’ve lived in the Agile Age for almost 20 of those years, the time it takes to deliver solutions, not to mention quality and efficacy are still falling short of expectations.

Beyond Agile, examined why software development failed to meet the lofty aspirations of the Agile Manifesto founders. The book also explained how to avoid some of the classic mistakes of Agile software development.

A recent talk given by one of the creators of the Manifesto for Agile Software Development, Dave Thomas, underlines the dysfunction caused when the principles of the manifesto are misinterpreted or distorted to fit a corporate IT agenda. He half-jokingly attributes the downfall as our tendency to turn adjectives into nouns; so instead of the title Manifesto for Agile Software Development, people turn it around a truncate it to — Agile Manifesto, thus losing its meaning and purpose.

Beyond Agile explored many of the noteworthy ‘lightweight’ methodologies in use today, some of which pre-date Agile. This provided context and explained why software development often fails to meet people’s expectation. One of the founders of the Manifesto for Agile Software Development, Alistair Cockburn puts it simply:

“The Agile Manifesto was the product of seventeen people from different schools and backgrounds. No one person is responsible for the words we came up with — it is clear that it was the product of all seventeen people. The addition or removal of any one person would have changed the outcome, something we recognised and discussed at the end of that meeting.

Whether you think ‘Agile’ saved the world or poisoned it, be sure always to recognise that it grew from a rich compost (joke intentional) of backgrounds. The next time you read a would-be history of the Agile movement, look for all those names. If you don’t see them, it is not a history, it is one person’s personal recounting of their own journey, years after the event (as indeed, this one is).”

Cockburn’s statement gets to the heart of why Agile is such an enigma: few people bother to understand or respect it for what it is, choosing instead to follow second-hand interpretations of the manifesto or, worse still, a consultant’s cheap imitation of it.

Agile failed not because it was inherently wrong or misguided. The Agile Manifesto was an irrefutable thing of beauty, and its core values are spot-on. The problem with Agile is it was released into the wild and then co-opted by people unwilling and unable to really think about it or understand what it meant. Kent Beck, the creator of extreme programming and one of the original signatories to the Agile Manifesto, calls this the ‘staring dog problem.’

“If you try to point something out to a dog, it will look at your finger,” he explains. “If you explain an idea in terms of concrete practices — like test driven development, pair programming, continuous integration — people will fixate on the practices and stop thinking.”

Scrum and other lightweight spawns of Agile are failures precisely for this reason. They shroud important ideas like user-centricity and fast iteration in practices, rituals, silly names and guiding principles. The Agile manifesto itself, despite its brevity, left too much room for interpretation. And now it feels like we’re back where we started in the late twentieth century with powerful technology and tools and no idea what to do with them.

Beyond Agile describes the three reasons why the method was created :

  1. To eliminate (or at least reduce) waste in software development;
  2. To create software that people actually use; and
  3. To deliver projects on time and on budget.

An analysis of fifty thousand software projects conducted by The Standish Group found that in 2015, an average of 29% of projects were successful (meaning they were delivered on time, on budget and to a satisfactory standard). The remainder, 71% were either failures or ‘challenged’ to meet expectations. Just think about that for a moment: starting a large scale technology project you only have a 1 in 3 chance of being able to celebrate success. Not very good odds. The same report in 2018 showed the situation had got worse with only 23% of projects successful and 77% wither challenged or failed.

Other sources corroborate these worrisome facts. In a paper presented to the 7th International Conference on Knowledge Management in Organisations, Stanley and Uden proved that software projects typically overrun their budgets by two hundred per cent, and exceed their schedules by fifty per cent.

But it’s the cost of the failures that’s the real issue here. The financial impact of project failure is nothing short of tragic:

  • The cost of re-worked and abandoned systems costs the US economy an estimated $75 billion per year;
  • In Australia, $5.4 billion is wasted each year on IT projects that don’t deliver value or are abandoned completely;
  • One project alone — the infamously abandoned National Health Service patient record system in the United Kingdom — cost taxpayers £10 billion.

To put those numbers into perspective, the United Nations estimates that a yearly investment of $267 billion would end world hunger by 2030. A meagre $175 billion per year would eliminate extreme poverty globally.

It’s been a long time since the Agile Manifesto was written, and even longer since Winston Royce published Managing the Development of Large Software Systems. But nothing has changed and no single methodology has really improved software development. Software development is still a hugely expensive, wasteful endeavour that rarely meets expectations. And that’s unacceptable, especially as we approach the end of lockdowns in the COVID era.

It shouldn’t be beyond humans to come up with a better, more reliable way of developing software solutions. Just as garment makers and car manufacturers in past centuries industrialised their domains, so too software coders need to do the same. Digitisation begets automation.

Methods like Beyond Agile address some of the shortfalls of alternative methods, but it’s by no means a silver bullet. It requires skilled people, disciplined practices and full engagement with users and the problem owners. Indeed its quite likely that many of the principles distilled in Beyond Agile can and should be applied to other development methods. This would go some way to fixing Agile.

In summary, to make Agile methods work there are four areas to consider which align closely to the original manifesto:

  1. Start by defining the challenge or problem to be fixed
  2. Define the outcome in terms of a quantifiable measure
  3. Describe the 6–12 features or functions the solution must have
  4. Identify the first half a dozen users you’ll engage at the outset and throughout.

Rinse and Repeat.

Digital Village is a community of IT professionals dedicated to providing flexible IT project team solutions to enterprise in Australia and New Zealand.

Insights library meetups

Why IT Projects Fail

What causes IT projects to fail & what does a successful project take?

Since the 1950’s, when humans started writing software and programming machines to do things, failure was common. It was also very expensive, but it was necessary. Most of the proceeding years were focused on improving the technology and it is a testament to humans of our capability, intelligence and dedication. I feel it is important to take a moment to stop and look at what humanity has achieved in terms of technology advancement.   ?

Jump to the present and the technology we have at our fingertips enables us to build amazing products and services and solve some serious problems as well as open up amazing opportunities for people and business. But now that we have the technology, the demand and expectation from markets (people) is pushing us to innovate more, build faster, be more efficient.  Makes you wonder where it ends or if it ever does.

However, now that we have the most advanced technology, this has not necessarily reflected in more successful projects. So makes you wonder, If technology is not the problem, then why do IT projects fail?

This month, at a Digital Village Meetup, we explored this question as a group. 

Session Outline

At Digital Village Meetups, we sometimes play a card game. The card game is simple; 6 decks of cards. Each deck representing a category, each card has a question or statement on it. A player rolls a dice, and picks up a card from the respective deck, reads it out, has a go at answering it and then the group discusses it.

In this session, we decided to focus on only one card from one deck and go deep on it as a group.

The original plan of the game was for each group to pick up a card from the deck without knowing what each other group selected. We did this to avoid group think, but we had rigged it so that each person would pick up a card with the same question on it (so we are all answering the same question without knowing).

BUT as each group came to select their card, they would dig into the deck so not to choose the card from the top (as we had planned to happen). The unpredictable nature of people set the tone for what was to come.

Once we broke into groups, each group spent 30 minutes coming up with a summary of their thoughts and ideas about the card they pulled from the deck. Below are the finding for each group:

Group 1:

Question Discussed: Why do IT Projects Fail?

Group 2:

Question Discussed: When running a project, what can you do to improve the feedback loop?

Group 3:

Question Discussed: Why do IT Projects Fail?

Group 4:

Question Discussed: Waterfall vs Agile?


As a collective group we discussed each groups findings and went deeper into peoples reasoning and experiences and explored what makes a successful project happen? The high-level results were:

Empathy & Attitude towards ‘right and wrong’ 

Of course culture is central to success but having a team culture and attitude and belief that “it is OK to fail, so Im not scared of experimenting and trying something new” is crucial for people to feel comfortable to be relaxed and be intuitive. However, there is a difference between it being OK to fail and and just being incompetent. The difference is in the learning. Were lessons learned and will that happen again?


One thing that was obvious is that there needs to be one person holding the torch and keeping everyone aligned and heading in the right direction. This person is crucial to resolving issues and making sure that everybody understands each other. This person is a listener and a communicator and doesn’t necessarily have to be the most liked person in the team.


Having a process in place makes things easier for everyone. So people know what to expect and they don’t ever feel lost about what is supposed to happen next. It gives a structure to something that is very peopley and soft.

Flexibility & Balance

An interesting observation was that there is not necessarily a ‘right’ or ‘wrong’ way to run a project. Agile vs Waterfall; it doesn’t matter and it is unhelpful to argue. It comes down to what is the best process and design for the project at hand.

Project Teams

However a proven structure of running teams is small, cross functioning teams. With complimentary skill sets and knowledge. The formation of the team is that of a group of 3-5 with one project leader. An example of a successful team structure is 3Wks, a software development firm which was acquired by GrowthOps in 2017. Project teams like this are well balanced in their individual capability and this gives a flexibility to solve most problems that are faced within a software project.


It was a lot of fun, but the general gist was humbling. The theme that kept being raised was PEOPLE.

#Peoplearecrazy. They are unpredictable. Everyone is unique and we cannot expect people to behave or think in a particular way.

The silver lining here, is that although the communication and  difference between people is the cause, if we combine these differences in a unified, harmonious and collaborative way, the outcomes are amazing.

This is why Design Thinking and related methods work so well. Because they extract and present each persons thoughts for others to see and understand.

What makes a successful IT Project?

Creating a common ground and shared understanding for all people around the same problem, solution, goal and outcome.

3wks, practiced a relatively unique project management method they designed to include all project stake holders in the development process. With a focus on outcomes that all people (tech and non-tech can understand, it is easier to keep people aligned on track and engaged in the project and the goal.

If you are interested in this process I highly recommend reading this book written by the 2 founders of 3wks; Beyond Agile.

Thanks for reading and hope to see you around the Village sometime soon.

Jason Hardie

Get Involved

See how DV runs Projects

Join the next monthly Meetup

Join the Village to work on a project

Engage Digital Village to run your project