In my interview for Arrk, I was asked what I wanted to get out of this job. If I remember rightly my response was something like: “I’d like to learn all about the computer systems that are increasingly pervading every aspect of modern life.” I am now in my 8^th month.

When I started there was no predefined role for me. I am a physics masters graduate with interests in what sometimes feels like too many things. At the interview I was asked “What area would you like to specialise in?”

I replied: “Anything really – I’d probably be more competent at backend programming due to the scientific nature of it. Data science is something I would find my feet in with some speed, can I learn about machine learning? Hang on, I’m also really interested in Human-Computer-Interaction and information design so maybe I’d like to try my hand at UX (I was a little concerned that this would show me up as being jack-of-all-master-of-nothing – Maybe I should show them the bajillion and one ideas in my notebook?)”

In my first week, another new employee, Jake (a BA from IBM) and I were given a project: design and build a tool to assist with the “alignment and propagation of goals throughout Arrk”.  We spent the next four months working with a team across Mumbai and Manchester, researching, designing and building. The whole team was open and supportive, which as a newcomer was really reassuring.

Along the way I tried my hand at the following…

 

Design Thinking

The first few weeks of the project was all about research and design. We conducted some internal Design Thinking sessions. Design Thinking is a creative strategy for solving problems. It takes you from discovery and specification of a problem, through design, iteration and then a proposal of prioritised work ready to be designed. It was also a great way to get to know other employees – interesting to see how other staff members reacted to how a newcomer might go about such a task. It did feel as if my mistakes were valuable. I even feel like we made a ‘mArrk’ on their methodologies.

UX Design

With guidance from an experienced designer, Jake and I designed the interface for the first release of our product. We crafted paper prototypes, tested and improved them. We then built digital simulations, conducted user tests and iterated. My main lesson from this has been ‘build for the user, not the machine’.

Programming

Studying for a physics masters taught me computing methods for solving equations, data analysis, lab work, microcontroller programming and more. After four years of scientific computing, I thought I understood programming. How wrong I was! Building software with a distributed team is very different. New areas for me included front-end development, databases and working with frameworks.

 

It feels quite unique to be working in an organisation with such a flat structure and open culture where failing (fast) is encouraged and ideas are never shot down. To see a project through from its inception in your first week of a new job, through development and into delivery is an extremely valuable experience to have. When an exciting customer facing project came along next, we were now ready to jump straight in!

 

Do you have what it takes to join our rapidly expanding team? Visit our careers page to see some of the exciting and extremely rewarding vacancies we have to offer.

Empowered customers are shaping and redefining the way business operate, they demand consistency and excellence, be that in-person or increasingly across a complex web of digital environments.

Thus the term “Age of the Customer” was coined, an acknowledgement that the customer is now firmly in the box seat, with the collective power to shift business strategy, lay waste to decades of shareholder value, or present a golden opportunity for forward-thinking and fast-acting organisations.

So, what does the Age of the Customer have to do with a winning membership engagement strategy? Simply put, your members (and future members) are also empowered customers, expecting the same levels of personalisation, innovation, consistency and communication channels as they would if they were making a purchase. Therefore, in the same way the customer-led market has shifted towards innovative use of technology and integrated messaging, so too the membership association must follow suit.

A satisfied and active ecosystem is the core ingredient of any successful association. A robust and affluent association is one that keeps its members engaged by consistently participating and engaging with its members in a personalised experience manner.

Therefore, forward thinking associations need to execute on the following strategy plays:

Change management

Strategic and operationally the association needs to operate a top-down, organisational wide member-obsessed model.

Experience

The association needs to proactively capture and understand what its membership values most dearly, and act on the findings accordingly. And this exercise must happen again and again for the association to remain relevant.

Technology

To enable this the association needs to adopt a modern digital platform which provides the foundation for all its digital experiences. These experiences need to be simple, consistent and accessible. The best digital experiences drive membership engagement and inform the wider ecosystem, while the worst can drive the most active community apart. Apathy (and legacy siloes) should be no friend of the membership association.

A working digital strategy should involve the analysis of data entered by individuals, such data holds the key to driving customer engagement and appealing to a wider community and range of demographics.

Breaking the 1% rule

A common challenge shared by associations is how to cultivate and grow member engagement; the 1% rule is often cited (or in the case of Wikipedia the 90-9-1 rule) where only this tiny percentage of the whole member base can be considered truly active and engaged.

By taking on and using the best practices from the Age of the Customer, by employing the right technology and by putting the membership at the heart of the movement, the 1% rule can be cracked.

Even the legal industry isn’t immune to technological disruption.

The legal industry is like banking and insurance. There’s a lot of red tape to wade through as it’s notorious for relying on physical record-keeping and having an eye-watering amount of administration. Practices have remained practically unchanged for centuries. Many startups are keen to disrupt this £26 billion industry in the UK, and beyond.

Far from being replaced by robots, the legal profession is set to be enhanced by the new technologies that have already reshaped much of our world.

The rise of legaltech is being treated with the same excitement and anticipation as the growth of fintech a few years ago.

