Corporate fire fighting

What does it mean to you ?

A sense of being busy, on the run, panic, stress, rush of adrenaline, hardly any time to stop and think, and of course, heroic efforts to douse fires that seem to be springing up everywhere. If any or all of these sound familiar, you aren't alone. Many organizations have integrated fire fighting into their very DNA, so much so that you could be considered a slacker if you appear calm and unruffled. Lack of time is often cited as a reason for short-circuiting adequate planning & risk management. There is never enough time to do the job right, they say. We'll somehow have the time to fix issues and patch things up later. The constant busy-ness and worry take the focus off of prevention of fires and towards combating them.

When fighting fires is a regular part of work, often times organizations tend to reward and recognize the heroes, the ones who are adept at dousing these fires. It is useful to remember that what you reward is what you will get more of. Also, bear in mind that in a corporate setting, some of the best firefighters could be the best arsonists too. Regular rewards and recognition of the heroes who fight fires rather than the ones who have not caused any fires can quickly lead to a flaming inferno that's hard to manage.

What ? This doesn't happen ? Look at your group's reward structure. Whom do you recognize and reward - the individual who works all night to meet a deadline while producing average quality code, the individual who stays up late to fix issues … in code they themselves have produced or the individual who delivers solid output that has been adequately tested within the given time ? It is easy to miss a hard-worker who delivers without much fanfare while doing the right thing.

When faced with a fire, take a step back to see the big picture. It is easy to miss the forest for the trees here. Divide your resources – it is not advisable to pull in all your resources to  fight a fire unless the situation truly demands it. Some project staff need to be insulated from firefighting so they continue to deliver on critical areas. Some fires may not really need to be doused. Evaluate the consequence of letting a fire burn. What is the opportunity cost of involving your resources to fight the fire versus letting the fire burn. Whom does the fire impact most and how important is it to them ? Such and related questions should help you create a strategy to fight your fire.

While it is strongly recommended that we prevent fires, there will be emergency situations. What we must do is to perform a thorough post-mortem of each fire, analyze its cause, the factors contributing to the fire, cost of the fire in terms of both the damage as well as effort involved in fighting it and steps to prevent such a fire from happening again. An often cited requirement for preventing fires is – more time. We are very busy fighting fires now. Give us more time and we will work on preventing fires. Frankly, that most often does not work. Work and busy-ness have a tendency to expand to fill any available time.

The Energy Bus

I recently read the book, “The Energy Bus” by Jon Gordon. It is an interesting read and offers ten rules for infusing your life, work and team with positive energy. The book is in the style of a fable that takes readers on an inspiring and insightful ride while revealing ten rules for life and work.

It's Monday morning and George walks out of his home to his car and finds a flat tire. Great way to start the week, but this is probably the least of his problems. His home and family life is in shambles, while his team at work is disillusioned and looking set to fail. With a big new product launch coming up in just two weeks, George has to find a way to pull it off or risk losing both his job and marriage. Trying to fix the flat tire shows up other problems with the car requiring additional repairs that literally force George to take the bus to work. Here, he meets a special bus driver and a diverse mix of co-passengers who, over the course of two weeks, share the ten rules for his life and work. During this process, they help George turn around his work and life from failure and destruction.

As the book says, everyone faces challenges. And every person, organization, company and team has to overcome negativity and adversity to define themselves and create their success. No one goes through life untested and the answer to these tests is positive energy; the kind of positive energy that consists of the vision, trust, optimism, enthusiasm, purpose and spirit that defines great leaders and their dreams. The book provides an actionable plan for overcoming life and work obstacles and bringing out the best in yourself and your team.

The 10 Rules to Fuel Your Life, Work, and Team with Positive Energy

1.    You’re the Driver of the Bus.
2.    Desire, Vision and Focus move your bus in the right direction.
3.    Fuel your Ride with Positive Energy.
4.    Invite People on Your Bus and Share your Vision for the Road Ahead.
5.    Don’t Waste Your Energy on those who don’t get on your Bus.
6.    Post a Sign that says “No Energy Vampires Allowed” on your Bus.
7.    Enthusiasm attracts more Passengers and Energizes them during the Ride.
8.    Love your Passengers.
9.    Drive with Purpose.
10.  Have Fun and Enjoy the Ride.

Testing as part of Development activity

Testing should be a part of the development activity and not be relegated as a separate function, to be performed post development. Here are a few “things to do” to enable this.

Involve testers from the start

