Free UK Delivery on Retail orders placed over £250
Showing Prices VAT

Contact our sales team 0800 783 5887 or sales@majisign.co.uk

How to be Agile with your customers (don't mention the software!)

ProcessTeamwork

Here’s my formula to convert your agile IT team into a blossoming and brilliant product design factory. I’m going to discuss how to overcome technical barriers that can exist between those people with ideas and those programmers with technical aptitude. I’ll show you how to spot some common pitfalls and enable you to start working on some concepts that will turn your team into one that’s all about the features and functions and not the coding and tools.

Pick any task that you need to complete for your business and you can be sure that it shall involve some form of technology. Even the simplest of tasks can become a technological maze. Endure this maze through self-learning and plenty of googling, it is possible to become self-sufficient. If there's a limitation of time or expertise (or patience!) then you need to find the people that can make your plan a reality.

Everyone needs to get stuff done. When working as part of a team it is important to use a process that delivers the result you’re looking for (even if the initial idea is vague). But a comparison of product design manufacturing vs. software development highlights loads of differences – but why? How can 2 teams that work using a similar process have different outcomes? Is it the product they’re making that is the cause?

 

Why it’s important not to be consumed by tools & software

Speak to anyone “in IT” and they’ll most likely be a programmer, coder or developer. They’ll be fluent in a few computer programming languages and be able to create programs that run on computers. Ask them what they do and you’ll either be hit with technicalities or told: “I work in IT”. Find a point of sale expert though and they’ll probably give you examples of what they do and give you a creative answer. What they won’t tell you is how their new easel blackboard was created using just the right amount of opacifiers in the chalkboard paint and is the answer to every trade stand display. And this is exactly why some teams succeed, some fail and some get delayed; it’s critical to abstract away how you do a job and make it into what you do.

This challenge persists into MAJIsign; design and engineering have embraced some of the most advanced CAD and image processing software whilst carpentry has enabled scale through automation using CNC and other machinery (all controlled through software). Whilst production processes are the business of the workshop, the designers and support teams have faced a new opportunity of having to work out the best way to use the software in collaboration with their customers. Above all, the right method needs to work for all products; from printing on canvas, to simple blackboards and easels right through to overhauls of the entire point of sale advertising displays.

 

Below, MAJIsigns’ Scandi Boxed Condiment Holderdesigned in-house according to the most important features of storing condiments, having a handle and using the most efficient manufacturing processes to reduce total cost.

 

 

So why does the customer even need to care about the software?

Usually, they don't! However, within manufacturing, this is an important step, since the customer becomes "the product owner". Think of this role as the chief designer - they get to set the specification of what they need; from colour & fonts to text for personalisation right through to technical specifications if they're needing an entirely new solution. At this point, we need a great way to identify all the needs and have the process take us from the initial idea right through to a finished product. And herein lays the crucial interface; you're placing together a designer and others from your team with (often) a total stranger. It’s imperative to find some common ground and coach them into your process. Remember; you’re not placing your customer with an Adobe Illustrator or Photoshop expert, you’re asking them to work with a product designer (who just happens to use some software).

 

Below, “I need something that keeps my menus and condiments together so the table stays tidy”, the Bistro Condiment Box

Bistro condiment box

 

Putting control in the hands of the customer and avoiding the “leave it with us” mentality

We talk about our team “being agile” and that it embraces the product owner role - it aims to put the customer first and they get total control of the priority order for each of the things that they want. They work with our team.

We also aim for some goals- reduce and control costs of development (or spend our money more wisely), improve team culture through shared achievements, communicate in a better way with everybody else that's involved and overall declare our efforts as "delivering value".

So what we really mean to say is

"regardless of my team's ability, we find it easier to deal with small chunks of attainable work. We can create something quickly and add features later".

We call this progression, collaboration and improvement an iterative approach. The alternative is a more traditional method; receiving a brief that contains a variable amount of useful information and having to design in isolation on an interpretive basis. It’s total guesswork and the butt of many IT jokes. Realistically though, many companies will ask for what you’d like and come back to you weeks or months later with a totally different product than you’d imagine.

The journey of software development for soft-products is useful to have experience of but what happens when the product is physical rather than software?

 

Being Agile when the product is real

I observed how Majisign combines agile practices to create great products. It took a couple of hours of wandering around a workshop to realise how the frustrations of software development can easily be avoided.

“An HGV appears at the back of the workshop with a timber delivery onboard. Behind the loading curtain, there are lengths of ash, sheets of MDF and an assortment of other woods I couldn't even name. A forklift truck appears, loads up the pallets and eerily drives off into the factory. I follow at a distance and see each type of material being arranged on a huge set of racking, all labelled and easy to refer to. I see one of the team loading a CNC machine with a sheet of wood; it’s huge and capable of cutting at such a rate, requiring a serious amount of vacuum power to extract the dust. Freshly cut items for sandwich boards are taken off another CNC and taken for spraying, laser engraving or both. Meanwhile, the printers are running and one is painting people’s advertising messages onto aboard panels whilst the other a child’s face onto a canvas. The Assembly team know what items are arriving and they're a crew with the dexterity of angels - expertly screwing, glueing and being an early QA on anything that they touch. A look downstairs and the dispatch team are carefully but quickly packing easels into boxes, taping up and sticking address labels. The courier arrives later that day and the dispatch bay is completely emptied. It's quite an operation. The variety of products and displays is huge- most of which are finished with customer specific branding and design.”

Clearly, the team has practised their routines and somehow there's a fluidity that makes its way through each of them making the whole process almost effortless.

 

Tell me how to make it look so easy

But before anything is manufactured, the sales, design and product teams have all had a hand in this success. They let the customers know what to expect and the designers are iterating in an agile manner. The customer can request a free design service (as well as supply their own artwork if they have it). The design team guide the customers towards an ideal final design. Interestingly they employ some subtle yet powerful processes;

 

  • They tackle each design element individually, so there's never a need to redesign the entire product. They've found this is more effective than creating an entire design with a "how's this?" approach since it leads to lots of rework and often a large effort for the customer to communicate back to them. Smaller pieces are easier to deal with, regardless of if it’s a Mother’s Day poster or trade stand advertising.
  • Templated designs and successful product prototypes are used since they've been proven to be ideal catalysts that coach the customer towards thinking about their usability requirements and ultimate purpose.
  • Reuse is widely promoted on fixed dimension print media. The art of communicating is retained and just the message changed. They reuse proven ways of doing things that work. This leads to positive usability and conversions. This is especially valuable for themes; from Christmas POS to birthday celebrations.
  • The customer is in control. They become "the product owner". After all, this product is going to be viewed by their customers and positively yield revenue. There's a plan with the desired outcome that is easily measurable
  • Include being creative. Often the enemy of efficiency, the creative elements are the reason why customers engage as they want a product to fit perfectly into their business and be beneficial. It's important to get the balance between creativity and predictability. They want the confidence that the process will work combined with elements of brilliant creativity.

Here's a table talker that holds salt & pepper. It's a really simple piece of design; it's functional and easily customisable. The base table talker design was used as a starting point and allowed for creative ideas about how to hold 2 pots to be iterated over. Elements of the premium table talker were added, too. Finally, the base was extended and routed out, creating an indent for 2 pots. A space in the middle allows for branding if needed.

 

Common pitfalls of being iterative

Most “I work in IT” teams have the best intentions to create a great product, however, are often frustrated with iterative development processes. This frustration originates from historically being employed as the expert (with ultimate control) yet in more recent years must now engage in iterative design and development sessions that seek to improve existing features (because everything can be changed). This can feel slow, especially when solution-orientated personalities are involved.

And that slowness has multiple reasons for existing:

  • As a developer, you're used to creating a solution that meets a checklist, a list of requirements or detail specification. And when that list is complete, the work is done, so how can it possibly be incorrect?
  • We are often told that the primary purpose of a system is to be logically correct, so when engaging in small changes to tweak layout, colours, fonts and images (to improve the user experience), there is sometimes little tolerance to keep changing
  • Communicating through code is very expensive and very slow. Sometimes the people creating the product aren't great communicators and do not have support from the team to facilitate it. By default, if they don't engage in early planning or this phase is omitted, the first opportunity for comment by the customer is when the first version of the product is produced. From here this pattern is repeated- feedback is collated and further changes made. Those changes are critiqued and more changes spawn. This pattern of exploration should always be replaced with discussion and collaboration

 

Creating a brilliant product

Ultimately the aim is to have collaboration drive the literal look and feel whilst objective discussion can discover metrics of most importance. Combined, the creators can produce a great product.

Software development has an ever-changing luxury whereby changes can be made at relatively low cost, mostly. But when the output is a physical product, the opportunities to change are much more contained, especially when that output is resistant to change. So whilst the world of computational technology is often cited as the leading edge of all industries, in reality, industries that are anything but virtual have been honing development processes well ahead of any software development environment. It may seem obvious that kanban, six-sigma and lean originated in manufacturing.

If you're working as part of a team that makes products, take your current to-do list (or backlog) and now apply it to something physical. A pub sign, a blackboard or a complicated building. How does this affect your priority order? What would cause you to remanufacture the object from scratch? And what's now easier to implement?

 

Conclusion

  • Convert your techies into business hosts or chaperones. Make it their business to guide customers and colleagues through a process that links to benefits
  • If your product is software based try to avoid revisiting the same features over and over- sure it can be changed, but why give yourself this cost?
  • Build software as if it were a physical item- think big and really concentrate on how people are going to use a feature
  • Just because you're using an agile methodology, it doesn't mean your customers do too. Work on abstracting the concepts of agile into value steps that make sense for everybody
  • Squash any sign of a team member communicating in code! Find a way that enables discussion and collaboration.
  • Identify people that are solution-driven. Make them one of your chaperones and keep them busy in planning activities "with the big picture". Isolated big thinkers get sour quickly.

 

This is a guest blog post written by Adam Vaughan; an innovative technical leader with experience in data-driven technology & software development, building some of the best data-led & engineering teams for a number of FTSE, NASDAQ and Fintech companies.