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.

“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.

DevOps has evolved into a global movement, yet it is a term that still generates confusion. Many organisations are aware of their need to enable more efficient delivery. Everyone recognises the existing points of failure, but when it comes to deal with them very little action is taken within the organisation.If you are new to DevOps, I recommend checking out our first article: what is DevOps.

This article will address DevOps from a practical approach according to the most common problems I’ve found in organisations.

My experience

Any IT transformation consultant will tell you there are a set of patterns that tend to get repeated in every company, therefore forcing the same problems to appear. From a DevOps perspective, that is absolutely true. The concept of DevOps covers a wide range of activities directly or indirectly related to the software delivery lifecycle (SDLC), which, in its nature, encounters multiple problems often easy to foresee.

Communication and collaboration are absolutely essential to keep processes in order and work as a whole. What happens is that teams tend to fall into the habit of repeating the same actions all over again, even when it is commonly known that issues are there.

As an IT consultant, I’ve had the chance to experience how silos are created within a company. It is interesting how open people are when having a conversation with an external consultant. Everyone acknowledges the issues, many know the causes which frequently point to the lack of cooperation between teams. A few even know how these would get solved, yet the organisation lacks initiative to push things through. The DevOps “philosophy” can help.

Most common challenges

Deployments taking too long

Distributed applications often require more than ‘copying and pasting’ files to a server. The complexity increases when having a farm of servers. Uncertainty about what to deploy, where, and how, is a normal thing. The result? Long waiting times to get our artefacts into the next environment of the route to live delaying everything, testing, time to live, etc.

What does DevOps bring to the table? Development and IT operations defining a deployment process in a “blameless” collaboration session, verifying what works and then taking it to the next level with automation to facilitate continuous delivery. This dramatically cuts timing for deployment; it also paves the way for more frequent deployments.

Missing artefacts, scripts and other dependencies

Closely related to the previous point. We frequently encounter failures recently after a new version of a working piece of software is deployed, often caused by missing libraries or database scripts not being updated. This is caused by a lack of clarity about which dependencies to deploy and their location. Again, fostering collaboration between development and operations can resolve these sorts of problems in the majority of cases.

When it comes to automation, dependencies can be defined which helps a great deal in speeding up deployments. Configuration management tools like Puppet or Chef contributes with an extra level of definition of dependencies; we can define not only dependencies within our application but also at infrastructure and server configuration level. For example, we can create a virtual machine for test, and install/configure tomcat before our artefacts are published.

Confusion about what to test

Testers also get their fair share of confusion as the functionality deployed is not clear or not shared in a common backlog, the QA team does not know what exactly they have to test. Obviously when that happens untested functionality goes through the route to live until production, therefore exposing systems to unpredictable errors.

When the QA team is included in daily stand-ups and/or planning sessions predictability increases, it allows the team to prepare user cases and distribute the work before hand. Furthermore, having multi-team stand-ups promotes development-testing collaboration and provides a daily platform for the QA team to ask operations questions about the development work.

Slow test processes

Many defined use cases are executed manually all over again; some of them are long and laborious but composed of multiple simple steps with zero challenges. Those activities consume man hours, preventing the QA team to focus on more innovative tasks.

Under an ideal DevOps landscape those repetitive use cases can be automated. Adoption of test automation tools like Selenium, Rally or HP QT free up the QA team for other critical activities.

Unavailability of environments

For those with development background, how many times did you deploy a test environment, only to find out that it fails? Downtime is a frequent issue; again IT operations cannot foresee or plan in advance if communication with development is low or inexistent.

Simply by the fact of bringing development and operations together to define processes and needs will translate into notorious results. Defining a clear process and configuration elements and then adopting configuration management tools such as Puppet, Chef and Ansible is a good strategy to aim for. The beauty is that you can automate the creation of a virtual machine (either in-house or cloud-based) before deploying, then configure that virtual machine, then deploy your artefacts, and finally, run a set of automated tests.

Ineffective production monitoring

Sometimes monitoring tools are configured in a way that produce a lot of irrelevant data from production, however, other times they don’t produce enough or nothing at all. There isn’t any definition of what needs to be looked after and what the metrics are.
Agree on what to monitor and which information to produce, and then put controls in place. Application Performance management tools are a great help if your organisation can afford it take a look to AppDynamics, New Relic and AWS X-Ray.

Firefighting instead of innovation

One common scenario is spending most of the time in ad-hoc repetitive tasks or solving emergency issues. Hence, the team is left with no time to innovate and create, and, over the years turns your IT system into a legacy monolithic system. I suggest doing some reading on IT bimodal organisation.

Adopting DevOps practises and technologies certainly requires investment of time and money; there is a learning curve which many organisations are reluctant to assume. Once that barrier is overcome the advantages outweigh the disadvantages. I found that those organisations who carve out some room in the budget to bring external consultancy will normally get the investment back. Getting to build a DevOps pilot is a great first goal.

High dependency on specific individuals

There are always a few individuals more talented or dedicated than the rest, those who seem to know everything about new technologies or who writes “magical” scripts to solve a specific issue quickly. The problem is that these people adopt the problem as their own problem instead of escalating it to a team level. Usually, they do so to avoid bureaucracy in companies that are not open to explore alternative solutions or technologies.

