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.

Collocation – how Happily are we doing it?

The Agile Manifesto values ‘Individuals and interactions over processes and tools’. Great importance is given to open and frequent communication in any Agile methodology such as Scrum. And a very effective way to bring it about is collocation. Webster’s defines this as 'the act or result of placing or arranging together'. Team members are brought together and placed in physical proximity in a room or closed area to break down the proverbial walls and foster camaraderie resulting in much higher synergies. A lot of studies show that collocation does hike productivity. Kane Mar at Scrumology writes about this here and also mentions a detailed paper that measured how radical collocation helped increase productivity in a renowned automobile company.

Most of you have tried this and probably reached a steady state where you are at peace with where you sit, in how much space, next to whom etc. and can finally concentrate on your work. But we all remember what an uphill task it was. So imagine you are used to sitting in your own fair sized cubicle, you’ve got your stuff around you making you happy – the wife and kiddies smiling from a silver frame, glimpses of that Hawaiian vacation, the memorable Disney cruise, a nice bamboo or fern you gave a home to, coveted books for ready reference, snacks stashed away in that bottom drawer, maybe you even make your own coffee at your desk (yes) – you get the idea!! Then you are suddenly transported to a 12x15 ft room, with no windows (shudder), shared with 10-12 people and a bunch of whiteboards for walls. It’s a tough transition for anyone, and can rattle the best among us.

Some of the typical teething problems newly collocated teams face are –

-          Lack of personal space, sudden proximity to a lot of people

-          No ‘privacy’ and ‘under the radar’ all the time

-          Lots of discussions that may not be relevant to you leading to noise

-          Lots of chit chat and trivial chatter – enjoyable to some, others, not   so much

-          Put ‘on the spot’ several times a day, need to give constant and instantaneous input on any questions

-          Risk of infections, people picking noses, sneezing on you etc. ( sad but true)

-          People making personal calls incessantly etc. etc.

               

The list can be a mile long, but as your neighbor becomes more familiar to you, you don’t notice the clashing elbows so much. Your sprint reviews show you how much work you are getting done in a miraculously low amount of time, and you get so used to thinking out loud, extrapolating and constantly questioning everything that it becomes second nature.

As trust builds up, people come up with their grievances at retrospectives and eventually this leads to better and more spacious workspaces, common team rules, core hours, off hours etc. making you happier.

I have faced this trial by fire ( what else to call it?) myself several times and would like to share my experience and my two penny worth. Here are some small ways to ease the transition into collocation and minimize some of the resistance and problems people face –

• Food, food and more food!! Yes, lots of talk means lots of munchies coming on, and any customer that provides it is a hero. Here is a blog post that talks about it.

• Team events where people get to mingle – maybe a day out having fun, or Happy Hour or an evening at the bowling alley or movie night. This gives folks a chance to interact away from the office environment and connect at a personal level.

• Name your team – cheesy? Not really! Be it the Lakers or Man United or the Kings XI, each team has its own identity, values and reputation to live up to. This certainly fires up the troops and they are ready to take on any battle (backlog) that comes their way.

• Team Rules – some basic stuff like no cellphones during meetings, core hours, person missing the Scrum gets Donuts, work remotely when sick etc. – anything that makes sense to you as a group.

• Information radiators – loads of whiteboards, flipcharts, colored pins, markers, post its, index cards, colored dots to portray your backlog, your work in process, your work ‘done’, burndown charts etc. etc. Frequent looks at what you have achieved so far is a HUGE motivator.

• Fun stuff – who said you can’t have a bit of fun? Dart boards, mini baskets, stress busting gizmos, silly toys – anything that lightens the mood and makes you laugh.

• Headphones – a great way to tune out some of the ambient noise and focus on something. They can also indicate that you would like not to be disturbed for a while.

• ‘Do Not Disturb’ or Silent zones or enclaves close to your team space, for those times when you just need to be heads down and work on something by yourself.

• Windows!!! This may not be possible all the time, but they are really your window to the world, especially when you work in a wooded campus with tall trees, really tall trees, with leaves turning in the fall, and snow sticking to the bare branches in winter…ok, I digress, but anyone will agree, even a small window is better than no windows!

This list can go on and on too. This is what is my experience and what made sense to the several teams I worked with, and this definitely did not happen overnight. It took a lot of angst, tears, patience, retrospectives and last but not the least, Scrum Masters and Agile coaches who carried our voice over to the top, to the folks who dish out goodies like prime retail space.

And you will need to be bold too. You will need to speak up, bond and come together as a unit and decide what spells utopia to you! What’s going to make your workspace so warm and fuzzy that you will feel like the Energizer bunny?