Definition of lawtech

Lawtech is generally defined as the use of technology to provide legal services, with such technologies set to disrupt the legal sector.

While the tech industry is firmly on the pulse of lawtech, the legal industry itself is heavily founded on tradition and custom. Many lawyers are still blissfully unaware of the impending disruption.

Despite some being slow to take up these new technologies, business as usual will no longer be an option in the near future, as has already happened in many other industries including publishing, retail and travel.

There are some sections of society who are currently virtually excluded from obtaining legal services due to the cost barrier. Some company founders therefore have a vision to remove this barrier with technology that can provide basic legal services to customers on a budget.

Lawtech is bringing new challenges and more opportunities. It’s already well-established in the United States, but is gradually spreading to Europe.

Examples of lawtech

Lawtech can involve using Artificial Intelligence to support the role of lawyers, removing the tedium of some aspects of legal work.

For example, AI technology called ROSS has been trialled to sift through data previously handled by people, and can be controlled with natural language queries. This means non-programmers can use the technology by typing commands in the form of questions or search strings.  

An app has been trialled that can draft confidentiality contracts. More software for will creation is also being trialled that helps people overcome the barrier of going through the tedious and unpleasant process of making a will.

Blockchain technology is enabling the exchange of digital legal contracts and avoiding the risk of security breaches like the high profile Distributed Denial of Service attack against Dyn. The Internet of Things refers to connected devices, and in legaltech such technologies are being employed to gather data intelligence for smart contracts.

The world’s largest law firm is trialling software that predicts the trajectory, cost, length and even the outcome of litigation by applying machine learning techniques to case law. It could help prevent some cases from going to court by analysing the most appropriate course of action.

Virtual assistants such as chatbots are growing in popularity in the legal sector. For example, they can provide a neutral and non-judgemental platform that supports people who have been a victim of crime. One app helps users send reports to the police in legal terminology that increases the chance that their crime will be taken seriously.

Advantages of lawtech

Lawtech has the potential to save time and money for law firms. It could possibly automate time-consuming legal processes such as document review.

Computer games can be used to teach employees about compliance and significantly reduce the risk of policy breaches. This will save both money and the reputation of law firms.

At the moment, there is still much less incentive for legal companies to cut costs compared to other industries because all costs are passed on directly to clients. If all lawyers charge similar fees, clients have no choice but to pay the going rate.

In disrupting the industry, lawtech benefits the consumer by forcing companies to innovate and provide a service that is better value. This will drive up customer service levels in the industry overall.

Lawtech can also make the legal sector more transparent by making firms more accessible. If the client has access to a piece of software predicting the cost of their litigation process, law firms will be more compelled to justify the fees they actually charge. This empowers the client to better understand a complex industry.

Hackathons can promote social justice by producing technological solutions that help people to obtain vital legal services. Examples include access to legal help in rural areas, or for people who don’t speak English as their first language.

Final Remarks

Lawtech is an industry ripe for disruption and these changes can benefit both clients and lawyers. Cost predictions can be made more accurate with machine learning software, improving operations within law firms. A vast amount of tedious work can also be eliminated for lawyers themselves.

More clients will be able to access affordable legal help without necessarily needing to turn to a lawyer. Access to legal representation will be vastly improved by potentially removing the need to physically travel to a firm’s location and services can be tailored to better suit the needs of clients.

The term ‘open source’ is used frequently, and is applied to fields other than software programming.

Companies often describe their business approach as ‘open source’ when they mean they have an open source leadership style or workplace culture.

In this article, we’ll discuss open source in the context of software programming and other business areas.

Definition of open source

Open source software is defined as “software with source code that anyone can inspect, modify, and enhance” (Open Source Way). The term open source was coined by nanotechnologist Christine Peterson in 1998.

This type of code is developed on the premise that all software source code should be free to access and belongs to the community. The source code is open to the world, and doesn’t require a fee. Theoretically, the open source approach results in better code, because the software is made by many hands.

Open source software contrasts the products of companies like Microsoft, which historically turns a profit from selling software that is closed source. This means it can’t be accessed by any developers outside of Microsoft’s organisation.

Background to open source

As well as being a type of source code, it’s an intellectual movement that many people believe is more in keeping with the foundations of the web itself, which is largely built on open source.
Supporters of open source believe that software code should be freely redistributed and modified. It’s in some ways similar to the idea of knowledge sharing in academia: can someone really own an idea, or is it better for it to be shared by the community?

The success of open source depends on the contributions of communities. Companies that benefit from open source should try to donate their resources to give back, such as by encouraging their own developers to contribute to the project.

Open source in business

Open source business principles are founded on the idea of open exchange, and that we work better together.

For example, transparency, meritocracy and community are key to development. Open source businesses may have leaders who regularly assess and respond to feedback.

Businesses practices are collaborative and employees are able to directly influence their work environment.

Famous examples of open source

You’ve probably already used open source software in your daily life, perhaps even without realising it. OpenOffice and Libreoffice, both fully-fledged office suites, are free and open source. Bibisco is free and open source software for writing novels.

