Points to ponder – Agile or Not!

One of the great things about working with Agile teams is that people gradually lose their inhibitions and become more open with their ideas. This is more common with a team that has been together for a few releases. There is an inherent trust in the group, and people voice their thoughts or opinions without any fear of being ridiculed or struck down – and even if they Are struck down, they can hold their own and expand on their ideas, argue, or banter till the cows come home. This is something I miss a lot from my old workplace.

This is a collection of my tweets, thoughts, opinions etc. that have come up over some time – some while discussing the concept of Agile/Scrum with co-workers, some while reading someone else’s blog or some literary article etc. Each of these could be a blog post, or the topic of a group discussion.  So whether you practise Agile or not, possibly whether you are in the IT industry or not, here are some thoughts on qualities and values I believe in, such as openness, integrity, customer centric actions, collaboration, knowledge dissemination, diversity etc. Maybe they will be quoted with my byline some day?

 While evaluating market conditions, how much analysis is too much, and how much is too little?

What is the smallest unit of time you break down your work to?

Is Avoidance always the best choice while resolving a conflict? Or could it worsen an already problematic situation?

Facilitate – help bring about, or make easy. Facilitation does not involve telling people HOW to do something.

Is attitude more important than aptitude? What if you had to choose one?

Collaboration means not holding back on your wildest ideas! An idea kept to yourself stagnates; talking about it leads to fruition!

Cross training is not only for contingencies - it can also create a better respect of what fellow team members do!

Collaboration begins in the mind.

Do colors contribute to the efficacy of information radiators? Imagine all task cards, charts etc. only in black and white!

Do you jump in and emulate your competition, or take the time to analyze?

Fear is often the underlying reason for resistance to change.

How often are you accommodating while resolving conflicts?

What would you rather do – empower your team, or hold power over them?

Whether you use Scrum or not, capturing and retaining tacit knowledge is still a big challenge for continued product success.

Your Scrum team is only part of your complete end to end business cycle. Are they in sync with your Scrum team?

Shorter time to market may not be very lucrative unless you have the pulse of your target users.

Welcoming change is the best thing you can offer your customer.

How does diversity affect your team throughput? Or is a group of similar people more productive?

Hey Ma, I want a 3 story bungalow!

Is your child influencing your buying decisions? And are you allowing them to impress you so much that you lose sight of reason? The ‘dream merchants’ or advertisers in India certainly seem to think so.

Once upon a time, when I was a rookie studying marketing management, we learned about the buying process, and how there was an influencer and a decision maker. Just for a change, I am relying on memory as it is, without resorting to this decade’s addiction of trying to Google the ‘buying process’ or something similar just to make sure I am saying the right thing. And giving in to another lifelong addiction – laziness – I am not going to trudge across the house to hunt out my copy of Philip Kotler to look for some diagram I vaguely remember. For now, let us agree that most promotions such as advertisements are targeted toward a specific person or buyer. It is assumed that the target audience or customer will identify with the character in the advertisement, and then want the same thing for himself or his loved ones. 

From the protective husband in the Prestige pressure cooker ad, or a grandpa selling chyavanprash for vitality, to a housewife endorsing some detergent, these were mostly adult folks. The few advertisements that featured kids were related to food items such as cooking oil or Bournvita, soaps (Pears) that made little girls pretty like their mommies, and Rasna, the Indian equivalent to KoolAid or Tang. When we were growing up in the ‘70s and ‘80s, kids were a happy lot, busy stuffing themselves with candy/chocolates, chasing butterflies and scraping their knees ( Savlon, Burnol etc.).

Flash forward to some of the current ads on Indian TV. Ad makers have really put the spotlight on children now. Judging by the money that goes into making these ads, and the millions needed for buying spots on cable networks, the number crunchers must really believe that kids are the influencers today. And that kids can pester or persuade their parents until they make, or rather submit to a buying decision. Kids have a footprint on almost every product line. Hundreds of kids sing for the Coca Cola video, some frolic because Hyundai the car maker has a big sale on, kids warn their parents to buy them the proper insurance cover, or save up for college, kids take their parents and other grown-ups to McDonald’s, and what not! Almost every billboard for housing has a few kids splashed across them proclaiming how they ‘love’ certain things in their new home.