So how are you handling collocation? Are you still running the rapids or in your happy place? Whether a Scrum Master or a team member, how are you dealing with resistance from your team and peers?

This post deals with collocation for teams that are mostly in the same location. How do distributed teams handle this? Thats another topic for another day.

How far can a Scrum Master go?

This does not refer to the career path of the Scrum Master. I mean, how far can a Scrum Master go without hitting an insurmountable wall, and what happens then?

The article ‘Role of the Manager’ by Pete Deemer on the goodagile.com website offers good insight into how the typical role of a manager, or role of a typical manager changes in Scrum. I have been fortunate enough to experience a lot of the scenarios given in this article. Managers who gracefully retract and step in only when asked to, and managers who just have to give their opinion on every story and every task and every task estimate. Some of this behavior trickles from the top. And in an organization that decides to buy-in into Agile, there is or should be clear communication across all levels about the management’s endorsement of Scrum. But doesn’t practice often turn out to be different from concept?

There surely comes a time when its critical to beat your competition, or go to market with a new feature, like yesterday! This may be a time when even executive management feels they would like to ‘bend’ Scrum a bit, and urge the pigs to cross the finishing line a bit faster?

What should the Scrum Master do in such a situation? Accept the trade-off even if it might mean derailing weeks or months of ‘scrummification’( surely there is no such word in the dictionary)? Take a stand, put his/her foot down and remind management about what they signed on for when they accepted Scrum? Or is it ok as long as the customer says its ok?

How idealistic can a Scrum Master really be? And how far can he go before he needs to bend or break?

Have YOU discovered JIRA yet? What about Greenhopper? Or Bonfire?

Do I sound excited? I am! I may be one of the last few on the face of this earth who had never encountered JIRA before. There is no suspense – for those archaic Clearquest and Quality Center lovers (I am one of them), JIRA is the new kid on the block. Yes, it’s been around since 2004, but that is still new! I know there is a plethora of tools out there, and for every tool I know, there are probably 10 tools I don’t know. Yup! There could be more tools being written right now, almost as we speak. So what is JIRA anyway?

JIRA is developed by this company. Wiki offers information here. It is an issue and project tracking tool that is used by more than 20,000 customers worldwide (website). JIRA offers 10 user licenses for 10$ with proceeds going to charity. JIRA has several plug-ins that offer various great things. Greenhopper is it’s plug-in for Agile project management, Bonfire for testing, Confluence for agile collaboration, Bamboo for continuous integration, Clover for code coverage and so on and so forth. A comprehensive list is available here.

I decided to try exploring JIRA to enhance my knowledge base some. You can try JIRA in 2-3 ways - download a version on your comp, or just login to their online Sandbox, or sign-up for a hosted trial. I decided to download the stuff. The installation was pretty easy and smooth – it installed/configured the web server as well as the database and got full marks from me. I remember painful attempts from several years ago where you needed to install and set up your own web server, licensing server and what not before downloading and using the tool. I had to create a login on the Altassian site and could generate a key easily. I decided to just browse around on my own before following any actual documentation or user guide.

Once you login as an Admin, you have projects, users, issues, plug-ins etc. as tabs. I started off creating a project. I then created some users and assigned them to various groups and added some roles for them. There is a way to assign or revoke permissions for various tasks to a particular group. Issues can be bugs, tasks, improvements or new features etc. Although some terminology is different, it is self explanatory. There are specific workflows or state transition diagrams available. You can either edit these or create your own. I tried to ‘Create an issue’ and it was pretty easy to do it. There are standard priority values like blocker, critical, major, minor etc. You can add your own or you can even change the name of these to suit your style. What’s not to like about so much flexibility?

When you login as a user, you come to your dashboard where you see issues assigned to you. This is configurable and you can setup what you see here. There are two other tabs on the top – Projects and Issues. You can search for issues using any filter, assign them, change the statuses etc. There are also several Reports available showing you information at a glance. Some of them are ‘average age report’, ‘user workload’, ‘worker workload’ etc. An activity feed/stream on the main page shows a trail of your recent activities. There is a lot of rich functionality here and much to explore and discover depending on your needs.

JIRA licenses are free for educational, non-profit and certain other types of users. Licensing costs are much lower than comparable popular tools. But the questions that I would ask as a prospective buyer are – what about complete test management, requirements traceability, scalability, performance, technical support etc.? Only YOU can decide what your specific needs are and whether JIRA meets them, and then the various trade-offs such as cost. But if you are looking for in-depth issue or defect management without too much upfront licensing or training cost, JIRA might be the answer!