The Linux kernel is the most prominent example of an open source operating system, created by Linus Torvalds. Torvalds is possibly the most well-known figure in open source.

The Linux Foundation charges itself with supporting the tech ecosystem to develop using open standards and protects the development of the Linux kernel.

What is FOSS?

Some people think that open source is not a sufficient term to describe free software, because it’s easy to get confused between ‘free’ as in ‘no cost’, and ‘free’ as in ‘the ability to modify’.

Free and Open Source Software (FOSS) is a newer term that describes the combination of open source principles and free software principles.

Open source means that the software is developed by a community and can be modified freely, while free software refers to the fact that there are no restrictions on users, including financial ones.

Pros for business

We’ve already written an article about the pros of open source software for business, but we’ll briefly summarise them here again.

Open source software can be very cost-effective for business. It’s also freely customisable.

There are often also paid versions of software available that provide businesses with any support they need to run it effectively. These options are still cheaper than closed-source software.

Businesses can also contribute to the open source community once they’ve benefited from the use of free software, and this shows they’re willing to give something back.

Cons for business

As open source projects are usually voluntarily maintained by communities, there’s always the chance that the project will lose momentum and maintenance will cease.

It can also be difficult to stay ahead of the licences in open source software. Businesses can be at risk of a lawsuit if they use software incorrectly.

Final remarks

Open source software has been popular among its adherents since the birth of the web itself, but is now being revived in the business world again.

Popular with developers for its ease of use and low cost, businesses are catching on to the many benefits of open source.

The use of open source in business is continuing to rise, making a positive impact on profits and workplace culture.

 

On Wednesday 14^th June, Arrk Group will be exhibiting at London Tech Weeks: ‘How Open Standards and Systems can transform public services’. Get your free tickets here. 

“We have to move towards automated testing really, really quick!”

In the early days of our adoption of automated testing, this was the clarion call that rang within Arrk that got us starting a program in earnest. This story explains how we went about making a success of it.

Some time ago, as with many organisations, Arrk Group’s main testing focus was on manual activities. However, we quickly realised the benefits of automating areas where automated functional testing would provide significant advantages.

To break down the wall between manual and automated testers, we set-off with a transformation programme called ‘Manual2Auto’ which covered structured training, self-learning, collaborating and climaxing towards teams delivering mini-projects. At Arrk, experiential learning forms the core of any programme which is catalysed by challenging goals to extract the best from the individuals and teams.

The big mission upfront for all testers was to “learn to code” or even “don’t fear to code”. We were aware that not all testers like to code or they became testers in the first place because they did not want to code. This mindset needed to be both understood and corrected if Manual2Auto had to succeed. When the program was rolled out, we carefully reasoned that given the demands of the time, the aversion to programming/scripting or being misfits would not only impact Arrk but also hurt the tester cause. We allegorically urged them to discard the saw in favour of a chainsaw. The testers saw it and understood that learning to be friendly with Java was way better than being a relic in the testing museum.

We started the program by reviewing the composition of the team, mindset, and technical competence levels, to ensure the transition to automation competent test engineers. We customised the Dreyfus Model to create our own categorisation levels for test automation. We set Manual2Auto goals for the team to move up the chain. We used gamification to get the competitive juices flowing along with the lure of rewards for the high-achievers.

We had the team divided into focus groups for two languages which are commonly used across projects at Arrk; Java and Ruby. We formed a dedicated trainer group comprising champion testers (having sound technical knowledge) and the Guruji Group (comprising passionate senior development personnel willing to impart technical skills within testers). The Champions and the Guruji’s conducted several sessions on pseudo-code programming, OOPs concepts and language specific aspects. These sessions required the team to invest in self-study, assignments and presentations.

Formal in-depth training was also conducted on Java and Ruby by external expert trainers. The Guruji Group played a pivotal role in customising the training content and in the selection of the trainers. Both the internal and external training were followed by tests to evaluate the progress in the respective learning groups. These tests amply communicated to the testers where each one stood individually and vis-à-vis the automation objectives. The scores were never intended nor used to beat up anyone. We had a periodic catch-up and pep-talk sessions to inform and focus the team. We made use of the gamification points ranks to highlight the stand-out performers from the rest.

After the success of Phase-1, we started Phase-2 with gusto intended to consolidate and implement the learning and skills acquired. We formed multiple work-streams for the purpose. All the work streams had reasonably steep testing-come-technical objectives, to assuage project demands/problems and serve future needs. For example, we formed work streams focused on:

• Designing automation approach for a multilingual website
• Optimising a very large but bloated automation suite
• Developing a mobile automation framework
• Presenting Groovy’s capabilities
• Demonstrating capabilities on security testing e.g. OWASP, tools
• Development of a mobile app to track happiness quotient of Arrkitects