How effective is this kind of advertising? Is this supposed to strike a soft spot in the adults’ mind, evoking emotions such as ‘how cute’ and prompt them into action? Or is this supposed to make an instant connection with the kids, who will then become brand ambassadors who will not rest until they bring a Hyundai car home? Or make their parents invest in a fund for the kids’ future.

Rapid urbanization, elevated lifestyles, excessive media exposure, and a growing (as opposed to aging) population can all be contributing factors to a new social environment. Does this threaten the sanctity of the family unit? I think the onus is still on the adults to enforce ground rules and keep things in perspective. A four year old demanding a Mercedes or a trust fund should still be ignored (unless belonging to the Pitt-Jolie or Trump clan maybe). Coke or Pepsi cannot be allowed to replace drinking water. Parental controls need to be enforced on cable channels and websites and eight and ten year olds maybe do not need Facebook or Twitter accounts. Parents still hold the reins over what is acceptable behavior, and hopefully they also hold the reins to their wallets.

How effective then are promotions featuring toddlers and pre-teens? Only time will tell, and it will certainly depend on how much ‘influence’ the decision maker in the buying process (You) allows them to have.

Diversity – Have we really embraced it?

As the year draws to a close, I would like to write about something which is talked about a lot. Almost everyone says they welcome it. Some have it as part of their organizational values. While some distinguish themselves from the milieu by proclaiming they practise it. I am talking about ‘diversity’, the trait that almost every company around the globe professes to have.

The most obvious association to ‘diversity’ that anyone might make is the ubiquitous disclaimers we see around us, relating to religion, color, age, national origin, ethnicity, marital status, sexual orientation etc. etc. etc. But does hiring a bunch of people who belong to some minority group make you fit the bill? Indeed, given the current lack of geographical boundaries in business, it is almost a given that you will have to associate with someone who is culturally different than you, and this could be challenging for many people. I think Indians are at an advantage here. India being secular, any random group of people is typically made up of people practicing different religions, speaking different languages or dialects, having different cultures, skin color, facial features etc. Growing up in a ‘crossroads’ type central region, I was certainly exposed to all this since a young age.

This post though is about something far beyond that. I personally feel that accepting diversity means having an open mind, being open to possibilities, being open to something that you have never seen or contemplated before. Diversity means accepting that people need not be better or worse than you, but just different. Or that your co-worker’s life may have a different trajectory from yours. Diversity can also show you that a senior person who has worked for 30+ years can have great tacit functional knowledge that you as a techno-geek with 2-3 years’ experience can never have, and vice versa. Either person contributes something valuable which may not always be quantifiable. Diversity means that a ‘suit’ or ‘college degree’ can contribute a lot from their formal education. And gray hair can sometimes transcend a piece of paper. The examples are many, and I am sure each of us has come across some form of this.

There are also some organizations that have set criteria regarding their workforce. They prefer their people to live in a short radius from the workplace. Or need a person to have a certain college degree or certain grades. Some view higher degrees as a threat. Some prefer people who have very similar bios, or similar academic credentials. They are almost afraid to introduce any element that is ‘different’, perhaps dreading interpersonal conflicts. These could be management directives, or the whimsies of any decision making individual. Such organizations definitely miss out on the potential enrichment of their workforce. One person with a different background can add to the knowledge base of your entire team and make them think outside the box. This further leads to innovative ideas that can benefit your business. And it could be the intangible bit that allows you to beat your competition. The time has come to stop viewing diversity as a threat.

Diversity is inevitable. And a diverse workforce will always produce higher synergies. A progressive organization will recognize that diversity will enrich them, and this can happen only when every person truly accepts it and welcomes it, by keeping their mind open to all possibilities.

Test Data - crucial step in test prep

This post has been long coming. I would like to end this blogging gap with a topic that has stalled many a testing effort of mine. We take a brief look at what test data is, how or why it is important, and then see how it fares in an Agile world.