It makes a lot of business sense to involve testers from the requirements phase itself. Testers can better understand the product to be developed, test the requirements and help clarify requirements better. As is common knowledge, it is least expensive to fix a defect at this early phase rather than at a later stage, such as a post implementation phase of testing or even later, when the cost of fixing defects escalates drastically. Testers can begin working on developing test plans while also checking to ensure testability of requirements.

Require Developer Testing


The minimum requirement from development should be to perform Unit testing. Testing groups should ideally receive report of tests run and results, along with information on any open issues or workarounds, before accepting a build for more formal testing. Unit testing helps catch issues much sooner with lesser turn-around time involved in addressing issues. Also, a “stable” build to the testing team enables testers to be more effective and reduces time spent on test / fix / test cycles. Other useful practices that may be adopted include – test driven development which is part of an agile development methodology. Also, having developers perform a set of integration tests, with their module integrated into the larger application, can be pretty useful in identifying more common and basic issues. These integration tests need not be extensive or complex and can involve a basic set of tests. Often developers tend to stop with unit testing their module or area of work. However, on integration with the larger application, newer issues tend to show up. Having a set of integration tests also being run, in addition to the module level tests can be very useful. The idea is to avoid delivering a “broken” or “poor quality” build to the testing group. Having testers blocked on basic features / items wastes a lot of time and effort as well as involving a lot of back-and-forth interactions to communicate, analyze, fix, check-in, re-build and re-test.
Leverage test automation

Test automation is not just for testers. In fact, developers can and do leverage test automation to test their work. Testers and developers working together on a common automated framework to develop and run tests is a good idea. Tools must be chosen that can support such a scenario and does  not involve a steep learning curve to learn a new language required by the tool. Tests may be added incrementally – developers as they develop new code, can add in new tests while testers can use the framework to build more complex tests. A common framework eases communication and helps to benefit from synergies of working together. Other good practices to follow include, building automated test suites (generally regression) and having these run against regular builds (often on a nightly basis).
If you are not already using it, you might want to consider using a continuous build / integration system and tying in your automated regression suite to it. When a build is generated, you can have a set of automated tests run on it and mark the build accordingly based on the results of the tests, observe the stability of builds, analyze test failures and be notified of any failures. We use Hudson at my present organization.
All of the above relates to the point I mentioned in an earlier post – Software Quality is the responsibility of everyone involved in producing the software. It is not confined to just the Quality / Testing team. Quality must be built into the product and the Development team (as also the Testing team) has an important role to play in building a quality product.

Testers and Developers: A Strong Engineering Partnership

The relationship between testers and developers should not be built around handoffs and blame. It should be built around shared ownership of product quality and different but complementary forms of technical judgment.

Developers know the implementation path. Testers often see user workflows, edge cases, integration risk, and ambiguity from a different angle. The strongest teams use both perspectives early.

What each role brings

Developers bring design knowledge, code context, technical tradeoffs, and the ability to prevent defects close to the source. Testers bring risk modeling, exploratory skill, test design, product skepticism, and evidence discipline.

Neither perspective is enough by itself. A developer can miss behavior that only appears across roles, data states, or user journeys. A tester can misread a failure without understanding implementation constraints. Collaboration closes that gap.

How collaboration looks in practice

  • Review acceptance criteria together before coding starts.
  • Discuss testability, observability, data setup, and error handling during design.
  • Pair on complex defects to shorten diagnosis time.
  • Agree which checks belong in unit, API, integration, UI, and exploratory layers.
  • Treat escaped defects as system feedback, not personal failure.

The credibility factor

QA professionals earn influence when they communicate with evidence and understand enough of the system to ask strong technical questions. Developers earn trust when they treat testing as part of engineering rather than a late inspection service.

Good software is not built by one role protecting itself from another. It is built by teams that make risk visible and act on it early.

How this shows up in QA leadership

A QA leader can use this idea to improve the quality conversation in a team. Instead of asking only whether testing is complete, ask what risk has been reduced, what evidence supports that claim, and what decision the team is now better able to make.

That is the difference between QA as activity tracking and QA as technical leadership. The strongest quality professionals make uncertainty visible in a way that helps people act.

Training Camp: What the Best Do Better Than Everyone Else

Just finished reading the book “Training Camp: What the Best Do Better Than Everyone Else” by Jon Gordon. It is an interesting read and here's a brief summary.

This book looks at what makes someone great in their field of work. The best in any field - sales, sports, business, etc. share a set of similar characteristics. There are things that the best do that others do not and things that they do better than everyone else. There is a way that the best of the best approach their life and work and craft that makes them stand out from the rest.