The mini-projects symbolised a rallying conscience call for the tester-teams to achieve what they had never thought they will be involved with, leave alone achieve given that these were technical work-streams and most were resigned to think they will be manual testers for the rest of their lives. But the initiative took root and spread, quite rapidly. The testers conferred with the technical experts about database design, technical nuances, got them to review code and so on. The techies were only keen to help since the testers were, for a change, interacting on a level playing field. The blossoming interactions indirectly helped the relationships as well and mutual respect got strengthened along the way.

The work-streams were demonstrated to an audience comprising the testers, senior management and the Guruji Groups. The show-and-tell sessions were well-received and applauses filled the room at times. The mood was infectious, the feeling upbeat. Many testers were now well and truly on their way to being technical, quietly confident how to use a tool or a script to produce results faster and better.

Two Significant take-away’s from the Manual2Auto program

Khushi Mobile App – Testers turn developers

Khushi literally means happiness. Khushi Android app (iOS app in the works) is designed to pulse-check the happiness quotient of Arrk employees. Easy-to-use and administer, the app determines overall happiness and that in itself represents a significant input for Arrk. The mobile app may have been built by a few testers but is really a shining beacon to all Arrk testers of what can be achieved if you put your mind to it.

JavaScript Testing Framework

The work-stream was aimed towards study and analysis of open-source Javascript-based testing tools and frameworks. After detailed analysis, a framework was created based on Protractor (AngularJS framework) and Jasmine. The framework enabled quick functional and UI testing of Angular and non-Angular applications. The proof-of-concept done on an existing project established the fact that the framework indeed enabled quick automation.

Manual2Auto represented a breakthrough journey for testers befriending the machine more than they were used to. It provided an impetus for testers’ first-hand realisation of the benefits of technical learning and the outcomes they can help generate. At another level, many testers also demolished a few demons in their minds to transform themselves into more confident, superior, efficient beings. We would call Manual2Auto a successful initiative but the joy of learning will carry on.

You’ve probably used SaaS before, even if you haven’t heard of this type of software distribution model until now. Just think of a web service like Google’s Gmail email provider – that’s an example of SaaS.

SaaS (Software as a Service) runs on a subscription model. It’s software delivered by a third-party vendor to customers over the internet. SaaS applications usually work in the browser or can be downloaded as an app. Users are normally required to have authorised login credentials to access services.

The SaaS model enables companies to treat at least some of their IT resources as a utility (a service with payment based on usage) instead of a capital investment (a fixed investment, that in this case would lose value over time).

Exploring SaaS

Historically, areas of business operations including recruitment, expenses and customer relationship management had the earliest adoption of SaaS. Salesforce pioneered SaaS by offering a subscription software model for its customer relationship management software before its competitors, and heralded the future.

Many IT businesses are now transitioning to SaaS models. Remember how Microsoft Office used to be delivered on a physical disk that you installed onto your computer? If you bought a new computer and had lost the original box it came in, you wouldn’t be able to reinstall the software. Now, Microsoft offers a suite of cloud apps called Office 365 that you log in to access from any of your devices.

Adobe also used to provide its design software on a disk or allowed users to download it once to install on a desktop or laptop. Now, customers are given ongoing access to its Creative Suite software through a paid subscription model called Creative Cloud, and is another example of an IT company transitioning to SaaS.

Lacking the brand authority or industry reputation of Microsoft or Adobe, SaaS startups employ a variety of methods to gain new customers. Customers can trial their software for free, or use a freemium account. This is when small users can use the software without payment, but must pay the subscription fee to scale up, add more users or access premium features.

Growth of SaaS

SaaS is becoming ever more popular, and has grown hand-in-hand with the shift from desktop to mobile and tablet devices. Increased broadband speeds and internet availability has also facilitated to the growth of SaaS (which relies on a good internet connection for users).

SaaS is inextricable from the startup world and the culture of remote work. Many SaaS businesses are themselves staffed by a team of remote workers, which cuts overhead costs for a bootstrapped startup.

It’s a virtuous circle. The more SaaS businesses flourish, the more SaaS products spring up to service them in turn. Team management tools like Basecamp enable SaaS businesses to manage remote teams, and allow employees to communicate with one another.

In some ways, SaaS providers function as outsourced IT support for its small to medium-sized users. Due to their ongoing subscription model, SaaS companies are required to provide excellent customer service and support. They have to appreciate the workflows of businesses from a large variety of industries to ensure their software is adopted correctly.

Benefits of SaaS

SaaS can make its business users more agile by reducing capital costs. If a company uses SaaS, there’s no need to invest in the hardware, and internal development and maintenance teams. It stimulates the growth of small business and freelancers because essential software is more easily obtainable, meaning they can compete with big players. For example, Wave is free invoicing software for small businesses, and can compete with industry incumbent Sage.

The implementation stage is much shorter than for businesses developing an IT solution in-house (a matter of weeks, rather than months or years). Businesses pay for the bandwidth they want to use, and they can scale their usage up or down according to operational needs. Businesses can usually integrate their SaaS solutions with other applications if there is a public API available.

In terms of maintenance, there is a dedicated team at the SaaS vendor working on updates and patches. Software updates can be rolled out at the same time for all users so that customers never have to worry about scheduling maintenance, or downtime.