The availability of the right test data is or should be the most important part of your test entrance criteria or test readiness checklist. Depending on the complexity of your application, and the kind of testing you need to perform, this could be an easy or herculean task. Testing a GUI application would probably be more intuitive, where your test data would be formed of various rules, field validations, boundary conditions etc. Testing a batch application would be more complicated where there are several permutations and combinations possible for not just one but several fields in a record. So a file with a record containing a hundred fields would definitely be more arduous than one containing five. Enter multi-files or other data formats like hex etc., and your complexity has gone up several notches.

Some organizations have dedicated departments that work solely on test data generation. This is a specialized skill that needs some finesse and experience. Following are some of the test data generation techniques I have come across and/or practiced –

1)  Testing the UI – As mentioned above, this is easier, but not any less important. You want to test all possible validations, even things as simple as not allowing alpha characters in a number field. Boundary conditions should also be tested, and so should specific error messages if mentioned in your specs. A well written detailed specs document is a pre-requisite for this kind of testing.

2)  Batch Testing – Developers provide data in many cases, since they have already used it for unit testing. It is beneficial to use this as a template, and generate several files with different test conditions, for detailed testing of each field or for negative testing. You may also have to build a file from scratch, based on the given file design – anyone who has done this is sure to remember this with a groan.

3)  Data dumps – Data dumps obtained from production are a great way to test with realistic or actual data. This can also enable volume testing where you want to check if your new code can sustain large amounts of data.

4)  Data Scrubbing – Scrubbing is very important, especially in industries like finance or healthcare, where NPI data is moved around from place to place. ‘Data Scrubbing’ is used to blot out all personal information, and dummy characters or random numbers inserted instead. This is generally carried out by dedicated test data generation departments, based on ‘rules’ provided by the test team.

5)  Data Generation tools – In-house tools are sometimes built for data generation. These tools ask a user to enter certain details, and use a set of rules and some random data to generate relevant information. For example, to generate data for all fields required for a loan application, the user would enter something like Age or kind of company such as Sole proprietor or LLC( for the condition being tested), and the tool will randomize and provide all data required for a valid application.

6)  Automation – Data driven testing is pretty popular and part of any test automation suite. This is one more instance where test data availability is crucial. Existing automation suites can be repositories of test data and can be used as a resource for future releases.

I think you get the idea here. I am sure there are several other methods for test data generation out there. Seasoned testers may even have their own special spins on this. We now come to the next question – how to handle test data on a Scrum team.

Most methods given above take time and planning. Sometimes there is ‘paper-work’ involved in dealing with other departments or other teams. These may not be Agile even if your team is. This leads to bottlenecks or delays that are difficult to surmount. Following are some steps that may be followed to avoid barriers or obstacles in your testing tasks –

1)  Highlight the importance of test data and note it as a pre-condition. This could be done by noting this as a part of your entrance criteria or checklist. This could also be a precondition on your WBS or placed on the critical path.

2)  Research and publicize the effort needed to generate test data for a given story. Solicit the help of the Scrum team members, and add task cards to establish accountability. Keeping the effort within the Scrum team will reduce wait times and allow this activity to be prioritized or ordered appropriately.

3)  Develop reusable repositories of test data that can be used in subsequent iterations.

4)  Interview actual business users, product owners etc. to obtain realistic values to test end to end business flows and document these for future use.

5) Establish SLAs with outer teams such as Data Generation units to respond quicker to Agile teams and have shorter turnaround times.

6)  Cross train testers or DBAs on Agile teams so that they are able to carry out complex data generation tasks. DBAs or developers might be better qualified for this since some tasks may require production access.

7) SOS – coordinate and disseminate information across Scrum teams. It may be possible that the same test data is being generated by other teams. Collaborate to reduce duplication of work.

There were many occasions when test data was a stubborn member on our ‘barriers’ board and just wouldn’t budge. This is one item without which a serious testing effort cannot be complete, and should be treated as a pre-condition for product release rather than just for testing. Test data generation can be so much smoother when everyone on the Scrum team assumes collective responsibility for it.

Scrum and the Product Owner – Can you do without one?