Invest some time for innovation, let your development and operation teams investigate and come up with new solutions. You can do that by assigning specific individuals and separating them from the daily tasks, or rotating that role to motivate the team. Listen to their proposals, and, as a team, consider the benefits.

Conclusion

Achieving a fully operating DevOps landscape won’t happen overnight. There are many changes to address in terms of mindset, definition of processes, and technologies. Split your goals into quick wins, medium term and long term, define your success criteria for the future compared to where you are now. Approach the journey with baby steps, it takes less time than you expect to reap the benefits.

This is a fictional account of a day in a tester’s life in 2049. As much as I have relied on some research material (see list at the end), this blog is a figment of my imagination intended to entertain more than anything else. The term ‘tester’ in the context of this blog is used for convenience sake and ease of understanding. I am imagining that the term could remain relevant amidst the massive technology leap and perhaps an unimaginably different world that might confront us in 2049. The characteristics of exploration, creativity and problem solving being the hallmark of a good tester will always stand the test of time which is exemplified in the story that follows. – Author

3 am June 15, 2049 – “Hey Alok, wake up… wake up man”.  Alok sat bolt upright, somewhat dazed but awakened by the voice of Stella, his supervisor from InnerDrishti Solutions. 

“Hi,” said Alok to the flickering image of Stella on the white graphene panel on the wall. The room was very dark with little light coming from the windows though he could somewhat discern the cloudlike haze around his apartment on the 456^th floor. He fleetingly saw some streaks of lights likely from cars zipping across the dark night sky.

“Lights come on.  Hey Stella, what’s the matter?” Alok said as the room instantly got lit in translucent light blue configured for this time of the night.

“Alok, well a couple of issues… someone hacked into the state’s Citizen Locker and stole a lot of sensitive identity information to be able to impersonate virtual identities… fortunately, the encryption logic was not compromised fully so we have a problem that can wait…but not for long.”

“Umm… and what’s the other problem, sleep related” asked Alok as he started gesturing to wake up the projection of an internet console. Alok gestured again to skip the sleep-related diagnostics (patterns, dream analysis, BP, RLS, oxygen levels, breathing rate, heart rate etc.) that would anyway have been uploaded into his health chest at Grand Sushruta Hospital. He mentally reminded himself to meet his doctor who had called him a couple of times about several warnings that had burst his health thresholds.

“Let’s get to work” he muttered somewhat angrily even as he saw Stella lips breaking into a smile.

“You remember the DNA related algorithms that were deployed a few years back…for St. Beaumont Hospital at Virginia.”

“I remember.  This is the one that Drishti implemented for gene altering processing and results reporting on the human genome. The project dealt with modifying the human genome so as to create designer babies that the parents could custom build. I remember having collaborated with several brilliant doctors around the world. The information they provided helped me to test effectively with help from Tokina, of course.”

“Correct. Pity you could not fly across the world to collaborate… Maybe you should have been born a generation or two earlier…”

“So what’s the issue with GeneOS?”

“Alok, we have noted in some GMO (genetically modified organisms) babies that they develop blue rashes all over the body once they age five years. This is followed by growth of cancerous cells in the body, multiplying quite rapidly. There seems to be no cure since we cannot figure out what is happening and to make it worse, some infant deaths have been reported. It makes complete sense to not delay any further.  Check the data on your console. ”

Alok started skimming the information that Stella projected on his console. This included doctor’s reports, photographs, medical reports of various kinds.”

“Do we know that GeneOS is the only cause?”

“That’s proven by an investigating team comprising some doctors in Virginia and Vikas Kapoor who developed those algorithms.  Vikas was flown over especially for this purpose. They have ruled out all other algorithms except ours. They want you to urgently analyse with Tokina’s assistance. Your past experience of testing the algorithms will help, we think”.

“Fine I will take care, Stella. Anything else?”

“Nah, take care. Bye”.  The panel sputtered, shone a bit and darkened.

Alok rubbed his eyes, got up and moved towards the bathroom. The lights dimmed behind him and he could hear the very faint whirring of the hidden cameras / sensors that digitised his every movement taking photos and capturing information all the time, by the petabytes. All the information was no doubt used for both right and wrong reasons and Alok had stopped caring. Maybe one day with increased affluence he will buy his way out towards more privacy was a thought he often thought even if illusorily.

The lights in the bathroom wore a faint yellow-green colour and as he pee’d, information started flashing on a console. He was a major in pharmacology and he usually paid attention to ‘warning’ numbers crossing the thresholds but not today.

He looked in the mirror and said “Lights white”. His tousled hair even if genetically grown looked great and quite natural in the white light. There were bags under the eyes which was no surprise considering how hard he had worked of late. His body frame was lean and he looked much younger than 35 years.

He thought of the call and he needed to get in touch with Tokina.

Tokina was a hyper-advanced version of a service robot created for InnerDrishthi to perform super-computing tasks like vector arithmetic, big-data analysis, simulations, advanced forecasting, testing and so on. She was programmed for years, fed on millions of data bytes which included user analytics, BI data, programming constructs, testing algorithms, and so on.