SaaS can also usually be accessed from any device from any location. Staff aren’t limited to using the software onsite, so they can be mobile and stay connected.

For the SaaS vendors themselves, using SaaS as a business model facilitates rapid growth, enabling some bootstrapped companies to quickly become tech unicorns (companies valued at more than $1 billion). SaaS has exploded in popularity a very short time period, playing a key role in the growth of the startup industry in recent years.

Future of SaaS

More businesses are beginning to use SaaS in their operations as it becomes better understood and accepted. Still, some larger companies will still prefer to develop their own software so they can be responsible for their own security and keep hold of their data.

Using SaaS allows lots of businesses to design their own workflows, rather than relying on the packaged software of the past. Businesses can adopt software that fits their unique business model and customer needs. More companies will move to towards the agile, remote-working culture facilitated by SaaS.

Some of the power is being wrested away from established big players by disruptive startups and businesses using their products. The exponential success of startups will continue, with the number of tech unicorns increasing from just 39 in 2013, to an impressive 223 in 2017.

Takeaways

SaaS is a powerful way for large and small businesses to increase their productivity by allowing them focus on core business priorities. Companies will continue to outsource more of their IT services to specialist providers to keep pace, rather than investing in in-house resources. If your business isn’t already using SaaS, it will probably be adopting it very soon.

For startups, setting up a SaaS company is getting easier than ever. The tech ecosystem is becoming more sophisticated and more hospitable to new startups. Increasing numbers of new SaaS products will become available (and at lower prices), benefiting both businesses and consumers.

Innovation is helping us do more with less. The success of Amazon, a retailer that doesn’t have any stores and simply ships its good from warehouses was one of the earlier examples of the disruptive rise of digital giants. In more recent times, it has been followed by Uber, a car sharing firm that carries thousands of passengers worldwide and has caused huge controversy among traditional transport providers; as well as Airbnb which doesn’t have any of its own accommodation but is now in the top five portals for room nights filled worldwide, ahead of a host of internationally renowned brands, including Hilton.

These modern-day success stories are all examples of frugal innovation – a strategy that is allowing companies to develop products of high quality while simultaneously minimising the time, money and energy they use.

Where has frugal innovation come from?

Frugal innovation can trace its roots back to the appropriate technology concept born in the 1950s. However, it generally gained popularity in emerging economies such as India, and the southern Asia region, that naturally had highly constrained environments in terms of the resources that were available.

However, the process then spread to multinational companies who picked up on the concept and saw it as a potentially game-changing strategy. Now, resource constraints are no longer seen as a liability that could hold a company back, they are instead viewed as an opportunity from which they can thrive.

So it’s about making savings – but how is it done?

Broadly, there are six major principles associated with frugal innovation. They are:

Engage and iterate

Research and development can often be expensive and complex with as many as 80% of products failing when they launch. With frugal innovation, the idea behind research and development is to be more market-focused, beginning with solutions that already include some active customer involvement. It’s effectively a form of high-speed innovation.

Taking advantage of new tools

Tools in their simplest form are anything that can help you get the job done – the Frugal Innovation Hub website describes this as anything from a checklist on the back of an envelope with questions to ask, through to computer aided analysis. Now, of course, there are thousands of tools that could make a job more efficient and productive and they are often bundled into sites that are targeted at specific problem areas. Examples include carbon fibre and 3D printers; as well as supply chain analytics and micro-factories.

Sustainable solutions

Being environmentally sustainable was once seen as something companies did almost as a goodwill gesture or as part of a marketing effort to appeal to customers with a green conscience. However, now environmental sustainability is viewed as an essential part of a frugal innovation strategy with customers no longer hoping for eco accountability from the companies they choose, but demanding it. This, in turn has led to a host of so-called “cradle-to-cradle” solutions which involve both upcycling and recycling; with frugal innovation insisting that this level of sustainability be built into the research and development phase of a project. It has been one of the keys to success for companies such as AirBnB, with home sharing; EasyCar with car sharing; ParkAtMyHouse with parking place sharing; and has also been employed by major companies like Unilever with its sustainable living plan.

Addressing customer behaviour

With frugal innovation, companies should be actively engaging with customers to boost sustainable living. Techniques such as gamification, social learning, self-monitoring and visualisation tools are all used to motivate customers and to inspire them.

Involving consumers – the prosumer

Consumers have become prosumers, meaning that they are not just “consuming” a product, but are actually helping to “produce” it too. This has taken on many forms including P2P sharing, crowdfunding, collective buying and more – consumers want to have conversations with the brands they engage with and they also require personalised solutions. As such, another element of frugal innovation is the idea of co-development, co-discovery, co-marketing and co-branding with prosumers.

Innovation together

It’s not just about listening to consumers, of course: it’s also about listening to start-up experts and collaborating with them on new ideas and bringing them into reality. Companies should look for innovative brokers who don’t just have bright ideas, but they also understand how the organisation works and can help corporations become more agile and monetise their concepts. There have been many examples among larger companies already including the creation of GE Ventures as funding for start-ups in Silicon Valley; and Renault taking techniques from its plant in Chennai and applying them for the production of Dacia vehicles in Europe.