The Product Manager has always been an important role for any product development company, whether your product is a car or a piece of software. The product manager manages one or more products, and shapes its creation right from concept to design to creation and production. This is what Wiki tells us about the product manager.

Any software project has a customer or sponsor who hails from the ‘business side’. What this means is that this person knows the company’s line of business and products inside out, and more importantly has a direct line to the actual customer or end-user. That may be why this individual is sometimes referred to as a ‘customer proxy’. Knowing your customer then is key to establishing what your target market segment is, where your product should be positioned, and indeed this will not only drive what features your product should have but also what the product itself should be.

Agile or Scrum has the Product Owner to perform this function. As any basic text on Scrum will tell you, the Product Owner is an integral part of the Scrum team. The product owner is responsible for the success of the project and has to ensure that it delivers appropriate returns on investment (ROI).

Roman Pichler offers a pictorial depiction of all the duties of a product owner. He also suggests that the product owner needs to be in the driver’s seat all the time.

Jack Milunsky sums up the product owner’s activities nicely.

Following are what I feel are some of the desirable traits of a product owner –

1)      Be 100% engaged

It may not be feasible to physically be with the team a 100% of the time, but a product owner should certainly be available to the team via phone, email, chat etc. This will encourage the team to raise flags instantly and resolve backlog related questions early on, saving a lot of time – a critical entity in a time boxed sprint.

2)      Product backlog champion

The product owner owns the product backlog, and needs to know it inside out. (S)he should also work on it constantly to keep it up to date. The product backlog should reflect the latest customer priorities for the product, or critical product features at any given time. Ordering (or prioritizing) the product backlog is another crucial task for the PO. This should happen continuously even during a sprint, so that extra time need not be spent on the backlog during the next sprint planning session.

3)      Own the product, be tuned in

The product owner is ultimately responsible for what happens to the product and hence for the outcome of any sprints/projects of the Scrum team.  The product owner should be aware of all daily updates, burndown etc. and have a clear picture of where the team is headed at any given time. The product owner should be able to cancel a sprint if needed, and should also be able to steer the team so that they continue to work toward delivering the sprint, and hence the product backlog items.

4)      Subject Matter Expert

The product owner should know the minutiae of a given product line, its features, the importance of each feature, user behavior, drivers for certain product attributes etc. etc. In short, the product owner should be a veritable encyclopedia on anything related to the product. 

This is necessary to establish trust and rapport between the developers and the product owner. Just as consistent velocity and successful sprints will establish the skill of the developers in a Scrum team, in-depth product knowledge and ability to get questions answered will establish the skill of a product owner.

Practically, there may be a learning curve even for a product owner, assuming an otherwise skilled product owner who has taken on a new product.

5)      Willingness to learn

It is quite difficult to be as omniscient as Yoda! A product owner should exhibit a willingness to learn. He/she should not hesitate to ask questions as needed. They could be product related questions for which the product owner needs to elicit information from multiple sources, or could also be process related questions that a Scrum Master can answer, or something related to the dynamics of the development team.

6)      Collaborative and communicative

Collaboration is the cornerstone of any Scrum team. The product owner should be an eager participant in any discussions related to stories or backlog items, since their comments can change how a particular item is built. This can result in cost savings even within a 2 week time boxed sprint.

The product owner should not hesitate to deliver news – both good and bad – to the Scrum team. The product owner should be friendly toward the team, and be able to embrace the ‘everyone at par’ mantra of Agile. The product owner should also be patient and take a back seat when needed, allowing the team to self-organize.

The product owner should happily co-exist with the Scrum Master, and if needed heed to the SM’s feedback regarding workload, team morale etc.

This is by no means an exhaustive list. Jim Trott provides a good list of necessary attributes of the product owner. 

A product owner may need to apply different strategies for success depending on the industry, the product itself, timelines, a particular team etc. But one thing is certain. The product owner is the driving force behind any Scrum team and an integral part of one.

To sum up, a product owner is a liasion between the end-user or customers and the Scrum team, and serves as a nexus or conduit. A good product owner will have not only the pulse of his target customer, but also that of his Scrum team to deliver optimum value to the product/organization.