Alok had worked with Tokina during the GeneOS implementation and he recalled the inconceivable speed and precision with which Tokina delivered results. Tokina was a cute humanoid with advanced AI, neuroprosthetics and reasonable consciousness allowing her to nearly look, feel and perform like human. Her sheer utility could be gauged from the fact that Tokina once successfully broke into an inter-continental hacker group in a matter of minutes driven by her processing over 50 million passwords per second.

“Call Tokina” commanded Alok and instantly the graphene panel came to light.

“Hi Alok, how’s the weather there?” Tokina looked exactly like he had seen her last (droids don’t age) – beautiful but freakishly cold.

“Tokina, remember the GeneOS testing that we did?”

“Yes, August 2046 – 526 hours and 54 minutes of testing”.

“There are problems detected now with some genetically altered babies but the dreadful results are seen after 5 years. The babies develop blue rashes and even die in some cases. I sent you the reports”.

“I did read. 25 babies affected out of 348; 10 dead”. Tokina had access to St. Beaumont Hospital’s data.

“Tokina, how many other vendor APIs and algorithms are we interfacing with?”

“There are 18 other vendors. 766 interfacing with”

“Okay. Here is what I want you to do. One, you need to check all the medical data in health chests of those babies afflicted but yet living with rashes. Compare these with those that are healthy and find the differences. Two, do the same check but this time with those who did not live. Three, compare the data of those diseased babies who lived and died. Got it?”

“Yes, the reports are on your console.” Tokina suddenly cackled with laughter for no reason.  Alok was used to such volatile unfathomable quirks of behaviour.

Alok and Tokina worked for several hours but found nothing wrong. They checked doctor’s reports, autopsy reports.  For the reported cases they pored through DNA/RNA sequence re-combinations / modifications, the Nucleases related algorithms that were used and the results both before and after the genetic alterations. Alok knew that all the heritable (raw) material used for altering the babies were selectively bred in highly quarantined sanitised labs with results rigorously verified many times over through automated means.

“Okay Tokina, let’s call it a day for now. Will call you again, if needed.”

“Sure Alok, take care!” Tokina mentioned somewhat dryly as she signed off.

Alok moved towards the window and could see the sky turning orange. He noticed some drones flying eerily past. His view was filled with dark concrete structures of buildings which seemed to get taller by the day.  He hated the view and yearned for those periods from the very distant past when humans lived in greener and more natural environments.

Despite a strong inner urge to feel the air on his face, he dared not open the windows. The early morning air was putrid and qualitatively poor said the reading on the window pane. Where was the earth headed? He wondered, how long?

Alok felt remorse and could not help going through all the investigations he did with Tokina. Even with the most advanced humanoid, he had drawn a blank.

Just then a thought struck.

From the labyrinth of his memory, he recalled vividly a conversation with a doctor involved with GeneOS many years back. The doctor had mentioned about some quality norms violations for an artificially grown gene plasmid to favour an organisation called GeneTek run by an ambitious megalomaniac multi-millionaire.

“Hey, check my audio recordings around January to June 2045 with a New Zealand based doctor”.

The console started playing his conversation with a Dr. Martha Jennings. She had indeed mentioned the risk of the gene misfiring and giving undesirable results. Alok had at the time reported the conversation to his supervisor but was told about how a panel of doctors had debunked her claims.

A quick check about Dr. Jennings whereabouts revealed she was now retired, into her 80s and living near the coast of Punakaiki.  Alok quickly connected with Dr. Jennings, apologised for calling so early (it was 7:30 am) and explained what the call was about.  Dr. Jennings took a while to respond but confirmed that the plasmid definitely might be the culprit and was worth investigating.

The lead was followed through with investigations, record verifications and other checks, some with Tokina’s help, with Vikas and other doctors. After a period of 7 days, the plasmid was finally confirmed as the cause of the blue rashes leading to infant deaths.

10:30am, June 24 2049: There were four of them in the conference room at InnerDrishti Solutions. Alok was physically present while Stella, Ashutosh (Stella’s superior) and Vikas had teleported themselves from various parts of the world. The meeting was called to commend Alok for cracking the ‘blue-rashes babies’ case.

After some (virtual) back-slapping around the table, Ashutosh summed it up rather poetically as it appeared to Alok.

“In this age of super highways in the sky, when human hearts can be printed at will, and super-computers are the size of sugar cubes it feels wonderful that a human tester could think and resolve a problem that machines and automation could not.”

References

Genetic engineering

Gene editing will transform Cancer treatment

Meet Sophia, the human-like robot

Nuclease: Definition, Function & Activity

7 ways cities are going to change in 100 years

110 Predictions For the Next 110 Years

2057 – Michio Kaku – The Body ep. 1

2057 – Michio Kaku – The City ep. 2

2057 – Michio Kaku – The World ep. 3

Project discovery workshops, most reading this article will be familiar with the term and what generally takes place during them and therefore why they are so critically important to the success (or failure) of a software development project.