So how does frugal innovation differ from agile and lean?

In many respects, the frugal concept takes agile and lean to a new level. It represents a way of thinking and behaving that revolves around not wasting what is available, no matter how much of it is available.

Of course, all three have similarities – the methodologies of agile arguably work because of the science behind lean. However, whereas lean is about eliminating anything that isn’t adding value, frugal is about establishing something’s value from the outset, effectively eliminating the inefficient methods of working before they are ever employed by being increasingly customer-focused and ensuring that as little time and energy (as well as money) is lost as possible.

All of the methods however, rely on bold leadership to take them forward with measurable goals. To truly capitalise on frugal innovation it may be necessary to reinvent your business model and introduce cultural changes through every aspect of management. This isn’t about cutting corners or offering “cheap” alternatives – it’s about providing the best, for less.

A question that rages within a tester’s mind often is whether her creative and exploratory skills alone are enough for manual testing (or ‘Sapience testing’ as James Bach calls it, giving the profession some respectability) or should she venture into the ‘technical’ side as well, supposedly the domain of the developer.

A smart tester will likely deduce quickly that to test better, this delineation between manual testing (viz. non-tool based, user personification with little/no knowledge of what lies behind the screen) and ‘technical’ testing (viz. manual testing enhanced with tools, technical systemic knowledge) does not matter.

So why is ‘being technical’ for the software tester such a big deal? Why are there so many related questions on testing forums? What’s the advice for a newbie tester or even for a confused one?

At the outset it must be understood that some take the step into software testing because they find development or coding difficult to get to grips with. On the basis of their curiosity, analytical thinking, meticulousness, persistence they could critique applications, survived and scaled. They could explore a domain and find defects without needing to worry about how the screen was programmed, what happens to the data, how’s it stored and so on…

However, many testers start down the road because they love the craft of exploration, to make a difference and to improve the ‘creation’. Maybe they used tools or looked ‘behind the curtain’ to some extent or not at all. Maybe they did a quick check into the database to check if the password is viewable, a quick record-replay script to setup the static data for the application and so on.

It could be assumed by some that both these types likely worked well with Waterfall-based projects where developers and testers worked in silos enough to leave each to their tasks and their comfort zones.

Since its advent Agile has induced a shift for software testers into becoming more ‘technical’ due to the expectation of a cross-functional team, need for collaboration and continuous delivery requiring usage of automation and tools.

So the choice of a methodology and the shift to Agile is undoubtedly a driver but that’s not to say that a tester need not be technical if it’s non-Agile.

If a smart tester wants to make a difference and make the creation better, would it stop at manual testing? As a thinking tester, would it not be incumbent upon her to think deeper to make her craft better? ‘Better’ in this case could mean delivering results faster, more intuition driven rather than donkey work, reducing duplication of effort, or simply finding ways to do stuff that a human cannot (i.e. a machine can be programmed to do instead with relative ease).

For example, the usage of Jmeter allows a tester to hit a server with hundreds of transactions where even a coordinated army of people will fail.

Why wouldn’t a tester use a tool to read web content to help simulate, empathise and raise issues on behalf of a blind-user.

If the same tests have to be repeated across different operating systems, browsers, devices why should the tester act dumb, indulge in drudgery even if in the most conscientious manner. When the tester can command a tool to do this all, then why not? Indeed she will need to cultivate a programming sense and learn to develop scripts in a language which can automatically exercise an application like a human. A mountain for some to climb but for many mountaineering is an enjoyable pastime.

It’s become a reality today that the software tester has to competently co-exist with a much larger team comprising developers, business analysts, architects and so on. The required collaboration leads to ‘interactional expertise’ which is significant not just for the team but for the tester as well. In the context of the topic thus the tester stands to gain understanding of development nuances – be it cache-handling when executing tests, memory management when performance testing, development patterns when scripting tests etc. when she works alongside with the developer. The extent of interactional expertise will depend on how ambitious and learning oriented the tester is. The technical gain for the tester coupled with her exploring-cum-analytical mindset, fastidious outlook, and penchant for perfection should help deliver greater good on the testing front, helping meet the user’s expectations for optimal application behaviour.

Yes, we well may still have a tester who will doggedly remain non-technical by choice, agile or not. It is argued by some that being non-technical prevents development bias and will help the tester impersonate better a non tech-savvy user. The conclusion somewhat easily derived is that being with such a disposition, she will test more effectively. The argument is weak and can lead to results bordering on disastrous if one sticks with such dogmas.

Imagine if the non-technical tester is called upon to test a SaaS based application? Or singularly tasked to reduce the test cycles by a third without compromising on tests? What might be the options if such challenges confront her?

One may be effective as a non-technical tester, but it will be so much hard work likely facing the risk of being ostracized or driven to obsolescence in a very dynamic world. Like most things in life, it’s all about being smart and learning to strike a balance.