I will follow up with more posts about plug-ins such as GreenHopper and Bonfire etc. in subsequent blog posts, making this part 1 of a series. So are you using JIRA for your projects? What has been your experience? Are you happy with its performance, or ready to chuck it out? I eagerly look forward to your feedback.

Daily stand-ups and the 15 minute challenge

The daily stand-up or daily Scrum is an essential feature of Scrum. It requires that everyone be present in person, or call in. It is a time boxed event which means it has a time limit and cannot exceed 15 minutes!

There are three essential questions every team member answers in the stand-up – what you did yesterday, what you plan to do today, and if you have any barriers or obstacles. The meeting takes place at the same time and same place every day to make it easy and ‘automatic’. Some teams do this at the beginning of the day, so that they have a roadmap ready for the rest of the day. Some teams prefer the evening when they have a good idea of what they achieved that day, and want to have an action plan ready for the next day. The time could also be determined by time limitations team members may have such as some people being in different time zones.

The Scrum Master acts as a facilitator here and makes sure that everyone sticks to the format. Any potential lengthy discussions are deferred for later. These kind of design discussions are generally held immediately after the Scrum. The SM also documents any new barriers on the board and has his/her work cut out. The Scrum Master may give his/her own update too explaining how s/he worked on particular barriers or concerns the team had.

One practice I have seen followed is that team members move the task cards during the stand-up. This is supposed to give a person a sense of accountability as they move a card from the ‘not started’ to the ‘in progress’ section. Similarly team members feel a sense of achievement when they move a card from ‘in process’ to ‘done’. Many coaches encourage this physical act instead of making updates in some online tool.

Distributed teams can prove to be a challenge for the daily Scrum. If there are only 2-3 persons in a closer time zone, they generally call in. If there is a large team (5+) in a far-off time zone such as another continent, they can have their own Scrum locally, and email updates to the Product Owner and the rest of the team.

The daily stand-up ensures that the team ‘inspects and adapts’ on a regular basis. Everyone is aware of the general updates and what is happening on the team, and how their progress or lack of it may be affecting others or causing impediments in others’ work. E.g delay in coding a certain feature may be blocking the testing story.

The information gained in the daily stand-up exposes potential and current issues and empowers the team to adapt themselves to complete the Sprint goal.

The QA story – and how best to portray it on your sprint backlog

Quality assurance and/or quality control is an integral part of the software development process. It ensures you conform to your requirements, meaning that you are delivering what your customer wants, and isn’t that what we are all striving toward in a nutshell?

Agile advocates test driven development or TDD, and many Agile or Scrum teams use it. But that’s a big topic on its own. I want to focus this post on how you portray testing or QA on your sprint backlog, whether it’s a TDD type activity, or manual testing or automation testing or any aspect of the testing lifecycle be it planning, design, execution, defect tracking, process improvement etc. These are tasks that you would typically have even on an Agile/Scrum team if you follow a modicum test management process. These need to be done for each story on your sprint backlog. E.g if your story is about creating a way to login to your system, or adding an item to a shopping cart, you still want to write high level and detailed testcases for each requirement pertaining to this story, then have a task for executing these testcases, have a task for defect logging if necessary etc. You will probably need tasks for setting up any initial conditions such as test environment or specific data setup. You will need tasks for obtaining approvals for your testcases, or following up on defects etc. You also might need tasks for other admin type activities such as setting up your test tools, assigning appropriate roles to team members, ensuring that your developers are set up right in the defect management systems so that you can assign your open bugs to them etc. etc. etc. The list is endless and you may do some or all of these depending on your organization, your team and the minimum artifacts you need to produce from an audit or compliance standpoint. I have not even touched on tasks relating to regression, integration etc.

Lets pause a second to take a deep breath. Does this seem like a lot of work? QA or testing almost always is. It takes a lot of due diligence to ensure sufficient test coverage and it’s the last step before you release your baby into the big bad world. So how do you portray all this on a sprint backlog? Create cards for each and every small thing, or just clump some things under a ‘miscellaneous’ heading?

This is what my experience has been. As you work on successive sprints, you start realizing the myriad small tasks or things that need to be done to reach the point of say, executing a testcase, and you gradually start creating separate tasks for them. This may appear to be overkill initially but it has its advantages. You increase visibility into what you do, and make the entire team aware of the nuances of a typical QA function. You make it easier for your team to understand your estimates – it is easier for everyone to follow several tasks that are 2-4 hours than having one number such as 20 hours or 40 hours that most will think you pulled out of your hat. This also builds greater understanding in everyone’s mind about the impact any changes to requirements or code will have on QA. So you get it – the advantages are manifold.