The way we go about them at Arrk follows our defined and flexible EmbArrk methodology, which means we usually spend a two or three week period at the customer’s location (the gemba) where our team collaborates with all customer stakeholders to envision and elaborate, even if at a high level, the solution for the customer enunciated and (Arrk) elicited business needs/problems that the customer is facing.

The moot question that this article looks to answer is what value the tester brings during discovery workshops and why we need their participation. The EmbArrk crew, at most times, comprises a Business Analyst, a Technical leader, a UX/UI champion and a Test leader. As much as the Business Analyst drives these discovery workshops, the technical and testing member play much-needed complementary roles (i.e. 3 Amigos).

The tester’s contribution to the discovery process can be better understood if her role is clarified.

The Case for Curiosity

Testing happens better on the basis of understanding of what the domain is; be it the business, its mechanics, or the application in use. Testers, by nature, possess the needed inquisitiveness and more to probe deeper through questions, observations and hypothesis.

This curiosity complements that of Business Analyst and helps the domain knowledge to unfold broader and deeper benefiting the entire group. The tester by virtue of the customer provided overview sessions, understands first-hand what the business drivers are, what it expects to gain from the solution, what the quantifiable measures linked with the objectives are, the product roadmap and so forth.

The knowledge and her interaction with the business stakeholders facilitates the drawing of system boundaries, components within which interact and how, the workflow, who uses them etc. She even mentally or physically creates user personas to focus her tests and impersonate these stakeholders when testing.

The Case for Testability

The user story development benefits as the tester influences the story details, the acceptance criteria, questioning the likely implementation and so on. A key element that will be at play when the stories get discussed is that of ‘testability’ and the tester is the (Wo)Man Friday that the team desperately needs. Testability at its simplest refers to ‘how we test’. But testing is never truly simple and testability as such is greatly influenced by:

How much is known about the application?

”The difference between what we know and what we need to know is why we test in the first place” – James Bach

It follows then that more the information about the application, its users, testing can get better.

Documentation available (including test cases)?

This aids the application working knowledge thereby helping test better.

Application complexity?

Simply put, the higher the complexity, the harder it is to test. Example; a mission-critical product requires deeper careful testing than a shopping cart application.

Application size?

Example: a multi-module application interfaced with 3rd party apps requires more elaborate testing… more the code, more the bugs that can be expected so tests need to travel far and deep.

User interaction with the application?

When this is learned through observation, usability tests, etc. testers can mindfully work the application like the ‘user’ would.

What technology is used for the application?

Example: an iOS app has different standards to meet requiring a specific testing approach than an Android app. The tester may have knowledge specific to the language, tool and technology which she will utilise to ease the testing effort and efficiency.

What tools can be used to test better?

Example; certain application protocols used may necessitate specific plug-ins to be used when using LoadRunner tool which the tester is best aware of.

Competence of tester?

A more competent tester tests better and faster and highlights issues to ensure a faster feedback loop:

• Technical skills | A more ‘technical’ tester can have richer conversations with the developers so as to target areas to test.
• Soft skills | A tester having more skills on communication, collaboration, negotiation, assertiveness, initiative front is likely to more positively contribute to testing.

Past experience of the tester?

Example; prior exposure to data-warehouse product based testing will make future testing experiences in the same area more effective

Time available for testing?

The more time made available for testing the more stringent the testing will be and conversely, less time allocated for testing can have a negative impact on the effectiveness of testing.

Therefore it should now be apparent the benefit of having a tester present during project discovery workshops. Who can better speak for and determine testability than the tester who has spent her life in testing, day and night, thinking and doing, dreamt tests, laid awake at night thinking data combinations to provoke a defect or many, etc. As much as testing may be done by anybody, it requires great perseverance, thought, creativity and an exploratory problem-solving mindset to transform testing into an art and a craft form. Such testers provide fantastic value to a team tasked to tango together for a discovery workshop.

The Case for Testing Thought Leadership

Based on the above, a high-level strategy or a mind-map representing the thought-process of the tester in how she will test the application, types of tests, tools that will be employed, data, risks and so forth is created as one of the outcomes of the workshop.

Based on understanding through first-hand information, observation, discussions, clarifications, mental models – the strategy is expected to be well-designed and rich in content that will go a long way to begin testing on the right note. Along the way, the smart tester will likely make a point or two in letting the customer know that the application-whenever-under-test is in safe hands.  The assurance so provided to the customer is worth its weight in gold which may or may not be verbalised.

To conclude…

As much as the benefits of having the tester in discovery workshops / EmbArrk should be understood by now, let me express explicitly which puts a lid on this article as well:

• Assist in collective knowledge acquisition.
• Apply unique mindset that thinks functional, non-functional, testability, user-centric, business-centric, destructively and constructively to question, challenge and clarify the knowledge build-up
• Assist in solutioning aspects from story development to estimates to a release plan
• Ensure customer expectations of the application quality are understood so as to be taken care of through strategy formulation and testing carry-out.
• Ensure incorrect assumptions about testing are nipped in the bud
• Build rapport, provide assurance and demonstrate capability to test

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.

“Be the change you want to see in the world” Mahatma Gandhi

These words mean much to us and they have unconsciously driven us to work towards a successful transition from the waterfall to the agile testing world. This article contains our collective thoughts about the journey that we went through, what was entailed, the skills we needed, the mindset shift and so on.