So perhaps being an accomplished software tester is a bit like when riding a bicycle; it is best if one keeps alert of one’s surroundings, avoids sharp objects and keeps peddling onwards.

Fragile is a kangaroo word. Within the Fragile ‘pouch’ is agile and the two words in a literal sense may not be seen at odds with each other. However within the software development world, we can use the kangaroo word to tell a ruminative story or two and even draw meaningful insights

Note: The two words find a fair mention on the internet for reasons other than the fact that it jingles when spoken together, like ‘Agile Fragile’.

Agile today is all across and its influence is growing day-by-day. Agile is followed to improve the quality of releases, make teams more productive, achieve faster time-to-market through optimised engineering practices and so on. But then we know that Agile is much more than practices. More than the methodologies it has helped sprout, there is the mindset, the philosophy, the culture it helps nurture within teams for expected good results. So then do we really need to take all that is spoken or hyped about ‘Agile’ at face-value? What are the pitfalls we need to guard against or dangers of its misinterpretation? What are the bad habits (agile anti-patterns) that we tend to fall into? What do we need to incubate, inculcate and percolate so that success with Agile can be more assured. Let’s try examine.

Culturally at odds

Agile fails when the organisation which embraces it cannot adapt to make it work. Maybe it has the will but not the method. Maybe both get fumbled at times.

Agile is not a template or a checklist that can be simply adopted. It’s an exploratory cum experiment-laden journey into a land of high promise, openness, and innovation. It’s not an easy transition for many and perhaps due to lack of prescription etcetera, the journey becomes higgledy-piggledy, goes downhill, frustrating its followers with results going down south. Agile coaches help but they are not resorted to by most adopters. Often agile becomes ‘followed’ in organisations after a crash-course training by some ‘senior’ personnel and then through words like ‘sprint’, ‘ceremonies’, ‘retro’ that rule the whiteboards more than the human DNA. The essence or philosophy of agile is what should be embraced and the practices need to be conditioned by this hug.

Agile adopters tend to also succumb to the pulls and pressures of commerce swaying away from the people-oriented, ethically correct practices expected in Agile. The culture thus gets ‘coloured’ for good and agile goes weak in the knees.

New clothes but mindless

It’s been seen due to lack of correct ‘mindset’ that management intervenes and ‘deals’ with the agile team to try shape their correct working. It may be a too many status meetings, extra reporting or ‘tweaks’ made to practices that send the team down a wrong agile alley. Maybe the twisting is down to what was sold earlier on the back of a numerically poor estimate. The balance between autonomy for the team and information to the management when skewed towards the latter tends to disturb the equilibrium. The team then does stand-ups, and other practices more for pleasing or for namesake (ritualism damned ritualism) rather than to ruminate and become better through team retrospectives or being transparent and achieve big-picture understanding via stand-ups and so on.

Agile needs planning and management and the managers have a crucial role to play as facilitators, wisdom-providers, motivators and coaches. The team needs more operational freedom than they did in the traditional world. The team also needs reposition of trust to function without fear of failure.

Disjointed Collaboration

Agile accentuates the promise and concept of one-team, one vision within a group of multi-skilled people responsible for requirements management, architecture, development, deployment, testing and UI/UX.
As much as technology and tools today provide greater assurance to achieve frequent software releases to allow ongoing demonstrable synchronization with business needs, the team needs to collaborate and work effectively to make it happen.

The fragility arises when people cannot do what is required of them. Matters get compounded in agile since each iteration is 2-3 weeks short and pressure to deliver is unrelenting. Consider the following sub-optimal examples that teams sometimes have to grapple with

• The PO prefers working with a less than adequate product backlog
• The user stories are one-liners or provided at the last-minute leaving little room for team discussion and refinement
• The UI/UX person is shared across multiple projects
• Technical debt piles on and the customer rejects any move to deliver anything except functionality
• The team is unduly large / scattered across geographies
• The team is small but constantly over-burdened to meet timelines that cannot move

How is agile expected to stay resilient in such cases and deliver results? Unlikely, don’t you agree.

The business stakeholders have to provide in-depth subject-matter information that the team must glean and use to deliver working software consistently and demonstrably. The team must find ways to work together, feel empowered, and take ownership to deliver value with top management support.

The team ought to regularly introspect and boldly take actions to find optimal manner of working so as to deliver better solutions.

No documentation, we are Agile

Agile gives the wrong notions, rather the manifesto (…“Working Product over Comprehensive documentation”…) is misinterpreted by Agile adopters about what and how much to document. Teams need to be prudent and diligent about what represents useful and worthy of being written down.

For example, compromising on content expression or clarity within user stories may seriously hurt what gets delivered to the customer. A contrary but valued example is where a team agrees that common/repetitive acceptance criteria gets documented separately rather than in each user story they apply to.

An agile team must indulge in brainstorming sessions, use visual aids and face-to-face communication rather than crisscrossing email conversations. Waste of effort and ink must be equally denounced.