Getting down a bit further to brass tacks, I have generally had specific tasks such as designing and documenting testcases, executing them, adding defects as part of specific stories, and then I have a separate story I call the ‘QA story’. All my administrative tasks go here e.g. resource onboarding, tool setup, work requests, status calls, mentoring, knowledge transfers etc. etc.

One big advantage of this is that I already know what most of the tasks are going to be each sprint, and it makes it easier all around during part two of the sprint planning meeting. Each tester can focus on the stories they are going to work on, with only one or two ‘new’ tasks they may need for a specific story. This saves time being an almost repeatable process. Of course, it has taken me time and several different projects to come up with this.

What do you think of this post? How do you portray your QA tasks on your sprint backlog? Do you have different tasks each sprint, or do you feel that you are doing similar things for each story? I would love to know your views and experiences.

Planning Poker for Agile estimation – Thou shalt not be inscrutable!

You don’t need a poker face to win this one. In fact, you need just the opposite. But hold on, let us start this properly.

Software estimation can be your worst nightmare, and no matter how many fancy statistical models you use, you may still end up not being totally accurate. Agile offers a unique method for estimating your user stories – planning poker. Yes, it uses cards, and yes, it is sort of a gamble like the game, and yes, it is FUN. And yet, you end up with pretty good estimates for your user stories, and hence your sprint or iteration. And you get to play this every other week, or every month, depending on your sprint length.

Wikipedia provides some good background on planning poker here. So does Mountain Goat software and http://www.planningpoker.com/. There is an oldish post  here which has several good comments that offer differing points of view and experiences. Ken Schwaber also wrote of this recently.

Ok, so now that we have enough links and sources to read around this, I would like to paraphrase the game simply. Planning poker is ‘played’ by the Scrum team or the developers to come up with grounded estimates for each story. Actual cards are/can be used. These cards have numbers such as 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ? etc. printed on them. This is how the process goes -

• A moderator is appointed by the group. The moderator reads out the story, the product owner elaborates a bit and then everyone thinks about it for a minute or two. A sand clock or kitchen timer may be used.
• At the call of ‘Show’, everyone turns their selected card up. It is important that everyone be quiet until this moment to avoid creating a bias.
• The person with the highest and lowest card explains why they came up with that particular number. This is not to convince anyone; they justify their choice and that’s all.
• The process is repeated where the group thinks for the minute or two and selects a card again. Everyone ‘shows’ and the high and low estimator again explains their choice.
• The card selection process is repeated until the team reaches consensus on a number and that is allotted as the effort estimate for that particular story.

The higher numbers on the cards are more widely spaced to denote the uncertainty that follows large estimates/tasks. These numbers resemble a modified Fibonacci sequence. Distributed teams can use an online tool that is available at http://www.planningpoker.com/.

Planning Poker works because it takes estimates from the actual performers themselves, and encourages dialogue and hence forces people in diverse roles to think about dependencies. There is also some literature on how averaging individual estimates gives better  results. Also, you have actual performers from different functional areas coming up with their numbers as opposed to one higher-up manager( however experienced) assigning a number for the whole project.

What method do you use to estimate your projects - agile or otherwise? Have you tried planning poker yet? Do you think estimating at the story or requirement level by actual performers will give a more grounded estimate?

Sprint plus one – is it the answer to your test automation woes?

Regression testing is an essential function in software quality assurance whether you are working on a path breaking new product, or some age old legacy system. It’s the only way to ensure that your enhancements, bug fixes or new features have not broken any existing code, and to avoid those 2 AM fire alarms (God forbid), when your yearlong project crashes the moment it meets a production environment. Depending on your organization size, culture, budget etc., you probably have a dedicated team that automates the testcases you marked for regression, and there is an automation suite that is diligently run before any production rollout. Whether it is current and has full coverage is a topic for another day.

So traditionally we have been used to this concept of automation very late in the cycle, generally after a battery of other tests have been run and your AUT( application under test) has withstood them. With Agile methodologies, it’s a whole different ballgame. Agile advocates short sprints or iterations, and each of these iterations have to produce a potentially shippable piece of functionality. It means that your features are coded and tested in every possible way. As this functionality builds up every subsequent iteration, you test more and more because you are integrating everything that came before and also testing it. Doing all this manually is a herculean task, and your friendly Agile coach, always around to lend you a helping hand, has urged you to use test automation. But this may not really be feasible.

In Agile projects, the codebase can and does change pretty rapidly from day to day if not from hour to hour. It means you could have a lot of bugs and are almost always rewriting or updating your testcases. It could also mean an application that is not very stable, and automating something that changes every day may not really seem to be a value add. Yet it is as formidable a task to manually test more and more functionality every subsequent Sprint. The ‘Sprint+1’ approach is the answer, according to this white paper on HP.com.