When it comes to comparison, it sometimes is assumed that Waterfall is some kind of an archaic thing that we must overcome and outlive. Well, far from it we see it only as a journey and from amongst this group, some testers have seen through projects successfully with waterfall methodology. We must realise that a method is needed to solve a problem in a given context, and the method may be iterative, waterfall or say Scrum. A project may come along and as testers (or as software professionals) we need to be up for any methodology, just as an archaeologist has no hang-ups about terrain or geography.

The Early Days | The Waterfall Tester

Waterfall as a methodology had tradition, solidity, predictability (being sequential) and assurance on its side. As testers, we mostly got involved later in the development life-cycle and meticulously progressed testing with application understanding, analyzing voluminous specs, written tests, defects, some fights, triage meets, multiple test cycles, phases of testing and so on… It was an orderly world that we lived in on one side of the wall and there was even a cushioned sense of protection provided by test leaders / managers, who called the testing shots.

As testers we confined mostly within ourselves and sometimes with the developers and business analysts to elicit, analyse and exchange information. Obviously, testers were closely knit and relations with ‘others’ would flare up at times given the ‘us-versus-them’ syndrome that existed. There were adventurous amongst us who ventured ‘into the beyond’ and even profited but somehow the ‘misdemeanors’ did not spread too much. We did our bit though with great passion, logged defects, negotiated and even suffered anguish when application shipment went through the ‘gate’ despite the ‘unfixed defects’ and  ‘their lack of concern for quality’. The defect leakage was a talking point then too. Sometimes the leaders would protect us from the defect leakages that came from the customer yonder, while at others we would bravely try to withstand the onslaught on our own, providing justification or looking sheepish at other times.

There were good times too, mind you. There were projects which were driven well by project management who looked at us with equal eyes, and led the team as a whole towards a common shared objective. Yes, we recall projects and parties where we bonded well and partied hard and so what if they were not testers! Alongside we learnt about intricacies of stakeholder management, requirements management, program specs, development pitfalls, language jargons and more that was part of their world that we did not see often. We shared the testing bits as well and some empathized.

Today, the role of an Agile Tester

“During my initial days with agile projects, I would see a user story akin to a requirement id like in waterfall and I recall being concerned when each and every little rule was not meticulously detailed by the Product Owner…” Shiv

The advent of Agile has first and foremost meant that the walls did not segregate us. Thus we are now out in the open free to observe, challenge, interact, speak and contribute. The onus is as much on us as on the rest of the team. The notion of a singular team is now reinforced more than ever (even though this happened sometimes within waterfall projects as well).

In our day-to-day tasks, we have to be proactive to pull tasks, coordinate and take to closure. For tasks like effort estimation, for example, we work as a team with each member expressing what effort it would take to complete a work-item.

“This is so much in contrast with how my test manager would come and tell me to do the test design by so and so date” Akshatha

“What I really like is that I can listen in and even contribute to technical discussions be it during look-ahead, planning or common analysis meeting” Apurva

Being in an Agile team environment, we tend to develop into more than just what testing demands from us. Yes, we need to identify at all times the impacted areas and ensure the test coverage is comprehensive enough so that the story is tested and in a shippable state. Or that automation needs to be done alongside development, or performance, usability and other quality criteria checks need to happen early and continuously (rather than later as a distinct time-boxed pre-release activity as it used to happen in another era after a functional test cycle completion). The scope for the tester to grow beyond the testing boundaries and with the cross-functional expectations of Agile has been a huge plus.

“I love the challenge of writing feature files in collaboration with the developer who helps me with the step definitions to be developed in Ruby and in tune with the database. It makes me so much more aware of the development side of things. During the discussions, I also understand the creator’s tools and mindset as much as the developer probably does of me, not just a hammer-man anymore” Akshay

As part of iteration work, we have to configure / manage test environments, create test data, report defects and work with the team to resolve them.

“We do not need to hold triage meets at periodic intervals. They happen every day” Shiv

We constantly need to collaborate with product owners, developers and business stakeholders to clarify the requirements, especially in terms of testability, consistency and completeness.

“Thanks to Agile, we participate in team retrospectives, suggest and help implement improvements. It gives us a sense that each team member is responsible for application quality” Akshatha, Apurva

Challenges we faced switching from Waterfall to Agile

This transition was not easy though, it took a while to get adjusted with the new ways of working. “

“I eventually understood that everything need not be documented in great detail within a story or that it is not the responsibility of the Product Owner alone. I saw first-hand that the story acquires better shape via the refinement it undergoes based on team discussions” Shiv

The team analyses the stories and agrees on the acceptance criteria along with implementation aspects, impact analysis, considerations for automation, responsiveness, usability and so on…

Going Agile meant testing small and continuously rather than waiting for a big build to be deployed to go hammer and tongs at it.

“I had worries about testing smallish elements within stories in isolation and more so about the other stories that I already tested in the previous iterations” Akshay

Automation, Continuous integration and a hardened sprint at the end ensures that the application is fully tested.