Even process documents may not be dispensed with since these may provide context and a sense of direction to the team members. For example a Project Canvas (an equivalent of Project Plan document) in a particular context or a Burn-down Chart maybe a useful wall-adornment for the whole team.

Documentation in an agile context must be deliberated by team and followed if needed rather than rejected outright. They will be worthwhile provided they positively impact what gets delivered to the customer.

Let’s sprint, think later

Projects need to be planned with business involvement upfront to clarify on business objectives, pain areas and so on. This holds true for Agile projects as well. Diving headlong into sprints without sufficient thought to what is to follow is a recipe for disaster. As much as Sprint 0 is what has come to be expected, the need to do more may still exist. Sometimes a discovery phase or an architecture definition phase may make sense to precede the sprints. The discovery phase could involve discussions, PoCs, story decomposition and development, product backlog formation, story maps, governance aspects, estimates of size, cost and timelines etc. This sets the tone, sequencing tasks and clarifies the roles that will need to be played.

Artefacts like definition of done, social contracts, definition of ready and similar maybe process documents but sets standards for the team to consistently achieve. They should not be seen as constraining, rather an efficient and a creative solution for some known ills.

It happens that teams are not adequately staffed at times to carry out some tasks e.g. code reviews if a technical leader is not available. In such cases the non-carry out of such tasks must be short-lived and not permanent. The team ought to see the fallibility of not following such processes and take steps to mitigate it like say paired programming.

Conclusion

So what must be done to ensure that Agile delivers results? There is no quick recipe but in brief considering what’s covered in this blog we could look at

• The organisation going agile should undergo a systematic dive into agile across the board which is monitored and tweaked as needed.
• Agile coaches could supplement the training, working closely with the leadership and the teams
• Ensure that the people in the organisation are assessed and recruited with consideration to role diversity, mindset, EQ and such besides technical skills.
• Regular conduct of retrospectives and town-hall meets at the program level to disseminate information about progress, way forward.
• Regular checks on team morale via surveys, etc.
• Inculcate and progress a culture of learning, openness, courage and innovation
• Employ and innovate engineering practices that improves the productivity, quality of deliverables and the overall efficiency
• Educate the customers with respect to how agile works and what may be expected

To reiterate, Agile is an exploratory cum experiment-laden journey into a land of high promise, openness, and innovation. Failure is surely not an option, so planning, questioning, adapting and reinventing is what should lead to success in the Agile journey, making agile non-fragile and cheery.

This immersive research activity requires the researcher to become involved with the activity, rather than just observing. Developed as a technique for better understanding the mind of the customer, ethnography is used at Arrk to gain a better understanding of the customer’s needs, wants and desires. Asking customers how they feel about a product or service, why it may be important to them, and what features they would like to see is just the start.

Ethnography is both a process and a product

As a process it involves using a set of analytical tools, which trained and experienced Ethnographers use alongside fieldwork – spending time with customers to observe how they interact with each other, products and their environment whilst paying attention to the surroundings where all these observations take place.

Ethnography is about generating understandings of culture from an emic or “insider’s” perspective.

“Emic and etic, in anthropology, folkloristics, and the social and behavioural sciences, refers to two kinds of field research done and viewpoints obtained; from within the social group (from the perspective of the subject) and from outside (from the perspective of the observer).”

As a product, Ethnography is the analytical culmination of fieldwork, participant observation, interviews and surveys.

Conducting Ethnographic research

Valuable insight can be collected via anecdotal information and stories, however, success ultimately lies in detailed analysis with theoretical tools in a systematic framework. The best person to help you realise this value is an Anthropologist, trained in ethnographic research methods, and with experience in the business world. The skill is being able to collect the right data related to the human experience, compile, interpret and report the findings.

The stages of Ethnography

A four phase process:

• Fieldwork (is the shortest, usually 2-3 weeks)
• Analysis
• Reporting (for which the elapsed time is scope-dependent)
• Valuation (conducted after release and again the elapsed time is scope-dependent)

Highly experienced Ethnographers should offer a Rapid Ethnography research service (Stages 1-3), time boxed to 3-4 weeks.

Ethnography timing

To ensure a full understanding of your target customer’s behaviour, interactions and unfulfilled needs, it’s important to complete Ethnographic research prior to work commencing on your MVP (Minimum Viable Product). This approach will also uncover what is not required, and, what is not important, which is a critical step to removing the need for any re-work.

Once your software has been released the fourth Ethnography Phase focuses on “Evaluation”, understanding how the software is becoming part of the customer’s life and how they are interacting with it. This phase provides the validated learning, and highlights the necessary changes and improvements, to ensure customer retention, and increase customer acquisition.

An approach to building your MVP which includes Ethnography, can, and will deliver significant results beyond a measurable return on your investment. To maximise this return, make sure your team includes a suitably qualified Anthropologist.

The genesis of this article came from a recent request by a start-up, who were puzzled why their Discovery and Inception workshops, and their Shadowing and Survey exercises did not equip them with enough meaningful information to build their MVP (Minimum Viable Product).