Agile automation: A primer on test automation in Agile projects (http://h20195.www2.hp.com/v2/GetPDF.aspx/c02879554.pdf) suggests that test automation should lag behind, but not more than for one iteration. So we assume that ‘story 1’ is completely coded and tested etc. in Sprint 1, and is automated in Sprint 2. The assumption here is that ‘story 1’ is stable at the end of ‘Sprint 1’. Some of the salient points and/or questions that I can think of based on agile projects I worked on are –

1)  Even if a certain story is ‘done’ at the end of one iteration, it could always have changes and reappear as a new story, hence requiring more work on it and rework as regards test automation.

2)  Test automation should certainly be a separate item on the product/sprint backlog. This will force all stakeholders to recognize and acknowledge that test automation is a necessary part of the project and requires a chunk of time and resources. It will add visibility in terms of estimates and burndown.

3)  Team members can concentrate on manually testing unstable portions and automating stable functionality. A different person could be doing each of these and either can give full attention to the task at hand, since the actual tasks or sub-tasks for achieving either will be different.

4)  Test automation can or should be a story in each iteration with specific task cards for each particular feature, story etc. that is to be automated.

I can go on, but I suppose you get the point. Every Agile team will be facing slightly different circumstances in terms of their company culture, product, technology, people etc. And each of you will need to come up with something that best fits your situation, try it for one sprint/iteration at a time, and keep improving on it based on your retrospectives.

So how are you handling test automation on your Agile project? Do you have a 100% automated regression suite? Do you think you are saving time using test automation? Or are you still happy using manual means for regression? I am eager to know what you think.

How hard is Scrum?

I know this is a loaded question that almost everyone who has ever worked on an Agile team will scramble to answer. Maybe this has come up in some of your retrospectives, about how the team found certain aspects tough to deal with or follow. But I am not talking about your feelings here. This is about Scrum itself, and its personification as it assumes quite an imposing personality. I came across this while reading this article at http://www.controlchaos.com/my-articles.

The author tells us how the scientific approach has taught us to make a hypothesis, test it and then apply it. This is also called the Newtonian or deterministic approach. But this makes less sense as the complexity increases, and the process becomes more empirical than defined.

Scrum is empirical because it embraces change, and evolves with it. Scrum makes things possible, but Scrum does not promise to make them predictable. Scrum is hard because it goes against the basic human nature of trying to simplify everything. As people achieve success with Scrum, they will set higher goals making it more complex to achieve them.

Yes, Scrum is hard. And I also think arts, humanities and basic sciences are underrated in India. If engineering is the topmost trade and the epitome of a fine education, how come no one ever taught me what a Newtonian approach was? :)

Embracing Change

Hello readers! I would like to welcome you all to this blog, and encourage you to follow this regularly in the days to come. With a name like 'Waltzing to change', its only befitting that my first post should be something about 'change'. So here goes...

Change is the only constant in our lives. We have all heard it many times. This change could come in the form of unexpected life events, changes at work, culture changes, changes in the world around us etc. etc. Yet when it happens, we find ourselves struggling to come to terms with it. 

Alvin Toffler talked about responding to change in his first book ‘Future Shock’ (1970). He later wrote two other books –Third Wave and Power Shift. Third Wave suggested that the 21^st century would be the information age and according to my old English professor, belong to the service industry. How true that has turned out to be! When I read this book several years ago, it seemed more of a chore as a reading assignment, but over the years I have often thought back to passages from this book, especially when I adjusted to the whole culture change of living in a new country.

I think that India has been facing a lot of the culture shock mentioned in Future Shock for the last decade, and will continue to do so as we face technological and social change at a staggering rate. There is rapid urbanization and movement from rural areas to big cities. People and families are facing a generation’s worth of growth overnight, and are ill equipped to handle all the sudden prosperity. Isn’t this a kind of change too?

Future Shock was written a long time ago, but it feels like we are actually living through what he predicted over three decades ago. That is an indescribable feeling. The only way to deal with change then, is to expect the unexpected, embrace change and be like the Borg – assimilate everything new you encounter, because as we well know, ‘Resistance is futile’ !! (Sic)

One software methodology that thrives on change is Agile. ‘Inspect and adapt’ is a tenet of this methodology which encourages quick responses to change, and empowers teams to take unexpected events and occurrences in their stride and come out winners.

For those of you who would like to read this revered tome, you can get it here on Amazon. Or maybe find a much thumbed copy in your public library or local thrift store!