“The challenge of automation seemed a mountain at first but when this was conquered by persistence it freed me up to do non-mundane, smart testing” Akshatha, Akshay

Automation also becomes easier given that the developer is close by to help make it effective and more efficient. Collaborating with them has exposed us testers to how development with patterns, standards etc. ought to be and automation is development anyway.

It is accepted that testing has to happen in tandem with the developer, because the team needs to deliver at the end of sprint. This is something very challenging and tricky at times. If a story gets delivered late for testing with the demo date looming, and the story has to make the cut for business reasons then we (and the developer) have to burn the midnight oil. In such cases (rather in general) collaboration with the developer to assess areas impacted, agree tests to perform and say cover off some initial testing in dev environment really helps smoothen what happens  when we test manually or with automated checks…

“I recall my earlier days where finding defects was one of the key motives of a tester, which is no more the only objective.” Apurva

In Agile the focus is on regular delivery of working functionality and to achieve that it is important to avoid or prevent defects in the first place. For times immemorial, this expectation has been set and this is not illogical or unreal. Agile has brought this to the fore and we play a central role.

How did we do it?

As more and more projects turn to Agile, the question for testers today is not when but how. The tester’s successful transition is dependent on how quickly she acclimatises (including in her mind), understands the agile way and starts in earnest.

Our recommended ‘success’ recipe for the agile tester is:

• Positive attitude
• Exploratory / analytical skills
• Communicate, collaborate and actively elicit information from team, technical and business stakeholders
• Test with hands. Test with tools.
• Perspective, ability to see big picture
• Out of box thinking
• Adapt, respond to change quickly
• Get technical to do the job effectively
• Fearlessness
• Growth mindset

Evolution is always good and should be seen in a positive light. As long as there is a demand for quality products, testing will continue… Testers are therefore indispensable, provided we upgrade ourselves to meet the challenges head-on.

We had great fun discussing, brainstorming and putting this together.  It is hoped that this helps a budding software tester make the journey or even for some testers to relive their transition they have had.

Jaikishen Sharma, aged 32 is a budding software tester working for an IT startup, with a penchant for experimentation. He innovates not only at work but also in life. He started out working as Business Analyst but being an explorer at heart, he found his true calling in software testing. He’s known in his organization as a master bug-hunter adept at finding problems that others often miss. Besides his professional pursuits, he is fond of mountaineering, reading, contributing to political causes and teaches poor children on weekends.

Jane Sharma, aged 29 and English by birth, is Jai’s loving wife. She’s both career-oriented and a dogged home-maker and lends a sense of sobriety to the happy-chaos that Jai is always so full of. They met at a common friend’s house 7 years ago, found solace in each other’s company and married uneventfully after a brief courtship. She works as a Project Management consultant when not cooking, tending the roses in the garden or negotiating the vegetable prices at the local bazaar.
———————
It’s Friday, 9:30 pm Jane finds Jai sprawled on the sofa with an open book and a faraway look. Shaping his hair in his customary but distinctive style, his brown tousled hair temporarily lay in check.

“Anything bothering you? What are you thinking about?”

“Umm, a new experiment was announced today. A presentation on ‘Pairing’ was made by a wannabe manager as part of the Agile embracement program that Argon is getting into.” (Argon Software is the name of the IT startup where Jai works).

“I have worked with Waterfall all my life with builds thrown over the fence by devil developers and now they want me to ‘pair’ with them. How am I going to cope?” Jai looked up at Jane with a slight frown.

Jane inquired calmly “Pair with who? What will you do differently when you pair?”

“Well, Ash, the developer, and myself will analyse the story together and chat about it. The story is written but there’s so much implicit stuff within that we both need to unravel and handle while coding and testing. She’ll let me know what part of the codebase will get changed, the schema / tables changes, what part of UI will be revamped and how she will test with Junit.”

“And what’s your contribution going to be?” Jane asked in a voice somewhat muffled by the toffee in her mouth.

“Simple, I will let her know how I will test it. Since I know the application far more than she does, I will let her know the other application areas where the impact might be so that she does not miss and create a regression impact.”

“Isn’t this the same Ash you had a tiff with earlier?”

“Yes,” Jai gently eased up mindful of his posture and the slouch that Jane commented about, often.

“Aishwarya Thakur, she seems nice otherwise but not sure why she tenses up and gets offended whenever I speak about her infected code during the Standup? My job is to go after the code with a hammer and bring down the structure if I can,” Jai said with a malicious grin, his eyes crinkling with joy.

“I remember the adjustments I have had to make with you – no slippers in the kitchen, no meat in the house, wearing a sari during Diwali…”

“And what about me when I visited your home in Bristol. The sheer politeness, the subtle humour – I just could not make sense of… but having loved and lived with you… I have begun to enjoy the ‘British way’, as you call it,” again his eyes crinkled that Jane so loved.

“So Jai, these are different mindsets or cultural differences at play and even at work, isn’t it? But it should help once the ice breaks and finds commonalities. The relationship and rapport should improve. Surely you will learn a lot about each other’s technical skills as well which will benefit the team integration,” Jane spoke with wisdom borne out of the many consulting assignments that she was so good at.