The book, in the words of the author, tries to inspire the reader to strive to be your best and bring out the best in your team - be it at work or elsewhere. The book is in the form of an engaging story of an un-drafted rookie footballer, Martin Jones, trying to make it to the NFL. Martin has spent his entire life proving to critics that a small guy with a big heart can succeed against the odds. In his first pre-season game, Martin stuns everyone with his performance and gains attention. However, during the game, Martin sprains his ankle pretty badly and is out of action. When he thinks that his dream of making it to the NFL is lost, he meets a special coach who shares eleven life changing lessons that could make him the best of the best. It is an inspiring story filled with nuggets of wisdom and insights on what it takes to excel as individuals and teams.

Irrespective of the field you are in, these eleven lessons have wide applicability.

1. The Best know what they truly want
2. The Best not only know what they want, but they want it more
3. The Best are always striving to get better
4. The Best don't do anything different. They just do the ordinary things better
5. The Best zoom‐focus
6. The Best are mentally tougher
7. The Best overcome their fear
8. The Best seize the moment
9. The Best tap into a power greater than themselves
10. The Best leave a legacy
11. The Best make everyone around them Better

The book has several interesting insights to offer. Some such as getting out of your comfort zone push folks to overcome their sense of inertia. If you are always striving to be better then you are growing which in turn means that you are not comfortable with the status quo. To be the best, you have to be willing to move out of your comfort zone and embrace discomfort as part of the process of growth. The book tries to break a popular myth about overnight success. Many people believe that star athletes, top performers, and others were born that way or simply stumbled on their success overnight. The best tend to make what they do look so easy and effortless that people either think anyone can do it or that there are the few chosen ones who alone can do it. People see the outcome and not the countless hours of toil, dedication, practice and preparation that lead to greatness. Do not settle for mediocrity, but strive for excellence every day .

Readers are exhorted to not focus on the past, nor look to the future. Focus on the "now". Success, rewards, fame are merely by-products for those who are able to seize the moment. Ironically, to enjoy success you must not focus on it. Instead, you must focus on the process that produces success. While striving to be the best, you must not ask what your greatness means to you but what impact it makes on others. The success you achieve now is temporary, but the legacy you leave behind is eternal.

Greatness, ultimately is a life mission and being the best really is not about being better than anyone else but about striving to be the best you can be and bringing out the best in others.

The Agile Tester Mindset: From Gatekeeper To Quality Partner

Agile testers create the most value when they stop acting as gatekeepers and start acting as quality partners embedded in the team's flow of work.

In traditional delivery models, testing often becomes a late phase. Testers receive a finished build, execute planned tests, file defects, and provide release status. Agile delivery changes that operating model. Testing must become earlier, faster, more collaborative, and more adaptive.

From Custodian To Participant

The old idea that QA is the sole custodian of quality does not work in Agile teams. Quality belongs to the whole team. Developers, testers, product owners, designers, operations, and security all influence whether the product can be trusted.

The tester's role does not become smaller in this model. It becomes more influential. Instead of owning quality alone, the tester helps the team understand risk, ask better questions, define better examples, create better feedback loops, and make better release decisions.

Testing Partial Work Is A Skill

Agile testers cannot wait passively for perfect requirements or complete features. They often need to test partial implementations, evolving workflows, and changing assumptions. That requires flexibility, product understanding, and strong communication.

Testing unfinished work does not mean lowering standards. It means giving useful feedback while the team can still change direction cheaply.

What Agile Testers Must Be Good At

  • Clarifying requirements through examples and edge cases.
  • Identifying product, technical, data, and integration risks early.
  • Designing exploratory tests around ambiguity and user behavior.
  • Working with developers on testability and automation.
  • Understanding enough of the technology stack to diagnose issues credibly.
  • Communicating residual risk without creating release drama.

Automation And Exploration Both Matter

Agile teams need automation because frequent change demands fast feedback. But automation does not replace exploratory testing. Automated checks are strongest when expected behavior is stable and repeatable. Exploratory testing is strongest when the team needs learning, discovery, and judgment.

The agile tester mindset is knowing when to automate, when to explore, when to ask a product question, and when to challenge a design assumption.

The Whole-Team Quality Model

Whole-team quality does not mean "everyone tests, so we no longer need testers." It means everyone contributes to quality from their area of influence. Developers prevent and detect defects close to the code. Product owners clarify value and acceptance. Testers strengthen risk thinking and evidence strategy. Operations and SRE improve production visibility and recovery.

Agile testers are most valuable when they help the team build quality into the product continuously. The goal is not to guard the gate at the end. The goal is to make the gate less dramatic because risk has been managed throughout the journey.