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

It is interesting to observe testers, especially folks new to testing, consider developers as the "other" group, the one's testers are up against. Some credit for such a notion must go to the organizations themselves for fostering this silo & antagonistic behavior without channelizing the efforts from both groups towards the common goal of releasing a quality product.

While newer methods such as Agile development require testers and developers to be partners and work together as one team, work needs to be done to make needed cultural changes and facilitate smooth cross-functional interactions and team work.

Looking at the relationship between testers and developers, one could probably say that testers exist because of what developers do ! There are many more such statements about the relationship between testers and developers. Here's one more - "If debugging is the process of removing software bugs, then programming must be the process of putting them in" and yet another helpful quote from a developer, "My software never has bugs. It just develops random features"

Producing and delivering a quality software product calls for all involved to work together towards a common goal while realizing that quality cannot be an afterthought or confined to a QA or QC team; quality must be the responsibility of both developers as well as testers and quality must be built into the product.

Thoughts on agile development, continued ...

Continuing on the subject of Agile development -
Agile, makes the assumption that neither customers nor software producers have a full understanding of what needs to be built. Contrast this with the traditional approach where the aim is to have the requirements defined and signed-off at the beginning of the software development lifecycle.
Agile projects involve learning through the project, leading to changes in requirements and how the system gets built. While traditional models are about "controlling" and "mitigating" change, agile introduces a different paradigm of accepting and accommodating changes. Traditional models involve extensive planning and regular monitoring to minimize deviations. Any such deviations are viewed as undesirable and attempts are made to get conformance of actual observed results to plan. In an agile model, any deviations from plan are treated as sources of additional information that help modify the plan to conform to reality.

Thoughts on Agile Software Development

Agile development presents an alternative to document-driven and rigorous process oriented software development methods. Agile, contrary to what is often believed, values planning, documentation, processes and tools. Before you wonder if this isn't a contradiction, let me clarify.
While, agile does value all of the items stated above, an organization that practices agile development must be able to state what it values "more". When push comes to shove, something must give. The organization needs to be clear on what is important and what gives. In an agile context, greater value is placed on working software.
While Agile practices may be applied to a wide range of projects, they are best suited for projects involving change and complexity; projects that involve risk, uncertainty and change.

Organizations that intend to adopt agile development must realize that the benefits from agile, such as increased productivity, shorter time to release, better quality, ability to embrace change, accrue from working differently and not just by working quicker. So, unless your organization is willing to change the way it works, going agile may not prove to be all that it's supposed to be.

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.

Google Wave

I've been wanting to play with Google Wave for a while but haven't had much time. Took some time off today to create waves and explore it some bit.

Initial observations of some features i thought were cool - playback of conversations and changes to the wave, inline replying, easy drag and drop of images to a wave (presently needs gears), creating new waves derived from existing waves, seemingly real-time instant messaging, collaborative authoring and editing that makes wikis seem dated, wave links and some interesting extensions.

I hope to spend more time waving and exploring in the days ahead.

Testing in the Agile World (Final part - 4)

Testing in the agile world, needs to adapt to change. The concurrency and shorter cycles introduced by agile development require not just testers but even their tools and processes to be adaptive too. Testers need to have a big-picture view and keep the customer's perspective in mind at all times. The tester mindset has to move from being considered as “custodians” or even “gatekeepers” of quality to being a participant in a larger group involved in defining and maintaining quality. Agile values the concept of a ”whole team” with everyone on the team being responsible for quality. Here, developers and testers are not pitted against each other unlike some of the other models; on the contrary these functions work together as partners to deliver quality artifacts.
The way in which tests get developed would need to change: from developing tests in isolation and based on documents such as requirements specifications, design, etc. to developing tests along-side code development, asking relevant questions, gaining quick understanding, refining tests on the go – also being able to quickly automate tests, test partial implementations as opposed to waiting for a completed artifact or feature - all are skills that are very much needed in the agile world. Testers do not necessarily get involved only when a feature is complete. Being able to pick up and test unfinished and in-process pieces while providing quick and useful feedback is important.

Testers should regularly communicate closely with customers or their representatives to both appraise them on the status of testing as well as obtain valuable feedback into the test activity.

Traditional models sometimes had formal QA teams that recommended processes and practices in a preventive way while the QC or testing group tested the finished product. In the agile world, teams are generally not keen on following much laid down processes although they do emphasize significantly on testing and its importance in product development.

In addition to the above, here are some more pointers for testers to add greater value in an agile world.
  • Performing incremental tests on work products as they are being produced. This does not in any way mean that testers perform unit testing nor that testers duplicate the unit test efforts that developers do. Testers should bring their expertise to play and develop and execute business focused tests that could be exploratory in nature and augment the unit test efforts
  • Testers in the agile world need to be familiar with the tools of the trade. Being able to go beyond their areas of specialization is expected. Testers should be comfortable with the development environment and handle tasks such as checking out source code from the repository, use the version control system, build system, use an IDE, know the language and be familiar with technologies used in developing the product, be aware of the frameworks used and so on. Testers on agile teams cannot afford to remain detached from the tools and technologies involved in producing software
  • Tester need to be able to work on limited requirements specifications and communicate effectively with product owners / customers to better understand the requirements and clarify assumptions. The ability to integrate and work well together with a cross-functional team is a required skill in the agile world
  • Testing in the agile world is not merely about doing exploratory manual tests. Testers perform various test types that would be performed in a traditional model, albeit based on the importance and requirement as assessed by the needs of the customer. Also, test automation is an important activity that happens in addition to manual test efforts
  • Testers should focus on tests that tend to integrate different features and operations. Maintaining a solutions approach to testing helps identify any issues which may not be captured by way of feature or unit focused test efforts
Quality in an Agile world is the responsibility of the entire team. Agile testers need to learn and apply agile principles to enable the whole team to produce a quality product. Agile testing requires testers to be  pro-active, creative, willing to take up different tasks, quick learners and adaptable to change, in short – be Agile !

Liked this entry? Join my community of professional testers to receive fresh updates by email. Use this link to add your email address to the community. Rest assured, I will neither spam nor share your email address with anyone else. Your email id will remain confidential. Subscriptions are handled by Google's FeedBurner service.

Related posts:
Testing in an Agile World
Testing in the Agile World (Part 1)
Testing in the Agile World (Part 2)
Testing in the Agile World (Part 3)