“Oh yes, I learnt today that Ash is a Sagittarian like me. And during lunch, we gorged on dhoklas. It was great. My technical skills are bound to grow since she’s so good with Java & Groovy… should help me immensely in making better use of WebDriver and SoapUI.” He got up and stretched his tall lean frame, the ‘Om’ locket glinted in the night-light.

Jane started to yawn but controlled it soon enough.

“This pairing will happen frequently, I guess?”

“As and when the development starts Ash will check with me or I will peek over her shoulder checking if she has covered this and that scenario. I can even help her with her unit tests. That way I will stop bugs leaking over into my environment. I intend collaborating with her a lot about the tests that I am likely to write. I mean if I know there are some common elements which are coded and reused in multiple places, I need to test once… saves my time. With short release cycles, I need all the time I can get.”

“Sounds interesting, a bond should build between you on the basis of the constant dialog and the differences should be a thing of the past.”

“Yeah, hopefully. Tomorrow I am seeking her help over an assert that I am finding difficult to code. I am sure she can crack it.”

“Chalo, let’s sleep now,” Jane said yawning uncontrollably.

“Coming… let me finish this chapter on ‘Test Driven Development’. After ‘Pairing’ Argon is going big with TDD,” Jai said his head already deep into the book.

The increasing acceptance and implementation of Lean principles by software companies is becoming a phenomenon. Whether these principles are introduced as values, guidelines or via the book, it can make a significant impact to individuals, teams and organisations. We are hearing (as well as being involved in) more and more examples of Lean implementation, often under Lean Transformation Programmes.

Lean however does come with its own set of challenges and complications. Companies that find it difficult to imbibe and transform with Lean, more often than not overlook or fail to embrace the following:

1. Lean isn’t just a set of tools or a change program that can run its course over a short period; it takes considerable time for organisations to change and evolve
2. Lean is a change in thinking which doesn’t apply only to specific departments or functions, but even the upper echelons of management and the organization as a whole
3. ‘Respect for People’ a significant yet complex aspect of lean is mostly overlooked leading to disrupted implementations

Many texts exist on Lean and its implementation across various industries, which do re-iterate the value of Lean Transformation. Once organisations embrace Lean as a philosophy or way of thinking its many benefits can be realised.

One of the key benefits is the identification of value generation stream and eliminating the non-value adding activities termed as ‘Waste’, to improve quality, speed, efficiency and productivity. ‘Waste’ is any process or activity that doesn’t add value, with value measured and defined by customer needs. For efficiency sake, we need to identify waste (i.e. inefficiencies, variations, deviations and any other non-value adding activities) in the processes and people practices followed in software development.

This blog is an attempt to put various activities in software development under the lens of ‘waste’ and identify some activities that can prove detrimental to the end result of fulfilling customer needs.  Before we do, it is pertinent to briefly understand the seven wastes of software development¹so that these can be seen, understood and eliminated.

1. Partially Done Work | Until the software is actually used by the user, it is likely not satisfactory/ incomplete/ failure-prone/likely to be rejected or become obsolete/…
2. Extra Processes | Examples being more paperwork/too much detail within requirements etc.
3. Extra Features | gold-plating, more code than necessary typically adding complexity or requiring more maintenance, inject bugs etc. [1]
4. Task Switching | includes non-sequential work or work multi-tasking/hand-offs between team members.
5. Waiting | includes delays of any kind (e.g. in staffing, start of testing, getting approvals) that impedes the value delivery to the customer
6. Motion | e.g. non-availability of stakeholders, distributed teams, artefacts sent for review
7. Defects | not finding defects early enough of any severity or impact is a waste

[1] Adapted for software development by Mary & Tom Poppendieck

Pre-Sales

This is a critical activity for any company and one that “brings in the money”, ensuring sustenance and continuity of operations. Contract bidding, price negotiation and navigating politics are vital to be successful. Efficiency can only be derived and improved through the tasks performed by individuals that enable companies to make that final bid. Listed below are probable wastes that are generated and how we may eliminate them.

Example of Waste	How to Eliminate
Excessive documentation (Extra Processes)	Ensure regular communication with customer, regular grooming of user stories
Same-role multiple reviews (Task Switching/Waiting)	Knowledge sharing; proper roles and responsibilities
Lack of team work, time lag for communication and limited information (Waiting)	Team workshops
Estimation not done scientifically due to poor analysis/information gathering (Partially Done Work)	Knowledge sharing; joint estimation and story sizing with customer
Relevant stakeholders not tapped for eliciting needs/requirements i.e. poor stakeholder management (Motion)	Proper stakeholder analysis (via RACI matrix/The Power/Influence v Interest Grid)

An argument can be made by sticklers that aspects like requirements study, analysis and research for projects that the company incurs but doesn’t bid for, is a waste. From a Lean perspective however this is ‘useful waste’ (provided it is indeed used) which won’t add immediate value to the particular task per se but will help build and consolidate the domain knowledge.

Analysis and Design

The typical outcomes generated as part of this activity are plotting user journeys, persona development, digital simulations and lo-fi prototypes, architectural designs. Typical waste can include:

Example of Waste	How to Eliminate
Lack of collaboration during analysis (Partially Done Work)	Scheduled catch-ups with customer/PO to discuss value generation in delivery as part of backlog grooming
Wrong choice of technology or solution (Defects)	Technical spikes
Dependency on a single source (Waiting)	Regular knowledge sharing sessions; team centric approach and development

The skill sets critical here are decisive thinking, foresight and thought collaboration. Value addition cannot only be attributed to current project implementation, as certain tasks performed during this activity might be beneficial in the long run.

Requirements Management

This activity involves the discovery, eliciting and documentation of business needs (via specs, epics, user stories etc.) that are required to be addressed in the probable solution.  This is an area that can be prone to waste.  In Lean software development projects, the principle is to define just enough detail to stories just in time for development to begin.  Examples of waste in this activity include:

Example of Waste	How to Eliminate
Documentation that is too detailed (Extra Processes)	Collaboration with team/customer; deliver working software regularly
Switching meeting rooms/re-scheduling sessions (Motion)	Plan better!
Missed or misunderstood requirements (Defects)	Regular knowledge sharing; automated testing (e.g. BDD/ATDD)
Lack of appropriate and skilled resources (Extra Processes)	Better ways of working; cross-functional team
Delay in feedback and approval (Waiting)	Ensure regular communication with customer

Development and Testing

Although Development and Testing have traditionally been two distinct activities, in Lean software development, the two work extremely closely together and so the non-value adding tasks arising out of the two are listed together. Both involve a level of standardization, innovation and critical thinking to deliver optimal solutions.   Common wastes include:

Example of Waste	How to Eliminate
Lack of domain knowledge, inadequate impact analysis, and ineffective test strategy (Partially Done Work)	Regular customer/SME involvement, user workshops, adequate documentation
Refactoring due to missed requirements (Defects)	Regular impact analysis, ensure trace-ability, ensure customer involvement in demos
Technical complexity not analyzed properly during spring planning (Partially Done Work)	Ensure a technical spike before estimation
Lack of transparency (Partially Work Done)	Regular communication to team; effective usage of task board, team wiki
Assumptions/clarifications and impediments (Waiting)	Raise red flag before moving into danger zone ensuring guidance from stakeholders, track impediments effectively
Lack of ground-level analysis of the tasks required for the stories (Task Switching)	Ensure judicious splitting of stories into tasks and its ordering

Pre-requisites need to be created and adhered to, before individuals begin their tasks. Pre-requisites can be in terms of defining standard coding or testing practices, impact analysis during grooming/planning ceremonies, determining integration planning & coverage, and resolving queries before they impact the work just before it needs to happen.

Recap | How to eliminate waste in software engineering

• Define ways of working and create standards | Set clear standards for the team to be followed (e.g. via Definition of Ready, Definition of Done, Social Contracts, Checklists, Code quality benchmarks) to determine when the task can be deemed complete. This will help maintain the balance between over-work and the right amount of work needed to get the job done.
• Defining specific roles and responsibilities | These go a long way in clarifying, reducing overlap and over-processing for many of the tasks. This ensures that there is no compromise in the flow.
• Strategizing based on long term vision | Designing and developing solutions with an eye for future help in reducing the re-work and refactoring that might be needed later. Ensuring Release planning based on Minimum Viable Product via key stakeholder(s) involvement
• Maintain focus on present deliverable | ‘Eye for future’ and ‘focus on present’ is a duality conundrum. Being aware of the lean principle that states ‘Decide as late as possible’ works best. For example, one doesn’t  need to test on environments to check handling user load of 100,000 users when the current & near future expected traffic is 10,000 or thereabouts. As individuals and organisations, we need to be pragmatic in formulating a strategy that sufficiently tackles both aspects.
• Smarter documentation | Documentation is a quintessential aspect of any project and we cannot live without it. However, determining the right level needed is far more important than just falling in the trap of documenting everything. Excessive documentation upfront in a project doesn’t add much value since the finer details are bound to change, also not many read pages and pages of text. The entire pre-text of Agile is to engage in conversation to hash out finer details and deliver incrementally.
• Continuous knowledge sharing and transparency | Helps in avoiding dependency and ensures smooth workflow in delivering only what the customer wants. Also enriches the collaborative knowledge built within the team.
• End user empathy | Closely relating to the needs of end users, helps in defining the exact deliverable needed. Developing a high-tech and modern application is of no use if it doesn’t resolve the problem or it goes beyond what the immediate need is.
• Selection of appropriate process and tools | Ensures optimum utilization of time and resources, and reduces the waste of ‘Over-processing’. Tools also mean automation – the more the better.
• Cross-functional and dedicated team | A fact that cannot be stated more. Ensuring this aspect will ensure consistency and higher productivity.

All the aspects stated above are standard management principles covered across other methodologies in some form or another. One might ponder then, what is different in the Lean teaching?
Lean teaches us to take the holistic and people-oriented view to interpret the essence of deriving efficiency by identifying wastes. What it calls for is a deeper introspection in how we do our work, recognise the end goals and model our actions to deliver maximum value by eliminating waste as we identify them. This can be achieved by orienting our processes and practices such that our efforts in achieving the end goals are truly justified and optimized.