ALMComplete

Taking the hassle out of scheduling Automated Test Runs

2010-12-16T10:45:00.009-07:00

Let's imagine you have a team of hot-shot QA gurus and they've taken the time to automate your test cases using TestComplete. Now let's imagine you want to take it to the next level, scheduling those automated tests to run at a particular time or a particular date. For example, let's imagine you want to schedule them to run automatically every week night at a 7 p.m so that you can check the run results when you get into the office first thing each day.

If you've had this need in the past, you probably created a batch job that launched TestComplete, sending it the Project Suite and Project you want to run. Then you had to create a Windows Scheduled Task to run that batch job at a particular date and time. This works fine, but what happens if you had set it up to run Monday, Wednesday and Friday, leave work on Tuesday and decide it would be great to have it run tonight because there were a lot of code committed today and you would like a retest. Unless you have a VPN connection to your office, you have to jump in the car and drive back to work.

If you've had this issue, you're gonna love this. This weekend (19-Dec-2010), we are implementing a new feature of Software Planner (QAComplete and ALMComplete editions) that allows you to schedule automated test runs via the web. Even cooler, you can see the run history in dashboards so that you can quickly see what things passed and failed. Since this is all web driven, you can do this from the luxury of your home without going into the office.

To illustrate how this works, we created a movie, you can watch it here: http://www.softwareplanner.com/movies.asp?Topic=AutomationScheduler.

For quick reference, here is what the scheduling screen looks like:

As automated tests run, they get posted to a dashboard that you can use to see what items pass and fail each day:

So take the hassles out of life -- explore the new Automated Test Scheduler. Oh, and by the way, it can also schedule HP QuickTestPro automated tests as well! Enjoy.

Uncluttering your tasks using Task Boards

2010-12-10T15:07:00.004-07:00

Most of us understand the complexity of software development. There are lots of moving parts, requirements to hash out, coding and testing to get done. With tons of tasks in a project, it can easily get overwhelming trying to figure out the status of what's on our plate and what things we've already completed.

Many Agile and iterative Waterfall teams have simplified this process by using Task Boards. If you've never used a Task Board, simplicity is what makes it interesting. A Task Board is simply a list of all the tasks a developer has to work on. It is normally divided into 3 columns:

1. To Do - List of things I've not started
2. In Progress -Things I am currently working on
3. Completed - Stuff I've completed

To utilize this, most teams simply use a whiteboard with sticky notes to identify these tasks, here is an example:

So as we begin working on things, we simply move the sticky notes to In Progress. Once we complete them, we move them to the Completed area. As new tasks come in, they go into the To Do column. By having this front and center for the team to see, we all know the status of our tasks.

After working with this a while, we thought it would be cool to have our Application Lifecycle Management (ALM) (http://www.softwareplanner.com) tool display Task Boards. So I asked my team to come up with a simple yet effective way of showing this online. They came up with a cool design. As a developer, you can access your Task Board and see all your tasks, just as you can by using a whiteboard. However, they took it a step further. For each task, they show:

1. What requirement it is related to
2. How many hours have been worked thus far
3. How many hours are left (and pct complete)
4. The critical dates (estimated start and finish dates)

They even extended it by showing any tasks that are due today in green and tasks that are overdue in red. That allows you to quickly spot the ones that might be slipping. This new feature is slated to go to production in ALMComplete (http://www.softwareplanner.com) sometime this month (December 2010). Here is a quick preview of what it looks like and here is a quick movie that shows how it works:

http://www.softwareplanner.com/movies.asp?Topic=TaskBoards

What do you think?

Using Retrospectives to Improve Future Testing Efforts

2010-10-12T16:52:00.001-06:00

This month's newsletter is delivered as an On-Demand webinar. It is the last in the 5 part series entitled "Uniting your Automated and Manual Test Efforts" and focuses on using retrospectives to improve future testing efforts.

Click here: http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?Filename=UnitingPart05) to begin the presentation. You will learn:

1. What a retrospective is and how it can help your team improve
2. How to conduct a retrospective
3. How to improve future releases by applying what you learn in retrospectives

Software Planner New Release - version 9.4.2

2010-09-24T10:37:00.002-06:00

We just issued a new release of Software Planner to production (Release 9.4.2) and it has several new features:

JIRA Integration – Allows synching of JIRA issues with Software Planner defects. Issues can originate or be updated in either system and will be synced.
Movie: http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?filename=SPJIRAIntegration
User’s Guide: http://www.softwareplanner.com/UsersGuide_swpSyncJIRA.pdf
HP Quick Test Pro (QTP) Integration – Allows automation engineers to run QTP scripts and have the run results appear in Software Planner lists and dashboards.
Movie: http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?filename=SPQTPIntegration_Overview
User’s Guide: http://www.softwareplanner.com/UsersGuide_QTP.pdf
Subversion Integration – Allows automation teams to associate subversion source code with Software Planner requirements, test cases and/or defects.
Movie: http://www.softwareplanner.com/GuidedTours/EdgeUI/Camtasia.asp?FileName=SVNIntegration
User’s Guide: http://www.softwareplanner.com/UsersGuide_SVN.pdf
Microsoft Project Integration – Allows importing and exporting projects from Software Planner to/from Microsoft Project.
Movie: http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?filename=ImportMSProject
Record Locking Feature – Automatically detects if others are editing a record to prevent data collisions.
Movie: http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?filename=RecordLocking

Optimizing your Test Efforts during the QA cycle

2010-09-08T15:42:00.002-06:00

This month's newsletter is the 4th in a 5 part series entitled "Uniting your Automated and Manual Test Efforts". This month we focus on optimizing your Test Efforts during the QA cycle. The topic addressed are:

How to determine how your QA cycle is progressing
How to determine your defect resolution rate
How to use metrics to determine the stability and production readiness of your software release.

You can see the newsletter at: http://www.softwareplanner.com/newsletters/newsletter_2010_09_sp.htm

Uniting your Automated and Manual Testing

2010-08-09T16:19:00.003-06:00

This month's blog is delivered as an on-demand webinar. It is the 3rd in a 5 part series and focuses on how to unite your automated tests with your manual test effort. To view the webinar:
http://www.softwareplanner.com/guidedtours/edgeui/camtasia.asp?filename=UnitingPart03

Pragmatic Software is Now SmartBear Software

2010-07-19T09:08:00.004-06:00

Pragmatic Software is Now SmartBear Software

You may have heard of the other sister company, the original Smart Bear Software, the peer code review company that created CodeCollaborator. The new SmartBear now includes the old Smart Bear and of course AutomatedQA, which is well known for its TestComplete automated testing and AQtime performance profiling tools. (You may also know that TestComplete works exceptionally well with SoftwarePlanner for test case management).

How will this benefit our users?

For one, our community of users has grown to more than 75,000 software developers and testers with the formation of the new company. We look forward to helping you take advantage of this much larger SmartBear community for expert advice, more support, knowledge sharing and of course improved software quality. Keep an eye out as we start to share tips and tricks, white papers, and other best practices that we hope will help you produce better software.

The combined company is also much better equipped to push product development forward. We are already working on a bunch of new ideas that will not only make it easier for our products to work together, but also put great new functionality in the hands of our users. Stay tuned – you will hear much more from us about automated testing, test management, code review, performance profiling, and development management.

Why did we change our name?

As AutomatedQA, Smart Bear Software and Pragmatic Software worked together to become one company, we had to select a name that we felt reflected our brand values: to be community-focused and offer innovative tools that are highly functional and at the same time actually affordable. Also, now that we have tools that support the immediate needs of both, developers and testers, we needed a name that wasn’t tied to one particular type of product. So we and our sister companies chose the name of one of our very successful existing brands to represent us all going forward. We also think the name is a lot more fun and interesting than using two or three letter acronyms. We hope you like our decision!

Here’s the new logo:

What do you think? Just a few minor adjustments of the original Smart Bear logo, which we thought was pretty cool to begin with as well.

Visit our existing Community page to learn how you can follow us and communicate and share with one another as we continue to add to our products, enhance our web site, and grow our community involvement.

If you want more details regarding the announcement, click here, and stay tuned for some exciting product news in the days and weeks ahead.

Are you curious about all the other tools that are now part of the SmartBear family? Ever needed to increase your test coverage or find those annoying performance issues or memory leaks? Or even find issues before they become bugs through fast and pain-free code review?

Tell your friends, give them a try and check out any of our tools for free:

TestComplete automated testing tool
AQtime performance profiling tool
CodeCollaborator peer code review tool
SoftwarePlanner development and test management tool

What’s your take on the New SmartBear? Let us know, leave us a comment, Tweet us or drop us a line.

Best Practices for Planning your Manual Test Effort

2010-07-02T14:32:00.000-06:00

This month's newsletter is delivered as an On-Demand webinar. It is the 2nd in a 5 part series entitled "Uniting your Automated and Manual Test Efforts" and focuses on best practices for planning your manual test effort.

Best Practices for Planning your Manual Test Effort

Click on the URL: http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?filename=UnitingPart02 to begin the presentation. You will learn:

1. How to improve the effectiveness of your requirements definition
2. Best practices for creating manual test cases for each requirement
3. How to ensure you have good test coverage for traceability for each requirement
4. How to best organize your manual tests

Best Practices for Planning your Automated Test Effort

2010-06-04T16:39:00.001-06:00

This month's newsletter is delivered as an On-Demand webinar. It is the 1st in a 5 part series entitled "Uniting your Automated and Manual Test Efforts" and focuses on best practices for planning your automated test effort.

Best Practices for Planning your Automated Test Effort
Click on this link (http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?filename=UnitingPart01) to begin the presentation. You will learn:

1. How to identify what test cases should be automated
2. How to best organize your automated test cases
3. How to version and protect your automated test cases
4. How to schedule your automated test cases to run periodically

5 Benefits of Daily Builds

2010-05-14T10:20:00.001-06:00

This month's newsletter describes the major benefits of doing daily builds and how it can improve your software quality. A daily build is the process of compiling your software daily so that tests can be run against it to identify any major coding issues introduced since the last build. Daily builds have become common place with Agile development, but it is not limited to just Agile teams. Teams practicing Waterfall development can also get enormous benefit from this approach.

To see the full article, click here: http://www.softwareplanner.com/newsletters/Newsletter_2010_05_SP.htm

Uniting your Automated and Manual Test Efforts

2010-04-20T08:43:00.001-06:00

This month's newsletter describes how to determine what test cases are best for automation and how to plan new releases with a mix of both automated and manual tests.

To see the full article, click here:
http://www.softwareplanner.com/Newsletters/newsletter_2010_04_SP.htm

8 Best Practices for Managing Software Releases

2010-04-20T08:38:00.002-06:00

Many software releases extend longer than expected and while sometimes project slippage is unavoidable, there are some clear cut best practice fundamentals that you can employ to reduce the chance of slippage.

See the full article here: http://www.softwareplanner.com/Newsletters/newsletter_2010_03_SP.htm.

Powerful Metrics for Developers

2010-02-11T08:51:00.005-07:00

Insanity is defined as "doing the same things over and over and expecting a different result". As a developer, it is easy to get into a rut of doing the same thing over and over again but never really improving your development process or identifying things that can aid in bringing real success to your job. To improve, we need to understand our goals and measure our progress towards them. This article discusses how to develop metrics that aid you in achieving specific goals.

What are Powerful Metrics?
Metrics are simply a way to measure specific things you are doing, but you could create hundreds of irrelevant metrics that really don't move you any closer to solving your everyday problems. Powerful metrics are a small set of indicators that are targeted to help you accomplish a specific set of goals.

Metrics Driven by Specific Goals
Before defining your metrics, ask yourself "What goal(s) am I trying to accomplish?", then write your goals down. For example, typical goals for a developer might be to:

Improve my estimating skills
Reduce defect re-work
Ensure that my code is tight and re-usable

Now that we have our goals defined, let's figure out how we can create a set of metrics to help us accomplish them.

“Improve my estimating skills"
To do this, you first need to record the actual time you work on assigned tasks as compared to the original estimates. The difference between the estimate and actual is the "variance". At the end of a project, determine your overall variances to determine how well you track against estimated hours. If you find that your variances are over 10%, consider buffering your estimates on the next project by the variance amount. For example, take the example below:

In the example above, buffering your estimates allow you to become a better estimator. After tracking this for a few releases and buffering your estimates, you will begin providing more accurate estimates. If your team is using Software Planner, you can run variance reports that automatically calculate the information above, below is an example report:

“Reduce defect re-work”
Software releases often take much longer than needed because defects are not resolved on the first round and it adds time to the release timeline when developers have to fix the same issue multiple times and testers have to regress those changes over and over again. Many times defects are re-worked 5 or more times before they are correctly fixed.

To resolve this issue, you must first have an appreciation for how often this is happening. One strategy for this is to add a field to your defect tracking solution that indicates that a defect is being re-worked. If your defect tracking solution has auditing capabilities, it should be easy to produce a report or dashboard that counts the number of times defects are re-worked. Below is a dashboard generated from Software Planner that shows defect re-work:

By knowing this, you can work on reducing re-work by employing these techniques:

Better steps-to-reproduce - Many times re-work happens because the tester has not provided enough steps to reproduce the issue consistently. Work with your QA team on providing really great reproducible steps. Even better, have them record the steps into a movie that show how to reproduce the issue. This can quickly be done by using Jing (http://www.jingproject.com/), a free utility that allows you to record an issue and it creates a link so that the developer can see it in action.
Better Unit Testing - Sometimes developers rush through the development and do not fully test it before sending it back to QA. This takes discipline, but if you take the time to fully test it before sending it back to your QA team, it will save you time in the long run.
Peer Code Review - Another set of eyes on your code can help you reduce re-work. Consider asking a peer to review your code before compiling it and sending it to your QA team. You can speed up code reviews by using tools like Code Collaborator.

“Ensure that my code is tight and reusable”
To do this, you must do peer code reviews. By having others inspect your code, you will begin to write tighter and more reusable code. To measure the effectiveness of this, measure the number of defects found during code review versus defects found during quality assurance. This will quickly identify how code review leads to a reduction in defects found during QA, which is more costly to fix than during development. Keep track of code reviews and defect statistics, below is an example:

You can speed up code reviews by using tools like Code Collaborator.

Summary
Dedicate yourself to improving your job by identifying your goals and tracking metrics that help you determine how you are trending towards your goals. The metrics listed above work fine for my team but I would like to hear what metrics you find are helpful in your organization. To communicate that to me, please fill out this survey.
If we get great feedback from this, we will publish the results in our next month's article so that we can all learn from each other.

Sign Up Today
Start improving your project efficiency and success by signing up for our monthly newsletters today.

Want a FREE BOOK of code review tips from Smart Bear Software?
You may not realize it, but Software Planner has a sister - it's Smart Bear Software. Both companies are owned by AutomatedQA and our teams relish helping developers deliver software reliably and with high quality. Smart Bear’s Code Collaborator tool helps development teams review code from anywhere, without the usual grunt-work and pain that often accompany peer code review.

Bugs cost 8-12 times less to fix if found in development rather than QA (and 30-100 times less if found in development rather than after release). And of course bugs found in development mean less time spent chasing them down for QA folks! Smart Bear believes so strongly in code review that they will send you a free book of code review tips. They conducted the world’s largest case study of peer code review with Cisco Systems, spanning 2500 code reviews, and the book presents these findings along with other peer review best practices.

If you know anyone who might be interested, please pass this information on to them -they can visit http://www.codereviewbook.com/?SWPnews to request a copy of their own!

Helpful Software Testing Tools and Templates
Below are some helpful software testing resources and templates to aid you in developing software solutions:

Powerful Metrics for Testers

2010-01-07T10:23:00.023-07:00

Insanity is defined as "doing the same things over and over and expecting a different result". As a tester, it is easy to get into a rut of doing the same thing over and over again but never really improving your test process or identifying things that can aid in bringing real success to your job. To improve, we need to understand our goals and measure our progress towards them. This article discusses how to develop metrics that aid you in achieving
specific goals.

What are Powerful Metrics?

Metrics are simply a way to measure specific things you are doing, but you could create hundreds of irrelevant metrics that really don't move you any closer to solving your everyday problems. Powerful metrics are a small set of indicators that are targeted to help you accomplish a specific set of goals.

Metrics Driven by Specific Goals

Before defining your metrics, ask yourself "What goal(s) am I trying to accomplish?", then write your goals down. For example, typical goals for a tester might be to:

Ensure that each new feature in the release is fully tested
Ensure that our release date is realistic
Ensure that existing features don't break with the new release

Now that we have our goals defined, let's figure out how we can create a set of metrics to help us accomplish them.

"Ensure that each new feature in the release is fully tested"
To do this, we must have assurance that we have enough positive and negative test cases to fully test each new feature. This can be done by creating a traceability matrix that counts the number of test cases, number of positive test cases and number of negative test cases for each requirement:

Requirement	# Test Cases	# Positive	# Negative	Comments
Visual Studio Integration	104	64	40	Good Coverage
Perforce Integration	0	0	0	No Coverage
Enhanced Contact Management Reporting	45	45	0	No Negative Test Case Coverage
Contact Management Pipeline Graph	10	8	2	Too few test cases

“Ensure that our release date is realistic”
To do this, we must have daily running totals that show us test progress (how many test cases have been run, how many has failed, how many has passed, how many are blocked). By trending this out, day-by-day, we can determine if we are progressing towards the release date.

Software Planner provides graphs that make this easy:

Another way to do it is to create a Burn down chart that spans the testing days. On the chart, it will decrement each day by the number of outstanding test cases still to be run (awaiting run, failed or blocked) and we can compare those totals to the daily expected number to determine if the release date is realistic. Let's assume we have a 2 week QA cycle, we can define the number of test cases to run and daily we can keep track of how many are still left to complete versus how many should be left to complete.

In the example above, we can see that we are not getting through the test cases quickly enough. On day 5, we are behind schedule by 15 test cases and we can see this clearly on the Burn down graph -- the red area (actual test cases left) is taller than the blue area (expected test cases left).

“Ensure that existing features don’t break with the new release”
To do this, we must run regression tests (could be manual or automated) that tests the old functionality. Note: This assumes we have enough test cases to fully test the old functionality, if we don’t have enough coverage here, we have to create additional test cases. With regression tests, you can normally stick to “positive test cases” with this group, unless you know of specific "negative test cases" that would be helpful to prevent common issues once in production.

To ensure you have enough of these test cases, it is a good idea to group the number of regression test cases by functional area. Let's assume we were developing a Contact Management system and we wanted to be sure we had regression test cases assigned to each functional area of that system:

Functional Area	# Test Cases	Comments
Contact Management Maintenance	25	Good Coverage
Contact Management Reporting	0	No Coverage
Contact Management Import Process	10	Good Coverage
Contact Management Export Process	5	Coverage may be too light

To determine if release dates are reasonable for your regression testing effort, use the same Burn down approach illustrated above.

Summary

As the new year begins, dedicate yourself to improving your job by identifying your goals and tracking metrics that help you determine how you are trending towards your goals. The metrics listed above work fine for my team but I would like to hear what metrics you find are helpful in your organization. To communicate that to me, please fill out this survey:
http://www.surveymonkey.com/s/DW656JZ.

If we get great feedback from this, we will publish the results in our next month's article so that we can all learn from each other.

Peer Code Review: An Agile Process

2009-12-22T10:31:00.007-07:00

This month's newsletter discusses how peer code review can be used by Agile teams to drive better software quality. The article was written by Gregg Sporar of Smart Bear Software and published in the proceedings of the Agile Development Practices conference in November 2009, Gregg has kindly given us permission to share it with you. We hope you have a great holiday and enjoy Gregg's article.

Is Peer Code Review Agile?
Peer code review is one of the most effective ways to improve software quality – but is it agile? Done correctly, it absolutely is. The Agile Manifesto[1] states:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Research has consistently shown that code review produces software with fewer defects, which aligns with the emphasis on working software. And what could be more interactive than two or more software developers talking (or instant messaging or emailing) about the code and making real-time improvements?

Yet many agile practitioners consider peer code review to be part of the “bad old world” of waterfall development and reject its inclusion in agile projects. This newsletter shows how code reviews can be conducted using methods that align perfectly with the fundamental principles of agile development.

Moving Beyond the “Code Review Stigma”
Historically, the process for conducting code review was pretty “anti-agile.” As originally conceived by Michael Fagan in 1976, code inspections[4] were a heavyweight code review process that led to an entire generation of software developers who believed meetings were necessary in order to review code.

Heavyweight processes and meetings are not regarded favorably on agile projects, and that stigma has tainted the concept of code review. This “guilt by association” has worn away over time, but misconceptions still linger.

The biggest misconception is that meetings are required to do code review. Fagan stated that meetings are required, as have other researchers. But Lawrence Votta of AT&T Bell Labs was not convinced. His study[6] showed that if developers read the code before the meeting in order to find defects, actually having a meeting will only increase the total defects found by 4% (while often tying up several hours of valuable time per participant).

Recent studies have confirmed that code review can be effective without meetings. Jason Cohen, founder of Smart Bear Software®, conducted a study[3] at Cisco Systems® that showed that a lightweight peer code review approach was as effective as a heavyweight code inspection process, but more time-efficient by a factor of 7x.

Yet even agile devotees who recognize that meetings are not required have misconceptions about code review: “We only use the latest techniques here – code review is from the past and provides no value,” or “All the unit tests pass, so why do we need to do code reviews?” If you take away the meetings and the heavyweight process, but leave the interaction, responsiveness, and dedication to continuous improvement, then code review is very much an agile practice.

How Does Code Review Align With Agile?
Delving into the underlying principles[2] of the Agile Manifesto provides specific evidence that code review is agile:

Working software is the primary measure of progress. Software developers are fallible, just like all other humans. We make mistakes. Some of those mistakes can be detected automatically (unit tests, static analysis tools, etc.) but just as professional writers have human editors in addition to spell-check software, software developers benefit from having one or more other developers examine their source code. It is interesting how much time we spend during an iteration discussing the requirements with our stakeholder(s) and the emerging design and architecture with other software developers, but when it comes time to actually write the code the tendency is for each developer to work in isolation. The interaction during discussions of requirements, architecture, and design uncovers flaws. The same principle applies to the writing of the code. Code reviews uncover flaws and have another key benefit that is prized by agilists – the feedback is kept close to the point of creation and happens sooner – before the code gets to QA or customers.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. That’s a tall order. To help meet it, agile teams frequently practice collective code ownership. The goal is that each portion of the source code is understood by more than one member of the team. To reach that goal, it is important to pay attention to the bus number for each part of the code – how many team members would have to get struck by a bus before no one was left that understood the code? If the bus number for a section of the code is less than two, then that’s a problem. By encouraging the reading and discussing of the source, code review helps maintain collective code ownership, increasing the bus number for the reviewed code. That way, if a team member is on vacation, or leaves the team, progress can continue at the same pace.

Continuous attention to technical excellence and good design enhances agility. All software developers have egos and most of them are naturally curious people who enjoy learning new things. Developers who know that their code will be reviewed tend to write better code because they know that their reputation is on the line. No one wants to be thought of as the weak link in the chain. A corollary is that developers who review other’s code get an opportunity to learn new tricks and techniques. A key step in mastering any craft is to benefit from the experience of others.

Types of Lightweight Code Review
Lightweight code review provides the right mix of code review process with agile practice, allowing effective and efficient code reviews without overwhelming burden. There are four different approaches to doing lightweight code review in an agile environment. Each has its strengths and weaknesses and they are not mutually exclusive, so there is no single right or wrong approach. As with so much in the agile world, each team needs to decide for itself which approach is correct.

Over the shoulder. This is the easiest technique of all: when it is time for a code review, find a developer and sit down with him or her in front of the code. Face to face communication is an easy, high-bandwidth medium for the author’s explanation of the code. An obvious drawback is that not all teams have all members in one location. An additional issue is that the reviewer is being interrupted – after the review it will take time for that developer to get back to the same level of productivity. The biggest risk with this sort of approach, though, is that it can end up being a walk through instead of a review. If the reviewer has no prior access to the materials then typically the author does most of the talking, which can result in a passive reviewer who spends more time nodding than asking questions about the code.
Email pass-around. When the code is ready, send it out over email. One of the advantages of this approach is that reviewers and authors can be in different locations. Another advantage is that the reviewers can do the review at their convenience. One obvious downside is that as the review proceeds and the emails get nested in multiple replies, it becomes more difficult to follow the conversation. And if files are reworked and line numbers change, it can be challenging to determine which version of a file – or even which line – is being referenced by a particular comment. But perhaps the biggest drawback is that it can be difficult to answer a simple question: When is the review finished?
Pair programming. One of the Extreme Programming world’s key contributions has been pair programming, which in some ways is a continuous code review. The advantages are that no workflow or tools or interruptions get in the way. Further, the review is at a deep level since the developer who is reviewing has the same level of experience with the code. One obvious downside is that the time commitment is non-trivial. A less obvious downside is that the reviewer is “too close” to the code to give it a good review. After all, a key benefit of code review is to get outside opinions. If two developers are pairing to the extent that they have the exact same view of the code then the code review will likely not be as effective.
Tool-assisted review. Code review tools exist to help overcome the shortcomings of the approaches listed above. They can package up source files, send notifications to reviewers, facilitate communication, ensure defects are fixed, and more. The obvious downside is that they require at the very least time for installation and configuration, and in the case of commercial products, money for license purchases. A popular tool for peer code review is Code Collaborator (http://www.codecollaborator.com).

Techniques for Optimal Code Reviews
Regardless of which type of lightweight code review your team chooses, there are tips and techniques[5] for preventing wasted time and improving the results:

Limit the amount of time – a developer should spend no more than sixty to ninety minutes at a time doing code review.
Go slowly – typically 200 to 500 lines of code per hour is the maximum rate for an effective review.
Limit the amount of code – as a product of the time and rate recommendations, the total amount of code for a review should be no more than 200 to 400 lines.
Have the author annotate the materials before the review starts. Just looking at the code using a different tool than their standard editor can lead developers to spot problems in their own code before the review begins.
Review checklists (if used) should be short, contain no items that are obvious or can be detected via automation, and should focus on things that are easy to forget (e.g. “Are all errors handled correctly everywhere?”).

Overcoming Resistance
A key Agile Principle[2] is: “The best architectures, requirements, and design emerge from self-organizing teams.” If peer code review is mandated by someone outside the team, its chance of success decreases. If team members do not want code review to succeed, it will fail.

Even when suggested by a team member, code review can still face resistance. A key to success is to start slowly. Do not attempt something like: “Starting today 100% of all code written must be peer reviewed.”

The key is to instead get the best return on time invested by initially doing code reviews only on a limited part of the source code. For example, one approach is to have the developers agree on the “top ten scariest source files” and then only review changes to those files. Or only review changes made to the stable branch of the source code. A slightly more extreme approach would be to just review unit tests – if the unit tests are complete and are passing, then those results indicate the underlying implementation is correct without investing additional review time.
The amount of code that gets reviewed can be expanded after a team has experience with code review and sees its value over time.

Summary
Peer code review is agile, when done correctly. The legacy of heavyweight code inspection processes has biased many agile developers away from code review, but there are multiple types of lightweight code review that work well in an agile environment. With the right approach and techniques, and by phasing in the use of code review over time, agile teams can more easily deliver working – and high quality – software.

Learning More
Read about the results and other insights in the book, Best Kept Secrets of Peer Code Review, written by the founders and associates of Smart Bear Software. Request a free copy of this book at http://www.CodeReviewBook.com.

References

The Agile Manifesto, http://agilemanifesto.org/, 2001.
The Agile Manifesto Principles, http://agilemanifesto.org/principles.html, 2001.
Jason Cohen, Best Kept Secrets of Peer Code Review, http://codereviewbook.com, 2006.
M. E. Fagan. “Design and code inspections to reduce errors in program development.” IBM Systems Journal, 15(3):216-245, 1976.
Smart Bear Software, 11 Best Practices of Peer Code Review, http://smartbear.com/docs/BestPracticesForPeerCodeReview.pdf, 2007.
Lawrence G. Votta, Jr., “Does every inspection need a meeting?” Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering, p.107-114, December 8-10, 1993, Los Angeles, California, United States.

Sound Off!
We value your input regarding this newsletter. Please take 2 minutes to fill out a survey (5 quick questions) that asks your opinion about this newsletter: Click here to take survey:

http://www.surveymonkey.com/s/7KKWHC9

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner - http://www.SoftwarePlanner.com
TestComplete (Automated Testing Tool) - http://www.TestComplete.com
Code Collaborator (Peer Code Review Tool) - http://www.SmartBear.com
Software Development /QA Templates -http://www.softwareplanner.com/Templates.asp
Test Case Training - http://www.SoftwarePlanner.com/Services.asp
Pragmatic Agile Development - http://www.softwareplanner.com/PADOverview.pdf

Reducing Costs with Good Requirements and Code Reviews

2009-12-22T10:22:00.003-07:00

Teams constrained by resources are always looking for a competitive advantage in reducing costs and improving software quality. This advantage can be achieved by implementing two best practices:

Writing good requirements
Providing peer code reviews

Studies have proven that the later a defect is discovered, the more it costs a team to fix. A study conducted by Dunn - "Software Defect Removal" - found that a defect that costs $1000 to fix when discovered during requirements analysis costs $25,000 to fix when left undiscovered until the quality assurance testing phase. Another study conducted by Jason Cohen, highlighted in his book - "Best Kept Secrets of Peer Code Review" showed that defects cost half as much to fix when found during code review vs. when discovered during quality assurance testing.

Defining Good Requirements
A good requirement contains these elements:

A narrative that explains what the requirement is going to accomplish
A prototype that depicts exactly what is expected (screen shots, report layouts, etc.)
A list of validation rules (e.g. allowable field sizes, allowed values, data validation, etc.)
A list of security rules (e.g. only administrators can access specific features)
A list of performance criteria (e.g. must be able to add a record in 3 seconds or less)
A list of audit rules (e.g. when adding or changing a record, store the history of the change)
Success criteria (e.g. objective criteria that can be evaluated to ensure this requirement meets the need)

Let's explore how taking this approach saves costs. Imagine we needed to develop a new screen to track our customer contacts and the screen entry needed to collect company name, contact name, email address and phone number. A poor requirement would simply describe the process (e.g. "create a data entry screen for collecting contacts") but would not include any of the other descriptive elements.

Without a prototype to guide him, the programmer might take liberties and design a screen that had a lot of ancillary fields (like birth date and marriage status) that may not be needed and may not include important fields (like email address and phone number). If no validation rules are specified, the programmers may not test a scenario where a new contact is added whose email address is the same as an existing contact -- causing a duplicate contact record.

If no security rules are identified, the screen may allow anyone to delete a contact and this may cause your team to lose an important contact record. If no performance criteria are set, the team may not test a scenario where you have 100,000 contacts in your contact list and your new software may slow to a crawl. If no audit rules are in place and a person deletes a contact, you may never know who deleted an important contact and why.

With a good QA team, many of the issues above would shake out during the quality assurance phase. However, the cost of discovering these issues and re-working the code is dramatically higher when discovered at this time. If the requirements had been written using the detailed elements above, the programmer would not have taken liberties to add additional fields and leave out important ones, they would have stress-tested the solution with large number of contacts, they would have implemented validation logic to ensure all fields were validated, they would have added logic to prevent duplicate records and would have audited records when deleted.

Defining good requirements is equally crucial for Waterfall and Agile projects -- the difference is that Agile projects will break the requirements into smaller units of work that are described by User Stories (what a user wants to do in each case). In our example above, a Waterfall approach would define all of the elements of each requirement at the outset of the project. An Agile approach would break each of those elements into separate User Stories (a User Story for the prototype, a User Story for the Validation Rules, etc.) and would incrementally implement each item in an iterative fashion.

It's also imperative to review requirements as a team (internal teams and client) once they are developed but before they are signed off. The review process lets extra eyes ensure that the elements above are addressed and that the requirement will meet the actual need.

Reducing Defects with Peer Code Reviews
As code is developed, it is important to review the code with your team. Below are a few items to look for in code reviews:

Ensure the code functionality meets the specifications in the requirement
Ensure each subroutine contains proper error trapping and handling
Inspect logic errors that can cause looping, memory leaks and performance issues
Inspect variable declarations to ensure that variables are cast properly to reduce boundary issues and invalid type casting
Review coding standards to ensure the code meets your internal standards, is well documented, and easy to maintain

The most efficient way to perform code reviews is to have team members inspect the code (called Peer Code Reviews) on a regular basis and openly discuss possible issues discovered during the code review. This activity can be done before checking the code in (called "pre commit") or after checking the code in (called "post commit"). The decision for pre or post commit is entirely up to your team and the way your team works best together.

By inspecting the code regularly, you can discover defects earlier in the development cycle which, like writing clear and detailed requirements, will reduce costs. Imagine a scenario where you reviewed the code and noticed that no logic had been added for preventing duplicate records from being added.

By discovering the issue prior to testing, you eliminate costly QA time to discover and report the issue. And if QA doesn't find the issue, you will spend exponentially more fixing it once the software has shipped to customers.

From a technical perspective, imagine a scenario where you had some logic that reads data from a database using a record set, then executes a loop over and over again until all the data is processed. A common programming mistake is not checking for a "no data found" or "end of file" condition.

A peer code review could quickly discover that the loop may be entered even if no data was loaded into the record set, which will only cause a failure under that condition. If this defect is not found until QA testing, your QA testers may see erratic behavior where it works sometimes (when data is found) but not other times (when no data is found). It may take your QA testers 2 to 3 days to discover the actual issue, so you have just added several days of effort to a problem that could easily have been discovered during a peer code review.

Reduce Project Costs with These Best Practices
Obviously, the sooner in your development cycle that you identify discrepancies in requirements and find defects, the less expensive the corrective measures will be. By writing good, detailed, and clear requirements at the outset of a project, and by having both team members and customers review them, you ensure that developers spend their time building the right thing the first time. By doing peer code reviews on your code before it goes to QA, you ensure that bugs are found immediately, while they are still easiest – and cheapest – to fix.

Can Tools Help?
Tools can help you with both of these issues.

Software Planner (http://www.SoftwarePlanner.com) allows you to keep all your requirements in a single place and allows your team to setup workflow to ensure that requirements are reviewed for best practices. Software Planner works equally well for Waterfall and Agile environments and allows teams to spot issues with requirements before it is too late and more costly to fix.

Code Collaborator (http://www.CodeCollaborator.com) allows your team to conduct peer code reviews online, a task that is painfully tedious and error prone without a tool.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner - http://www.SoftwarePlanner.com
TestComplete (Automated Testing Tool) - http://www.TestComplete.com
Code Collaborator (Peer Code Review Tool) - http://www.SmartBear.comSoftware Development /QA Templates -http://www.softwareplanner.com/Templates.asp
Test Case Training - http://www.SoftwarePlanner.com/Services.asp
Pragmatic Agile Development - http://www.softwareplanner.com/PADOverview.pdf

Basics of Test Driven Development (TDD)

2009-12-22T10:19:00.002-07:00

If you've heard of Test Driven Development (TDD) before but was not sure what it was or how it works, this newsletter provides a summary of the approach.

What is Test Driven Development?
Test Driven Development is a unique way to develop software by starting the process by collecting a requirement, developing test cases for the requirement, followed by the coding process. For traditional development and testing shops, this process "feels backwards" because traditional approaches perform the coding before beginning testing. However, this approach has been used for years by Agile Development teams.

So how does it Work?
For TDD to work, create your test cases using an automated testing tool and then write the code that causes the automated test(s) to pass. So here are the steps:

First fully understand the requirement
Create automated test(s) that test the requirement
Create the coding logic -- test it by running the automated test(s)
Once the automated test(s) pass, the coding then fulfills the requirement
Re-factor the code for better maintainability, run the automated test(s) again to ensure it still works

What are the Advantages of TDD?
Studies have shown that Test Driven Development reduces defect density, improves software quality, and in some cases make team productivity higher. Empirical Software Engineering Journal published a paper that summarized 4 cases studies (1 at IBM, 3 at Microsoft), where they followed the TDD practice and evaluated the effectiveness of it. For more information on this study, visit http://www.infoq.com/news/2009/03/TDD-Improves-Quality.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner -

http://www.SoftwarePlanner.com

TestComplete (Automated Testing Tool) - http://www.TestComplete.com

Software Development /QA Templates -http://www.softwareplanner.com/Templates.asp

Test Case Training - http://www.SoftwarePlanner.com/Services.asp

Pragmatic Agile Development - http://www.softwareplanner.com/PADOverview.pdf

15 Useful Test Cases for ensuring Consistent User Interfaces

2009-12-22T10:06:00.002-07:00

When testing user interfaces, it is easy to overlook test cases that ensure that your user interface is user-friendly and consistent. This newsletter identifies 20 test cases that might be considered when testing user interfaces for consistency.

15 Useful Test Cases for ensuring Consistent User Interfaces

Screen Font Type - Ensure that the screen font family matches from screen to screen. Mismatching fonts within the same sentence and overuse of different fonts can detract from the professionalism of your software user interface.
Screen Font Sizes - Ensure that the screen font sizes match from screen to screen. A good user interface will have an accompanying style guide that explicitly defines the font type and size for headers, body text, footers, etc.
Colors - Ensure that screens do not use different color sets as to cause an inconsistent and poorly thought-out user interface design. Your style guide should define header colors, body background colors, footer colors, etc.
Icons - Ensure that icons are consistent throughout your application by using a common icon set. For example, a BACK link that contains an icon next to it should not have a different icon on one screen versus another. Avoid free clip-art icons, opt for professionally designed icons that complement the overall look and feel of your screen design.
Narrative Text - Having narrative text (screen instructions) is a great way to communicate how to use a specific screen. Ensure that narrative text appears at the same location on the screen on all screens.
Brevity - Ensure that narrative text, error messages and other instructions are presented in laymen's terms but are brief and to-the-point.
Dialog Box Consistency - Use a style guide to document what choices are available for dialog boxes. You should have not have Save/Cancel dialog on one screen and an OK/Cancel on another, this is inconsistent.
Links - If your application has links on the screen (e.g. Save as Spreadsheet, Export, Print, Email, etc.), ensure that the links have consistent spacing between them and other links, that the links appear in the same order from screen to screen, and that the color of the links are consistent.
Menus - If your application has menu items, ensure that menu items that are not applicable for the specific screen are disabled and the order in which each menu item appears is consistent from screen to screen.
Buttons - If your application has buttons (e.g. Submit, OK, Cancel, etc), ensure that the buttons appear in a consistent order from screen to screen (e.g. Submit then Cancel).
Abbreviation Inconsistencies - If your screens contain abbreviations (e.g. Nbr for number, Amt for amount, etc), the abbreviations should be consistent for all screens in your application. Again, the style guide is key for ensuring this.
Delete Confirmations - It is a good practice to ask the user to confirm before deleting an item. Create test cases to ensure that all delete operations require the confirmation. Taking this a step further, it would also be great to allow clients to turn off specific confirmations if they decide to do this.
Save Confirmations - It is good practice to ask the user to confirm an update if updates are made and they navigate to another item before explicitly saving. Create test cases to ensure that all record movement operations require the confirmation when updates are made. Taking this a step further, it would also be great to allow clients to turn off specific confirmations if they decide to do this.
Grammar and Spelling - Ensure that you have test cases that look for grammar or spelling errors.
Shortcuts - If your application allows short cut keys (like CTRL+S to save), ensure that all screens allow using of the consistent shortcuts.

By the way, did you notice any inconsistency above? We intentionally showed 15 useful test cases above but the narrative before the listing shows 20 test cases. Inconsistencies are easy to spot, right?

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner - http://www.SoftwarePlanner.com
TestComplete (Automated Testing Tool) - http://www.TestComplete.com
STAR QA (Automated Testing Resources) - http://www.star-qa.com
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Test Case Training - http://www.PragmaticSW.com/Services.asp Pragmatic
Agile Development - http://www.pragmaticsw.com/PADOverview.pdf

20 Useful Test Cases for testing User Interfaces

2009-12-22T10:00:00.003-07:00

When testing user interfaces, it is easy to overlook test cases that would be helpful for a more thoroughly tested solution. This newsletter identifies 20 test cases that might be considered when testing user interfaces.

20 Useful Test Cases for testing User Interfaces

Required Fields - If the screen requires data entry on a specific field, it is good practice to identify the required fields with a red asterisk and to give a friendly warning if the data is left blank.
Data Type Errors - If the screen contains dates, numeric, currency or other specific data types, ensure that only valid data can be entered.
Field Widths - If the screen contains text boxes that allow data entry, ensure that the width of data entered does not exceed the width of the table field (e.g. a title that allows 100 characters in the database should not allow more than 100 characters to be entered from the user interface).
Onscreen Instructions - Any screen that is not self-explanatory to the casual user should contain onscreen instructions that aid the user.
Keep Onscreen Instructions Brief - While onscreen instructions are great, keep the wording informative, in layman's terms, but concise.
Progress Bars - If the screen takes more than 5 seconds to render results, it should contain a progress bar so that the user understands the processing is continuing.
Same Document Opened Multiple Times - If your application opens the same document multiple times, it should append a unique number to the open document to keep one document from overwriting another. For example, if your application opens a document named Minutes.txt, if it opens the same document for the same user again, consider having it append the time to the document or sequentially number it (Minutes2.txt or Minutes_032321.txt).
Cosmetic Inconsistencies - The screen look, feel and design should match the other screens in your application. Creating and using a style guide is a great way to ensure consistency throughout your application.
Abbreviation Inconsistencies - If your screens contain abbreviations (e.g. Nbr for number, Amt for amount, etc), the abbreviations should be consistent for all screens in your application. Again, the style guide is key for ensuring this.
Save Confirmations - If your screen allows changing of data without saving, it should prompt you to save if you move to another record or screen.
Delete Confirmations - If a person deletes an item, it is a good idea to confirm the delete. However, if your user interface allows deleting several records in a row, in some cases you might consider allowing them to ignore the confirmation as it might get frustrating to click the confirmation over and over again.
Type ahead - If your user interface uses combo boxes (drop down lists), be sure to include type ahead (if you have hundreds of items in a list, if you type in the first letter it will skip to the first item that begins with that letter).
Grammar and Spelling - Ensure that you have test cases that look for grammar or spelling errors.
Table Scrolling - If your application lists information in table format, if the data in the table extends past one page, the scrolling should scroll the data but leave the table headers in tact.
Error Logging - If fatal errors occur as users use your application, ensure that your applications writes those errors to a log file, event viewer or a database table for later review. Log the routine the error was in, the person logged on, and the date/time of the error.
Error Messages - Ensure that error messages are informative, grammatically correct, and not condescending.
Shortcuts - If your application allows short cut keys (like CTRL+S to save), test each shortcut to ensure it works in all different browsers (if the application is web based).
Invalid Choices - Do not include instructions for choices not available at the time. For example, if a screen cannot be printed due to the state of the data, the screen should not have a Print button.
Invalid Menu Items - Do not show menu items that are not available for the context you are currently in.
Dialog Box Consistency - Use a style guide to document what choices are available for dialog boxes. You should have not have Save/Cancel dialog on one screen and an OK/Cancel on another, this is inconsistent.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner -

http://www.SoftwarePlanner.com

TestComplete (Automated Testing Tool) - http://www.TestComplete.comSoftware Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

Test Case Training - http://www.PragmaticSW.com/Services.asp

Pragmatic Agile Development - http://www.pragmaticsw.com/PADOverview.pdf

Benefits of Keyword Driven Testing for Test Automation

2009-12-22T09:53:00.003-07:00

Most software companies have considered automated testing and many have fully automated their regression test cases in an effort to reduce manual effort needed to test new builds of their software. Many companies that have been successful with automation attribute it to keyword driven testing techniques that reduce the time spent creating test cases.

This newsletter addresses why companies consider automation and best practices for ensuring that time spent automating test cases provide a return on investment.

Why Automate Your Test Cases?
Many companies run their regression test cases manually, so when does it make sense to begin automating your regression test cases? It makes sense to automate your test cases when you can no longer run the regression test cases on each build created. For example, if you are doing daily or weekly builds of your code to quality assurance and you cannot quickly run your regression test cases with each build, it is time to consider automating them. Automating your test cases provide these benefits:

Quicker Releases – By having your regression test cases run automatically, your software quality team can concentrate on testing new features of your software and less time regressing existing features.
Higher quality releases – Your software releases will have fewer bugs and require less customer support because they will be of higher quality.
Happier Customers – Your customers will be happier and more willing to serve as testimonials for future prospects.

Why Does Automation Fail?
Many companies are thinking about test case automation or have experimented with it in the past. Some companies that experimented with it eventually abandoned it because of these reasons:

Poor Understanding of Test Automation – Many companies see automation as a silver bullet that will allow them to quickly automate every test scenario quickly and allow them to abandon manual testing and reduce staff. In reality, automated testing is designed to quicken the running of regression test cases but it is not a substitute for manual testing. A quality-oriented software team will see the value of utilizing both automated and manual test cases to ensure great test coverage and higher quality releases.
Improper Tester Education – Automation requires a tester to learn the testing tool. Companies that purchase the tool but not any training will eventually abandon the tool because the testers are not equipped to use the tool.
Lure of Record / Playback – Many companies think that they can quickly get up and running with automation by simply recording their screen actions and playing them back. While record and playback will create scripts that they can use as a starting point for your automation, it does take time to update the scripts to be more re-usable and it takes scripting language knowledge to do this.

What is Keyword Driven Testing?
Most automated tools require the test engineer to understand a scripting language (VB Script, Java Script, etc.) to write their automated test cases. Most tools have the ability to create the scripts using record and playback, but this does not always write the most efficient scripting code and is not as re-usable and maintainable.

Since many testers do not have deep scripting skills, it is imperative that your automated testing tool has a way to create Keyword Driven Tests. Keyword Driven Testing is a way to define automated test cases without the need for scripting skills. It allows a tester (or even a subject matter expert) to create automated tests by describing each step of the automation.

For example, if you are automating the login process of your application, your user will access your application, type in their user-id and password and press a button to login. Traditionally, testers would do this by writing VB Script that will navigate to your application, identify each object on the screen (user-id, password and login button), then write script to enter in the user-id, password and to press the login button.

With keyword driven testing, the tester does not need to understand the scripting language to make this happen, they can simply describe the event (navigate to your application, enter in "abc" for the user-id, enter in "xxx" for the password, press the Login button when done). As you can imagine, this is a much simpler approach to automated testing than scripting.

How have Successful Companies Implemented Automation?
Successful companies understand the enormous benefits of automated testing and have implemented strategies to ensure that they receive the maximum return on investment with their test efforts. Below are the secrets to becoming successful with test automation:

Start Smart – Automation efforts are similar to software development efforts -- it takes upfront thought and a good test design architecture to ensure that your automated test cases will be re-usable and easy to maintain. Before jumping into automation, ensure that your automated tool has the ability to maximize your efforts with keyword driven testing -- as this will ensure that you can easily re-use your automated test cases.
Start Small – Start your automation efforts on an established project that already has a good set of manual regression test cases written. Take those manual regression test cases and develop your automated test cases that will replace them. Once this is done, you will find that you can automatically run those automated test cases each day of builds and with minimal efforts, freeing your team up to do more manual exploratory test cases. Once you have this established for a single project, move on to other projects and expand your effort.
Blend Automated and Manual Tests – Not all test cases should be automated. Some test cases require a human eye to ensure that screen cosmetics are appropriate, that data is reasonable, etc. Spend time automating test cases that do not require this type of human contact and continue to use manual test cases when appropriate. A good application lifecycle tool should allow you to track both automated and manual test cases.
Keep track of Metrics – Keep track of how many automated and manual test cases are run for each build, how many pass, how many fail, etc. Track how many additional automated test cases your team can write with each release so that you can determine average time needed to develop automated test cases in the future. Track how many defects are found post-production to determine if your automation efforts are paying dividends. A good application lifecycle tool should allow you to track metrics for both automated and manual test cases.
Build on your Successes – Once you have successfully implemented automated testing on a single project, roll it out to more projects. Help other teams in your organization learn the benefits of automation and help them do it right.
Schedule Your Automation Efforts - A good application lifecycle tool will allow you to organize your automated test cases into "test sets" that allow you to run test cases in a specific order. It should also allow you to schedule those test sets to run at specific intervals (nightly, weekly, monthly, etc.).

How can I learn more about Test Automation?
There are a number of automated and manual test management solutions on the market, as long as your selected solution allows you to follow the best practices of this newsletter, you can easily begin making the transition to automation and begin receiving a return on investment from your efforts.

If you don't have a solution for both automated and manual testing, Software Planner (http://www.SoftwarePlanner.com) and TestComplete (http://www.testcomplete.com) offer an integrated solution that offers both automated and manual test cases and has a keyword driven testing engine that ensures re-usability and maintainability.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner - http://www.SoftwarePlanner.com
AutomatedQA TestComplete (Automated Testing Tool) - http://www.TestComplete.com
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Test Case Training - http://www.PragmaticSW.com/Services.asp
Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf

The Seven Habits of Highly Effective Scrum Masters

2009-12-22T09:41:00.003-07:00

Published in 1989, The Seven Habits of Highly Effective People, written by Stephen R. Covey has helped millions establish great habits for achieving true interdependent effectiveness in their life and their jobs. This article discusses the 7 habits, framing the habits for highly effective scrum masters. Below are the 7 habits:

Be Proactive
Begin with the End in Mind
Put First Things First
Think Win/Win
Seek First to Understand, Then to be Understood
Synergize
Sharpen the Saw

Habit 1 - Be Proactive
A Scrum Master's goal in any software project is to empower team members to get things done and to remove impediments. Below are some ideas for being proactive on software projects:

Run Daily Scrum Meetings
Each day, your team should hold a Daily Scrum Meeting. Normally, this daily meeting is set for 15 minutes and each team member is asked 3 questions:

“What did you do yesterday?”
“What will you do today?”
“Are there any roadblocks or anything impeding your progress?”

15 minutes is not always enough time to have a good dialog and a meaningful meeting, some days may take 30 to 45 minutes. To speed this up, consider having each team member post a summary of what they did yesterday and a summary of what they plan to do tomorrow in a daily discussion forum that is automatically distributed to all team members. This allows you to spend the Daily Scrum meeting talking about roadblocks, design decisions, and impediments to progress.

References:
Discussion Forums - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=DiscussionBoard

Best Foot Forward
A key way to reduce cost and time overruns is to prevent them during design. Some Agile evangelists might argue that doing user stories (which normally do not contain detailed requirements, prototypes or designs) is the best approach. Although our team has been using Agile for years, we found that user stories are not detailed enough, as they tend to cause too much rework and have a tendency to reduce the accuracy of estimates. Agile is designed to be flexible and tweaked for your specific needs so by deploying a more structured requirements gathering, we enjoy the flexibility of Agile and the reduction of rework, providing us with the best of both worlds.

References:
Requirements - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=FunctionalSpecifications
Detailed Design - http://www.pragmaticsw.com/Templates.asp

Review Metrics Daily
It is important to ensure that the Agile sprint will complete on time. You can ensure this by having team members enter their time daily and reviewing burndown and velocity charts.

References:
Burn Down Chart - http://www.pragmaticsw.com/WhitePaper_SP_Metrics.pdf

Habit 2 - Begin with the End in Mind
Your end goal for the sprint should be to deliver high quality software that meets the goals of the sprint. Before coding begins, you should make a list of success criteria that you judge the project on. For example, your success criteria may be that the software produces specific results, has no known defects (or a small number of low severity defects), is reusable, is maintainable, is well documented, is easy to use, etc.

By defining the success criteria up front, you can objectively evaluate whether the project met the criteria or not. Solicit help from all team members (product owner, scrum master, developer, tester, etc.) when defining the success criteria. By getting a team perspective of the success criteria, you will have better and more measurable criteria and you will get much better buy-in from the team. Below are some tips for ensuring your meet your success criteria at the end:

Identify success criteria - Make sure your success criteria is published and agreed upon by the team members.
Review success criteria - At least weekly (in one of your daily team meetings), review the success criteria. This can include reviewing your defect statistics, test case run history, etc. to allow you to determine if you are progressing towards the success criteria as the project continues.
Retrospective - Once your project is complete, do a "post mortem" or "

retrospective

" to determine if you met your success criteria.

References:
Retrospectives - http://www.softwareplanner.com/Newsletters/newsletter_2008_08_SP.htm

Habit 3 - Put First Things First
Prioritizing work effort is critical. You must apply effort to the most important things first, followed by less important things. Work the higher priority items first, then the lower priority items if time allows.

Habit 4 - Think Win/Win
When dealing with projects, you want to foster a win/win relationship between your team and the client. The alternative to that is:

Win/Loss - In this scenario, your team wins but the client loses. This can cause loss of future business with the client.
Lost/Win - In this scenario, your team loses but the client wins. This can cause team burnout, financial distress and other issues.
Win/Win - This is the scenario you want to foster. In this scenario, both your team and the client wins. How is it done? Normally this centers around the project management pyramid (Features, Time, Cost). To foster a win/win relationship, one of those variables must be flexible. Once your team and client agree to that, it is much easier to make objective decisions about how to plan the project.

Here are examples:

More Features / Less Time - The flexible variable is cost, so your client agrees to absorb more costs (you can hire more people).
Cost Savings / Less Time - The flexible variable is features, so less features will be delivered but costs and time will be less.
More Features / More Costs - The flexible variable is time, allowing you to extend the timeline.

Habit 5 - Seek First to Understand, Then to be Understood
Many of us have a bad habit of blocking out a conversation and not listening because we so desperately want our opinion to be heard. Every team member (product owner, scrum master, developer, tester, etc.) has different experiences, different perspectives and motivations. Before you can solve any problem, it is important to first listen intently and diligently to fully understand the problem.

Once you feel you have all the facts, solicit ideas for multiple solutions. Having several options can provide better discussions and allows team members to tweak initial solutions into solutions that are more far reaching and solve the problem in a more direct way. If you disagree with an approach, don't attack the person that offered the approach. Instead, explain based on your past experiences why you think there might be a better approach.

Habit 6 - Synergize
Team collaboration is the key to a synergized team. A synergized team is made up of divergent team members that have different strengths, different backgrounds and different perspectives. Encourage these differences but provide your team with tools that allow you maximize their effectiveness.

Highly collaborative teams communicate with each other by sharing their calendars, posting their statuses into discussion forums so that everyone is aware of what the other is doing and accomplishing. These teams keep track of all tasks they work on each day, the number of hours worked, the number of hours remaining and variances to plan. They also share documents that illustrate best practices and produce white papers that teach others what they have learned.

References:

Tools -

http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=OverviewSoftwarePlanner

Calendar Sharing - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=Calendar

Discussion Forums - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=DiscussionBoard

Task Tracking - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=ProjectPlans

Document Sharing - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=SharedDocuments

Habit 7 - Sharpen the Saw
Productive scrum masters see the need to continue honing their skills and love learning new techniques, best practices and approaches. Below are some links that might be of interest to you:

Agile Overview -

http://www.pragmaticsw.com/Newsletters/newsletter_2008_02_SP.htm

Team Composition - http://www.pragmaticsw.com/Newsletters/newsletter_2008_03_SP.htm

Understanding Scrum Rules - http://www.pragmaticsw.com/Newsletters/newsletter_2008_04_SP.htm

Scrum Kickoff and Product Backlog - http://www.pragmaticsw.com/Newsletters/newsletter_2008_05_SP.htm

The 30 Day Sprint and Daily Scrum Meeting - http://www.pragmaticsw.com/Newsletters/newsletter_2008_06_SP.htm

Agile Reporting and Metrics - http://www.pragmaticsw.com/Newsletters/newsletter_2008_07_SP.htm

Retrospectives - http://www.pragmaticsw.com/Newsletters/newsletter_2008_08_SP.htm

Tailoring Scrum to your Needs - http://www.pragmaticsw.com/Newsletters/newsletter_2008_09_SP.htm

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner -

http://www.SoftwarePlanner.com

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf

Agile Training - http://www.PragmaticSW.com/Services.asp

Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

The Seven Habits of Highly Effective Agile Scrum Product Owners

2009-12-22T09:28:00.001-07:00

Be Proactive
Begin with the End in Mind
Put First Things First
Think Win/Win
Seek First to Understand, Then to be Understood
Synergize
Sharpen the Saw

Pre-Requisite Information
This newsletter discusses habits for highly effective Agile Scrum Product Owners. If you are not familiar with Agile or Scrum, please see our newsletters at http://www.PragmaticSW.com/Newsletters.asp, specifically those posted February 2008 - September 2008, those newsletters explain Agile Scrum in detail.

Habit 1 - Be Proactive
A Product Owner's goal in any software project is to ensure that the project produces the highest return on investment (ROI) in the shortest amount of time. Below are some ideas for being proactive on Agile software projects:

Communicate Sprint Rules to Management
Since the product owner is responsible for prioritizing the product backlog and is responsible for ROI, the product owner must communicate to his/her upper management that once the sprint begins, they can not push for new features in the sprint unless they are willing to abandon the sprint. Upper management sometimes tries to interfere with the sprint by introducing features not currently in the backlog and derailing team members with busy work that can cause the sprint to fall behind schedule. The product owner must communicate the rules to management and remind them if this behavior happens, the sprint must be aborted and a new sprint must be planned.

Meet Daily
It is important to participate in the Daily Scrum Meeting. This provide full transparency - if you review progress, status and impediments daily, you should never be surprised if tasks begin to slip and you can proactively resolve those to reduce slippage. When meeting daily, hold the meeting first thing in the morning and try to keep the meeting to 30 minutes or less. Here would be a typical agenda for the meeting:

Review progress - Do this by analyzing a project burn down chart. This shows how well you are progressing towards completion of the project.
Identify slippage - After reviewing progress, identify if anyone is slipping in their tasks and brain storm on helping them catch up.
Remove Roadblocks - Ask if anyone is experiencing impediments and roadblocks. Help clear those roadblocks.

Learn More: http://www.pragmaticsw.com/WhitePaper_SP_Metrics.pdf

Habit 2 - Begin with the End in Mind
Your end goal for a sprint should be to deliver software that could be released to production if needed (high quality is important). Before the sprint begins, you should make a list of success criteria that you judge the sprint on. For example, your success criteria may be that the certain backlog items are complete, has no known defects (or a small number of low severity defects), is reusable, is maintainable, is well documented, is easy to use, etc. By defining the success criteria up front, you can objectively evaluate whether the project met the criteria or not. Below are some tips for ensuring your meet your success criteria at the end:

Identify success criteria - Make sure your success criteria is published and agreed upon by the team members.
Review success criteria - At least weekly (in one of your Daily Scrum Meetings), review the success criteria. This can include reviewing your defect statistics, test case run history, etc. to allow you to determine if you are progressing towards the success criteria as the sprint continues.
Retrospective - Once your project is complete, do a "retrospective" to determine if you met your success criteria.

Learn More: http://www.softwareplanner.com/Newsletters/newsletter_2008_08_SP.htm

Habit 3 - Put First Things First
Prioritizing the product backlog is critical. You must apply effort to the most important things first, followed by less important things because this directly affects ROI.

Prioritize the Product Backlog - When planning a sprint, it is important to ensure that the most important features are being worked on during the sprint. To do this, prioritize the product backlog as high, medium and low (in terms of how it will impact ROI). Within the high priority items, prioritize the relative importance of those items (1 to 10, with 1 being the most important to ROI).
Best Foot Forward - Review the product backlog priorities often. It is OK to change the priorities during the sprint for the items that have not yet begun to ensure that the items being worked on will benefit ROI in the best way.

Habit 4 - Think Win/Win
When dealing with projects, you want to foster a win/win relationship between your team and the client. The alternative to that is:

Win/Loss - In this scenario, your team wins but the client loses. This can cause loss of future business with the client.
Lost/Win - In this scenario, your team loses but the client wins. This can cause team burnout, financial distress and other issues.
Win/Win - This is the scenario you want to foster. In this scenario, both your team and the client wins. How is it done? Normally this centers around the project management pyramid (Features, Time, Cost). To foster a win/win relationship, one of those variables must be flexible. Once your team and client agree to that, it is much easier to make objective decisions about how to plan the project. Here are examples:

1. More Features / Less Time - The flexible variable is cost, so your client agrees to absorb more costs (you can hire more people).

2. Cost Savings / Less Time - The flexible variable is features, so less features will be delivered but costs and time will be less.

3. More Features / More Costs - The flexible variable is time, allowing you to extend the timeline.

Habit 5 - Seek First to Understand, Then to be Understood
Many of us have a bad habit of blocking out a conversation and not listening because we so desperately want our opinion to be heard. Every team member (Product Owner, Scrum Master, Team Members) has different experiences, different perspectives and motivations.

Before you can solve any problem, it is important to first listen intently and diligently to fully understand the problem. Once you feel you have all the facts, solicit ideas for multiple solutions. Having several options can provide better discussions and allows team members to tweak initial solutions into solutions that are more far reaching and solve the problem in a more direct way. If you disagree with an approach, don't attack the person that offered the approach. Instead, explain based on your past experiences why you think there might be a better approach.

Habit 6 - Synergize
For Agile teams, team collaboration and empowerment is the key to a synergized team. A synergized team is made up of divergent team members that have different strengths, different backgrounds and different perspectives. Encourage these differences but provide your team with tools that allow you maximize their effectiveness. Highly collaborative teams communicate with each other by sharing their calendars, posting their statuses into discussion forums so that everyone is aware of what the other is doing and accomplishing. These teams keep track of all tasks they work on each day, the number of hours worked, the number of hours remaining and variances to plan. They also share documents that illustrate best practices and produce white papers that teach others what they have learned.

Learn More:

Tools - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=OverviewSoftwarePlanner
Calendar Sharing - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=Calendar
Discussion Forums - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=DiscussionBoard
Task Tracking - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=ProjectPlans
Document Sharing - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=SharedDocuments

Habit 7 - Sharpen the Saw
Productive product owners see the need to continue honing their skills and love learning new techniques, best practices and approaches. They proactively learn about different ways to improve Agile projects. Below are some links that might be of interest to you:

Agile Alliance - http://www.agilealliance.com/show/1641
Yahoo Scrum Development Group - http://groups.yahoo.com/group/scrumdevelopment/
Agile Project Management - http://finance.groups.yahoo.com/group/agileprojectmanagement/
Agile Overview - http://www.pragmaticsw.com/Newsletters/newsletter_2008_02_SP.htm
Team Composition - http://www.pragmaticsw.com/Newsletters/newsletter_2008_03_SP.htm
Understanding Scrum Rules - http://www.pragmaticsw.com/Newsletters/newsletter_2008_04_SP.htm
Scrum Kickoff and Product Backlog - http://www.pragmaticsw.com/Newsletters/newsletter_2008_05_SP.htm
The 30 Day Sprint and Daily Scrum Meeting - http://www.pragmaticsw.com/Newsletters/newsletter_2008_06_SP.htm
Agile Reporting and Metrics - http://www.pragmaticsw.com/Newsletters/newsletter_2008_07_SP.htm
Retrospectives - http://www.pragmaticsw.com/Newsletters/newsletter_2008_08_SP.htm
Tailoring Scrum to your Needs - http://www.pragmaticsw.com/Newsletters/newsletter_2008_09_SP.htm

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner - http://www.SoftwarePlanner.com
Automated Testing Resources - http://www.Star-QA.com
Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Agile Training - http://www.PragmaticSW.com/Services.asp
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

The Seven Habits of Highly Effective Project Managers

2009-12-21T16:45:00.004-07:00

Be Proactive
Begin with the End in Mind
Put First Things First
Think Win/Win
Seek First to Understand, Then to be Understood
Synergize
Sharpen the Saw

Habit 1 - Be Proactive
A project manager's goal in any software project is to ensure that the software is shipped on time, within budget, with high quality while satisfying the software requirements. Below are some ideas for being proactive on software projects:

Understand Your History - When planning projects, you should know what your variances have been on past projects (how many hours were estimated vs. how many hours were actually spent).
Best Foot Forward - A key way to reduce cost and time overruns is to prevent them during design. When collecting requirements, have your team review them for completeness and testability. Back the requirements with a detailed design and prototypes, as this allows you to better understand (and agree on) the solution and provides more detail for better estimates. Some Agile evangelists might argue that doing user stories (which normally do not contain detailed requirements, prototypes or designs) is the best approach. Although our team has been using Agile for years, we found that user stories are not detailed enough, as they tend to cause too much rework and have a tendency to reduce the accuracy of estimates. Agile is designed to be flexible and tweaked for your specific needs so by deploying a more structured requirements gathering, we enjoy the flexibility of Agile and the reduction of rework, providing us with the best of both worlds.
Communicate Effectively - During development, it is imperative that everyone knows the status of the development effort and to allow people to ask questions and get answers regarding specific requirements. To do this, communicate daily status and requirement questions via email or a discussion forum. Have developers discuss (briefly) what code modules they worked on for the day -- this allows others to know what areas they are working in and can proactively alert them if they are also working in an area that might causes issues based on the work they are doing. Have developers and testers ask questions about requirements and have subject matter experts respond to those questions with answers. This can dramatically reduce QA time.
Meet Daily - No matter if you are using Waterfall or Agile development, it is important to meet daily with your development and testing team to know the status of where things stand. This provide full transparency - if you review progress, status and impediments daily, you should never be surprised if tasks begin to slip and you can proactively resolve those to reduce slippage. When meeting daily, hold the meeting first thing in the morning and try to keep the meeting to 30 minutes or less. Here would be a typical agenda for the meeting:

Review progress - Do this by analyzing a project burn down chart. This shows how well you are progressing towards completion of the project.

Identify slippage - After reviewing progress, identify if anyone is slipping in their tasks and brain storm on helping them catch up.

Remove Roadblocks - Ask if anyone is experiencing impediments and roadblocks. Help clear those roadblocks.

For example, your success criteria may be that the software produces specific results, has no known defects (or a small number of low severity defects), is reusable, is maintainable, is well documented, is easy to use, etc. By defining the success criteria up front, you can objectively evaluate whether the project met the criteria or not.

Solicit help from all team members (project managers, product managers, testers, automation engineers, other developers, documentation specialists, etc.) when defining the success criteria. By getting a team perspective of the success criteria, you will have better and more measurable criteria and you will get much better buy-in from the team. Below are some tips for ensuring your meet your success criteria at the end:

Identify success criteria - Make sure your success criteria is published and agreed upon by the team members.
Review success criteria - At least weekly (in one of your daily team meetings), review the success criteria. This can include reviewing your defect statistics, test case run history, etc. to allow you to determine if you are progressing towards the success criteria as the project continues.
Retrospective - Once your project is complete, do a "post mortem" or "retrospective" to determine if you met your success criteria.

Habit 3 - Put First Things First
Prioritizing work effort is critical. You must apply effort to the most important things first, followed by less important things. Many times a project can introduce cost and time overruns by small decisions that are made each day. The project manager must keep a close eye on these things to ensure that the project has the best chance of completing on time and on budget. Here are some examples of innocent "small" changes that could impact your project deliverables:

Feature Changes - Many times the team is tempted to make "small changes" to a requirement during the coding or testing phase under the guise of making the feature more attractive or usable. If the proper thought is put into the requirements, use cases, prototyping and design, the probability of this happening during coding or testing is less. A "small change" can impact many things. For example, imagine that a developer presents the case for enhancing a particular screen to have a bit different design than was originally set. Although making the coding changes might be minimal (a few hours), it is important to see that it might also trigger a change to the requirements document, the test cases, automated test cases, the help system and other documentation. So this "small" 4 hour coding change could turn into a 3 day impact on the overall project plan.
Enhancements Disguised as Defects - Sometimes testers will disguise an enhancement as a defect. If the developer is not familiar with how it was originally implemented (or why it was implemented this way), they may assume it is a defect and make a change that impacts existing clients. Although the tester saw this as a great change for their clients, it may impact clients that do not see it as a good change. To mitigate this, the project management and/or product owner should triage defects to ensure that they are true defects, not enhancement requests.

Habit 4 - Think Win/Win
When dealing with projects, you want to foster a win/win relationship between your team and the client. The alternative to that is:

Win/Loss - In this scenario, your team wins but the client loses. This can cause loss of future business with the client.
Lost/Win - In this scenario, your team loses but the client wins. This can cause team burnout, financial distress and other issues.
Win/Win - This is the scenario you want to foster. In this scenario, both your team and the client wins. How is it done? Normally this centers around the project management pyramid (Features, Time, Cost). To foster a win/win relationship, one of those variables must be flexible. Once your team and client agree to that, it is much easier to make objective decisions about how to plan the project.

Here are examples:

More Features / Less Time - The flexible variable is cost, so your client agrees to absorb more costs (you can hire more people).
Cost Savings / Less Time - The flexible variable is features, so less features will be delivered but costs and time will be less.
More Features / More Costs - The flexible variable is time, allowing you to extend the timeline.

Once you feel you have all the facts, solicit ideas for multiple solutions. Having several options can provide better discussions and allows team members to tweak initial solutions into solutions that are more far reaching and solve the problem in a more direct way. If you disagree with an approach, don't attack the person that offered the approach. Instead, explain based on your past experiences why you think there might be a better approach.

Highly collaborative teams communicate with each other by sharing their calendars, posting their statuses into discussion forums so that everyone is aware of what the other is doing and accomplishing. These teams keep track of all tasks they work on each day, the number of hours worked, the number of hours remaining and variances to plan. They also share documents that illustrate best practices and produce white papers that teach others what they have learned.

Habit 7 - Sharpen the Saw
Productive project managers see the need to continue honing their skills and love learning new techniques, best practices and approaches. They proactively learn about different ways to manage projects, including PMI, ITL, CMMI, and Agile. Below are some links that might be of interest to you:

Project Management Institute (PMI) - http://www.pmi.org
Information Technology Lab (ITL) - http://www.itl.nist.gov/
Capability Maturity Model Integration (CMMI) - http://www.sei.cmu.edu/cmmi/

Learning Agile - These newsletters explain the basics of Agile Scrum:

Agile Overview - http://www.pragmaticsw.com/Newsletters/newsletter_2008_02_SP.htm
Team Composition - http://www.pragmaticsw.com/Newsletters/newsletter_2008_03_SP.htm
Understanding Scrum Rules - http://www.pragmaticsw.com/Newsletters/newsletter_2008_04_SP.htm
Scrum Kickoff and Product Backlog - http://www.pragmaticsw.com/Newsletters/newsletter_2008_05_SP.htm
The 30 Day Sprint and Daily Scrum Meeting - http://www.pragmaticsw.com/Newsletters/newsletter_2008_06_SP.htm
Agile Reporting and Metrics - http://www.pragmaticsw.com/Newsletters/newsletter_2008_07_SP.htm
Retrospectives - http://www.pragmaticsw.com/Newsletters/newsletter_2008_08_SP.htm
Tailoring Scrum to your Needs - http://www.pragmaticsw.com/Newsletters/newsletter_2008_09_SP.htm

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner - http://www.SoftwarePlanner.com
Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Agile Training - http://www.PragmaticSW.com/Services.asp
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

The Seven Habits of Highly Effective Developers

2009-12-21T16:36:00.004-07:00

Be Proactive
Begin with the End in Mind
Put First Things First
Think Win/Win
Seek First to Understand, Then to be Understood
Synergize
Sharpen the Saw

Habit 1 - Be Proactive
A developer's goal in any software project is to ensure that the software is developed to a requirement that meets the customer need and one that produces software that is reusable and maintainable. Below are some ideas for being proactive on software projects:

Be Responsible for Great Requirements - Don't blame others for poor

requirements

. Instead, work with the team to fully analyze the requirements to ensure they are complete, accurate and meet the needs of the customer.

Analyze Reusability during Design - When creating a design, many developers look no further than the current requirement for their design. When creating a detailed design for the requirement, the developer should approach it to be used in other ways than fill the existing design need. For example, if you are designing a new system and it has 20 listing screens and 20 edit screens, it would be better to design a single listing and a single edit screen that can accommodate all 20 needs. The screens can look and feel different if needed, but you can still use the same code base by deploying "behaviors" that dictate how the screen operates. By making the screen reusable, you can then build additional listing and edit screens quickly because you are not re-writing code from scratch. It also helps in maintainability because if a major screen flaw is found, you are only fixing a single screen rather than 20 distinct screens.

Communicate Effectively - During development, it is imperative that everyone knows the status of the development effort. Communicate daily status via email or a discussion forum. Discuss any impediments that are keeping you from making progress. Discuss (briefly) what code modules you worked on for the day -- this allows others to know what areas you are working in and can proactively alert them if they are also working in an area that might causes issues based on the work you are doing.

Review Test Plans before Coding Begins - A great way to be proactive in decreasing QA time is to have your QA team publish test cases before coding begins. You should require that your developers review the test cases before beginning coding and that they run the test cases prior to shipping the code to QA for testing. This reduces QA time by validating that the test cases have good coverage for the requirement and by bringing to light things that the testers are expecting you to code for (validation issues, bounds, etc.). For this to be effective, you must build time into the project plan for the developers to do this. A good rule of thumb is to build 10% extra time into the project plan for this activity (if the coding is estimated at 200 hours, build 20 hours in for this activity). By doing this, you can expect a 30% decrease in QA time because you will minimize re-work, so the effort is worth the investment.

Habit 2 - Begin with the End in Mind
Your end goal for a software project should be to deliver high quality software that meets the needs of the client using reusable and maintainable code. Before coding begins, you should make a list of success criteria that you judge the project on.

For example, your success criteria may be that the software produces specific results, has no known defects (or a small number of low severity defects), is reusable, is maintainable, is well documented, is easy to use, etc. By defining the success criteria up front, you can objectively evaluate whether the project met the criteria or not. Solicit help from all team members (project managers, product managers, testers, automation engineers, other developers, documentation specialists, etc.) when defining the success criteria. By getting a team perspective of the success criteria, you will have better and more measurable criteria and you will get much better buy-in from the team.

Habit 3 - Put First Things First
Prioritizing your work effort is critical. You must apply effort to the most important things first, followed by less important things. For example, everyone will generally agree that creating reusable and easily maintainable code is important. However, in an effort to do this, developers have a tendency to "gold plate". "Gold plating" is when a developer adds bells and whistles to the feature that were not asked for and can easily increase the complexity and estimated hours needed to deliver the work. Be very careful with this.

It is great to create reusable code, but it does not have to handle every future scenario that you can dream up. Instead, stick with the stated features needed but organize the code in a way that makes it easy to extend and improve in future releases. As you develop the code, do team code reviews to identify how to better reuse code, to spot troubled code and to reorganize for maximum maintainability.

Habit 4 - Think Win/Win
In many organizations, development and testing teams play a blame game and create tension between the teams. This can be very disruptive and can greatly affect the quality of the software project and the user experience. The development and testing teams should have a common goal -- to ensure that the client receives the software with the highest of quality. If this is a unilateral goal of the team, it makes sense for all team members to provide help and encouragement to each other so that when the software is shipped with high quality and the client is happy, everyone on the team basks in the joy of a happy client. If you want to encourage an environment of trust, respect and foster an win/win team, here are a few tips:

Share Knowledge - Don't hold your knowledge to yourself, share it with others.
Socialize - Eat lunch with members in different roles in your company. Learn more about them, take a general interest in their hobbies and personal goals.
Encourage Others - Offer congratulations and compliments to team members that you see are doing a great job. Tell your (and their) manager how well you think they are doing. Tell them how much you appreciate their efforts.
Help Struggling Team Members - If you see team members struggling, jump in and offer to help. If you offer, follow through and ensure they get the help they need. You may need help in the future so offering help can foster a win/win relationship for you in the future.

Habit 5 - Seek First to Understand, Then to be Understood
Many of us have a bad habit of blocking out a conversation and not listening because we so desperately want our opinion to be heard. Every developer and team member has a different experiences, different perspectives and motivations. Before you can solve any problem, it is important to first listen intently and diligently to fully understand the problem. Once you feel you have all the facts, solicit ideas for multiple solutions. Having several options can provide better discussions and allows team members to tweak initial solutions into solutions that are more far reaching and solve the problem in a more direct way. If you disagree with an approach, don't attack the person that offered the approach. Instead, explain based on your past experiences why you think there might be a better approach.

To get started with this, schedule time weekly for code reviews. Code reviews allow people with different experiences and skill levels to objectively evaluate your coding structure and style and make recommendations for maximum reuse and maintainability. You also will learn a lot in the process and allow yourself to approach challenges in a different way.

Habit 6 - Synergize
Team collaboration is the key to a synergized team. A synergized team is made up of divergent team members that have different strengths, different backgrounds and different perspectives. Encourage these differences but provide your team with tools that allow you maximize their effectiveness. Highly collaborative teams communicate with each other by sharing their calendars, posting their statuses into discussion forums so that everyone is aware of what the other is doing and accomplishing. These teams keep track of all tasks they work on each day, the number of hours worked, the number of hours remaining and variances to plan. They also share documents that illustrate best practices and produce white papers that teach others what they have learned.

Habit 7 - Sharpen the Saw
Productive developers see the need to continue honing their skills and love learning new techniques, best practices and approaches. They have a thirst for knowledge, reading every development book they can get their hands on. They also know when to have fun. They recharge their batteries by taking great vacations and by having outside hobbies and activities. Here are a few of our favorite development books:

Agile Project Management with Scrum - by Ken Schwaber, Microsoft Press
The Enterprise and Scrum - by Ken Schwaber, Microsoft Press
Code Complete - by Steve McConnell, Microsoft Press
Rapid Application Development, by Steve McConnell, Microsoft Press

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner - http://www.SoftwarePlanner.com
Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Agile Training - http://www.PragmaticSW.com/Services.asp
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

The Seven Habits of Highly Effective Testers

2009-12-21T16:27:00.003-07:00

Be Proactive
Begin with the End in Mind
Put First Things First
Think Win/Win
Seek First to Understand, Then to be Understood
Synergize
Sharpen the Saw

Habit 1 - Be Proactive
A tester's goal in any software project is to ensure that the software is delivered with high quality. When software projects fail due to poor quality, you can either be proactive or reactive when analyzing what caused it. If you are reactive, you will blame other people and circumstances for problems or obstacles. If you are proactive, you will take responsibility for the failure and find ways to correct it in future projects. Upon completion of every project, your team should do a "post mortem" or "retrospective" where you openly discuss things that were done successfully in the project and things that were done poorly. Below are some ideas for being proactive on future projects:

Be Responsible for Great Requirements - Don't blame others for poor requirements. Instead, work with the team to fully analyze the requirements to ensure they are complete, accurate and testable.
Analyze Traceability - Creating a traceability matrix of test cases for each requirement allows you to analyze the test cases for coverage, testability, and completeness. Proactively hold team meetings to review your test cases to ensure you have fully understood the requirement and have adequate test coverage. Post your test cases for the development team to review before coding begins, this will reduce rework and QA time.
Communicate Effectively - During testing, it is imperative that everyone knows the status of the testing effort. Communicate daily status via email or a discussion forum. Include metrics like defect counts, requirement coverage, number of test cases run, passed, failed, and awaiting run, etc.
Describe Defects Effectively - When creating defects, spend time creating a good defect description, steps to reproduce and expected results. Include screen shots and as much information as needed to fully reproduce the issue. This will reduce QA rework.

Habit 2 - Begin with the End in Mind
Your end goal for a software project should be to deliver high quality software that meets the needs of the client. Before coding begins, you should make a list of success criteria that you judge the project on. For example, your success criteria may be that the software produces specific results, has no known defects (or a small number of low severity defects), is well documented, is easy to use, etc. By defining the success criteria up front, you can objectively evaluate whether the project met the criteria or not. Solicit help from all team members (project managers, product managers, testers, automation engineers, developers, documentation specialists, etc.) when defining the success criteria. By getting a team perspective of the success criteria, you will have better and more measurable criteria and you will get much better buy-in from the team.

Habit 3 - Put First Things First
Prioritizing your work effort is critical. You must apply effort to the most important things first, followed by less important things. For example, everyone agrees that negative testing is important to ensure that software gracefully handles scenarios where the user tries things that are not normally done and it was not designed to do. But when stacked up against positive testing, negative testing is definitely less important. So begin your testing effort by testing the software to ensure it works as designed and test it vigorously for this. Once that effort has been completed, then perform your negative testing (testing bounds, invalid data entry, overflow, injection, etc.).

Habit 4 - Think Win/Win
In many organizations, development and testing teams play a blame game and create tension between the teams. This can be very disruptive and can greatly affect the quality of the software project and the user experience. The development and testing teams should have a common goal -- to ensure that the client receives the software with the highest of quality. If this is a unilateral goal of the team, it makes sense for all team members to provide help and encouragement to each other so that when the software is shipped with high quality and the client is happy, everyone on the team basks in the joy of a happy client. If you want to encourage an environment of trust, respect and foster an win/win team, here are a few tips:

Share Knowledge - Don't hold your knowledge to yourself, share it with others.
Socialize - Eat lunch with members in different roles in your company. Learn more about them, take a general interest in their hobbies and personal goals.
Encourage Others - Offer congratulations and compliments to team members that you see are doing a great job. Tell your (and their) manager how well you think they are doing. Tell them how much you appreciate their efforts.
Help Struggling Team Members - If you see team members struggling, jump in and offer to help. If you offer, follow through and ensure they get the help they need. You may need help in the future so offering help can foster a win/win relationship for you in the future.

Habit 6 - Synergize
Team collaboration is the key to a synergized team. A synergized team is made up of divergent team members that have different strengths, different backgrounds and different perspectives. Encourage these differences but provide your team with tools that allow you maximize their effectiveness. Highly collaborative teams communicate with each other by sharing their calendars, posting their statuses into discussion forums so that everyone is aware of what the other is doing and accomplishing. These teams keep track of all tasks they work on each day, the number of hours worked, the number of hours remaining and variances to plan. They also share documents that illustrate best practices and produce white papers that teach others what they have learned.

Habit 7 - Sharpen the Saw
Productive testers see the need to continue honing their skills and love learning new techniques, best practices and approaches. They have a thirst for knowledge, reading every testing book they can get their hands on. They learn how to make their jobs easier -- by automating test cases and applying best practices that reduce QA time and increase software quality. They stay in touch with the testing community by visiting testing sites like Sticky Minds, QA Guild and others. They also know when to have fun. They recharge their batteries by taking great vacations and by having outside hobbies and activities.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

Software Planner - http://www.SoftwarePlanner.com
Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Agile Training - http://www.PragmaticSW.com/Services.asp
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

Enabling Team Collaboration with Discussion Forums

2009-12-21T16:20:00.002-07:00

Teams keen on improving team communication and collaboration can utilize discussion forums to ensure all team members are communicated with. This newsletter discusses:

Improving requirements via discussion forums
Improving coding via discussion forums
Documenting retrospectives via discussion forums
Where to find discussion forum tools

Improving Requirements via Discussion Forums
Software projects can be completed more quickly by collecting solid requirements because re-work can be minimized. A key to collecting solid requirements is to have all stakeholder review the requirements. Stakeholders includes product management, project management, programming and quality assurance team members. Once a requirement is created and ready for review, use discussion forums to communicate this to the stakeholders.

As the stakeholders review the requirement, they can post their comments, questions, and concerns via the discussion forum. Things stakeholders should look for when reviewing requirements are completeness, correctness, adherence to your existing architecture, and testability. By keeping these discussions in a discussion forum, everyone is involved in the discussions and a complete history of questions, issues and answers are documented for later review. Below is an example of someone asking a clarifying question about a requirement and another team member providing guidance:

Improving Coding via Discussion Forums
When in the coding phase, it is wise to create a discussion forum for the release you are working on. Teams can use discussion forums to ask clarifying questions regarding requirements and test cases. Teams can also post a brief summary each day with their status. This can include a short description of code modules affected in each day's coding effort, defects fixed, etc. Below is an example that shows that the developer is posting his status for the day, identifying code modules changed and defects fixed:

Documenting Retrospectives via Discussion Forums
Once a software project is completed, it is important to document what went right and what went wrong with the project -- this is called a retrospective. Below is an example of a retrospective that was posted via a discussion forum:

Where to find Discussion Forum Tools
The screen shots above were from Software Planner (http://www.SoftwarePlanner.com). If you would like to see how Software Planner's discussion forum tool works, navigate to http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=DiscussionBoard. If you wish to find free discussion forums, here are a few:

1. Google Groups - http://groups.google.com
2. Yuku - http://www.yuku.com
3. My Free Forum - http://www.myfreeforum.org

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com
Agile Training - http://www.PragmaticSW.com/Services.asp

Automating Your Regression Test Cases

2009-12-21T16:11:00.002-07:00

Companies that develop and maintain software can dramatically improve the quality of their software releases by creating regression test cases that ensure that existing features are not broken with new releases. This newsletter discusses:

How to create regression test cases
When to automate regression test cases
Best practices for automation analysis

Creating Regression Test Cases
Once a software product has been released to production, each new release of
the software could cause existing features to fail. To prevent this, it is wise to create a set of regression test cases that are run with each new release. Below are some best practices when developing a regression suite:

Categorize by Functional Area – Your software product most likely has different sets of functional areas (e.g. Invoicing, Billing, etc). When creating regression test cases, categorize them by functional area so that you can ensure you have good test coverage for each functional area of your software.
Regression Test Case Design – Regression test cases do not normally need to test bounds, invalid data entry, etc – normally they will be designed to test the software the way it is designed to work. The reason for this is that when the feature was originally designed, it should have been thoroughly tested for bounds, invalid data, etc. An exception to this is if you find that new releases tend to break existing features from a validation perspective. If this is the case, keep some specialized regression test cases to ensure that the validations are still in place.
Revisit the Regression Set with each New Release – Upon implementing a new release of your software, it is wise to recognize new features shipped with the new release and to create a new set of regression test cases that test the new features. If you do not revisit your regression test cases with each new release of your software, the regression test cases will become stale and out dated.

When to Automate Regression Test Cases
Many companies run their regression test cases manually, so when does it make sense to begin automating your regression test cases? It makes sense to automate your test cases when you can no longer run the regression test cases on each build created. For example, if you are doing daily or weekly builds of your code to quality assurance and you cannot quickly run your regression test cases with each build, it is time to consider automating them.

To automate test cases, you must purchase an automated testing tool. There are many great tools on the market, including Automated QA Test Complete (http://www.TestComplete.com), HP Quick Test Pro, HP Win Runner, Rational Robot and Rational Functional Test, just to name a few. We normally recommend Automated QA Test Complete, as it is competitively priced and has similar features as the others. Once you have purchased an automated tool, you can use the tool to create your regression test cases.

How does Automation Work?
Each test case becomes a script. Many tools have record and playback features where you can turn the recorder on, open your software and perform the actions for a test scenario, then save the recording. This is a great way to learn the scripting engine, but it is not usually adequate to create well designed automated test scripts. Normally, you will want to have a technically minded software quality engineer in your organization that creates and maintains the automated scripts, as using these tools require knowledge of the tool, programming skills and great trouble shooting skills.

If you are initially creating your automation strategy, it is wise to consult with an automation expert to ensure best practices for your automation design. There are many companies that specialize in this; we have worked extensively with Star‐QA (http://www.star-qa.com) with great results.

Contracting with an automation expert can save effort and costs in the long term, as they will normally work with you to provide an automation framework that will be reusable and can provide training to your software quality engineer(s), allowing them to make great strides with their automation skill set in very little time. Another advantage of working with an automation expert is that they can implement "keyword driven automation". This simply means that they can create a set of re-usable automation scripts that can be invoked by name (Login, AddOrder, AddtoCart, etc), allowing less technical team members to create new sets of automated scripts.

Best Practices for Automation Analysis
Once your regression test cases are automated, they should be automatically run upon new builds of your software. If you can do daily builds of your software into your quality assurance environment, this is ideal. Once the automation is running daily, you will need a way to quickly determine how many automation test cases were run, how many passed and how many failed.

For failed tests, you will want to drill into the detailed logs to determine what caused the failure. Software Planner (http://www.SoftwarePlanner.com) is an ALM tool that can manage this process. Software Planner integrates with all the major automated testing tools including Automated QA Test Complete, HP Quick Test Pro, HP Win Runner, Rational Robot, and Rational Functional Test. By integrating automated testing into Software Planner, you can launch the tests from within Software Planner, create test sets, analyze the results (which tests passed or failed), and automatically send emails upon test completion. You can also trend these results using graphical dashboards. Below is an example of a dashboard that shows trending of your automation runs:

As you can see from the graph above, the past 2 days (Oct 10/11) has introduced a problem in the code because 19 automated test cases failed while 17 passed. Looking at the graph, you can see that the the issue was introduced on Oct 9, as all test cases passed from Oct 2 - Oct 6. This type of information is invaluable for quality assurance teams.

Summary
As we have seen, automating your regression test cases can be valuable. You should see a return on investment within one release of your software after implementing an automation test strategy. This will be achieved by:

Quicker Releases – By having your regression test cases run automatically, your software quality team can concentrate on testing new features of your software and less time regressing existing features.
Higher quality releases – Your software releases will have fewer bugs and require less customer support because they will be of higher quality.
Happier Customers – Your customers will be happier and more willing to serve as testimonials for future prospects.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com
Agile Training - http://www.PragmaticSW.com/Services.asp

Agile Scrum - Tailoring Scrum to Your Needs

2009-12-21T16:05:00.004-07:00

This newsletter is the final one in a series of newsletters that discusses the Agile Scrum process and ends with tailoring Scrum in a way that improves your individual software releases. Here are the prior newsletters in this series:

Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm
Apr 2008: Agile Scrum - Understanding Scrum Rules http://www.pragmaticsw.com/newsletters/Newsletter_2008_04_SP.htm
May 2008: Agile Scrum - Scrum Kickoff and Product Backlog http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm
Jun 2008: Agile Scrum - The 30 day Sprint and the Daily Scrum Meeting http://www.pragmaticsw.com/newsletters/Newsletter_2008_06_SP.htm
Jul 2008: Agile Scrum - Reporting and Metrics http://www.pragmaticsw.com/newsletters/Newsletter_2008_07_SP.htm
Jul 2008: Agile Scrum - Retrospectives http://www.pragmaticsw.com/newsletters/Newsletter_2008_08_SP.htm

Overview
As you have read in our prior newsletters, Scum offers a very efficient way of delivering software releases. However, Scrum in it's purest version, may not meet your needs exactly. Never feel afraid to take the Scrum methodology and make it your own by customizing it or tweaking it to meet the needs of your team.

6 Ways we have Tailored Scrum to our Needs
Below are ways we have tailored it to meet our needs, this may trigger ideas for your team to use when tweaking Scrum for your team:

30 Day Sprints - In the purest of Scrum, the 30 day sprints are 30 calendar days. We found because of holidays and workload, 30 calendar days did not work well for us. So we changed this to be 30 working days, then we added 10 more working days to the sprint for final quality assurance (bug fixes, final design/rework changes, etc.) before moving to beta or production, so our entire sprint becomes 40 working days.
Software Quality Engineer - In the purest of Scrum, a team is made up of the Product Owner, Scrum Master, and the Team. The team is comprised of programmers that perform coding, testing, and documentation. In our experience, programmers do not make the best testers, so we have included another team role called the Software Quality Engineer, and this engineer is responsible for creating test cases, reviewing them with the team, and performing regression testing (automated if possible).
Documentation Specialist - As mentioned earlier, programmers are not the best documentation specialists, so we also included another team role called the Documentation Specialist. This person is responsible for updating user guides, marketing materials, training guides, help guides and movies.
User Stories - In Scrum, User Stories are the requirements. User Stories are written on 3x5 index cards and provide minimal information about the requirement and are awarded story points. Story points are just a way of estimating the user story as to its difficulty. We found that User Stories just did not provide enough information to provide a good test plan. Therefore, we create a requirements document (called a Work Order) that explains the feature in detail, contains a prototype of the feature (if applicable), and provides estimated hours to complete the work order. This allows our software testing engineer to create a better set of test cases (with great traceability) and allows our developers to code the requirement to specification. For an example of a Work Order document, see this: http://www.pragmaticsw.com/Template_WorkOrder.doc.
Publishing Test Cases Prior to Coding - In a traditional Waterfall environment, the test engineers develop test cases as coding is progressing and then they run the test cases once all functionality is coded and is ready for testing. In this scenario, the programmer does not have visibility to what test cases are going to be run until all coding is complete. In our experience, this approach causes a 30% longer quality assurance cycle because many of the test cases fail due to the programmer not being aware of the scope of testing. When test cases fail, it takes iterations of re-work to get them fixed. Our approach is to have the test engineer publish all test cases BEFORE coding begins and we REQUIRE the programmer to fully read and understand the test set before they begin coding. This fuels them to code the logic in way that will ensure the test cases pass. Once the coding is done, we also REQUIRE the programmer to run each test case and ensure all pass before moving marking them ready for quality assurance testing. The software test engineer will also run the test cases again to ensure they pass, but can spend a lot more time doing exploratory testing and ensuring a higher quality product. Many people think this will add time to the programmer's tasks because they have to run and fix tests during coding. This is true, but from our experience, it only adds about 10% more to their timeline, saving a overall quality assurance timeline of 20%.
Automated Testing - Although Scrum does encourage automated testing, we believe if you have not started any automated testing, it is best to start your automation on your regression test cases, as those will need to be run daily to ensure you are not breaking existing features. We still find creating and running manual test cases for new functionality is critical, as a human can have a deeper test and can physically review the results in detail. For more information on test automation, see this document: http://www.pragmaticsw.com/WhitePaper_TestCase_Automation.pdf.

Summary
Never feel afraid to take the Scrum methodology and make it your own by customizing it or tweaking it to meet the needs of your team and always continue to make it better via input received during your retrospectives.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com
Agile Training - http://www.PragmaticSW.com/Services.asp

Agile Scrum - Retrospectives

2009-12-21T15:52:00.002-07:00

This newsletter is one in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases. Here are the prior newsletters in this series:

Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm
Apr 2008: Agile Scrum - Understanding Scrum Rules http://www.pragmaticsw.com/newsletters/Newsletter_2008_04_SP.htm
May 2008: Agile Scrum - Scrum Kickoff and Product Backlog http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm
Jun 2008: Agile Scrum - The 30 day Sprint and the Daily Scrum Meeting http://www.pragmaticsw.com/newsletters/Newsletter_2008_06_SP.htm
Jul 2008: Agile Scrum - Reporting and Metrics http://www.pragmaticsw.com/newsletters/Newsletter_2008_07_SP.htm

Overview

Few Agile sprints go exactly as planned. Many sprints encounter problems that must be corrected and some go smoother than planned. Regardless of how successful or disastrous a sprint is, it is important to review the sprint in detail once it is over. This allows your team to figure out what things were done well and to document the things that need improvement. It also aids in building a knowledge base that teams coming behind you can review to ensure they get the most out of their upcoming projects. The key to future successful sprints is to learn from past mistakes. The process of formally reviewing your sprint is called a Retrospective.

5 Steps for Conducting Retrospectives
Below are the steps for conducting successful Retrospectives:

Plan Your Retrospective - Upon completion of a sprint, the team should conduct a Retrospective. This is where the Scrum Master invites all the major players of the team (Product Owner, Team Members, Software Quality Engineers, etc.) to a meeting to review the successes and failures of the sprint.
Require Team Participation - Ask the attendees to bring a list of 2 items that were done well during the sprint and 2 things that could be improved upon.
Hold the Retrospective Meeting - Go around the table and have each person to discuss the 4 items they brought to the meeting. Keep track of how many duplicate items you get from each team member. At the end of the round table discussion of items, you should have a count of the most common items that were done well and the most agreed upon items that need improvement. Discuss the top success items and the top items that need improvement.
List Items Done Well and Things Needing Improvement - Upon listing of the success and improvement items, discuss specific things that can be done to avoid the items that need improvement upon the next release. If some items need more investigation, assign specific individuals to finding solutions.
Create a Retrospective Report - The best way to keep this information organized is to create a "Retrospective" report, where you document your findings. Send the Retrospective report to all team members. Before team members embark on their next sprint, make sure they review the Retrospective report from the prior project to gain insight from the prior project. We created a template that you can use for the document, download it here: http://www.pragmaticsw.com/Template_Retrospective.doc.

Our Experience with Retrospectives
Agile is an iterative process and if your team makes use of Retrospectives, they will continually improve their Agile process. We have found this to be true in our own organization, below are the results of the first few Retrospectives we conducted:

Sprint 1 Retrospective
Our first sprint did not result in a releasable piece of software because we had too many items that were not fully completed by the end of the sprint. When we conducted our Retrospective, we had these recommendations of items to improve:

Better Requirements - We started by utilizing User Stories for analysis and found that User Stories did not provide enough detail and caused too much re-work. So we replaced User Stories with a more detailed requirement document called a Work Order, here is an example: http://www.pragmaticsw.com/Template_WorkOrder.doc. We also found that providing estimates (in number of hours) and tracking hours remaining was more efficient, objective and reliable than using Story Points, so we changed our measurements from Story Points to hours.
Test Case Development - In the first sprint, we had our software quality engineers create test cases for each requirement, but we did not share those test cases with the programmer. Once the code was moved to quality assurance, we found a lot of re-work because many of the test cases failed. So we decided for the next sprint we would have the software quality engineers define all test cases before coding began and we required the programmer review the test cases before coding began. Upon finishing the code, the programmer was required to run all established test cases. We found in Sprint 2 that this simple suggestion reduced quality assurance time by 30% and improved quality.

Sprint 2 Retrospective
By implementing better requirements and by reducing our quality assurance time, ur second sprint went much better and we released the new software into Beta. However, our team members had to work too many hours to get the sprint completed, so when we conducted our Retrospective for Sprint 2, we had these recommendations of items to improve:

Better Estimates - We ran reports that showed that our estimates were about 12% underestimated in Sprint 2. To fix this, we decided to add a 15% estimate buffer to our next sprint and allocated team members to 7 hour days instead of 8 hour days (to account for meetings and planning).
Leadership Oversight - We reduced the workload of our lead programmer to ensure he had time to provide leadership for code inspections, code refactoring and general team leadership.
Regression Automation - In Sprint 1 and 2, our regression test cases were run manually and it took about 2.5 full days to fully regress the existing features. Due to this, we could only afford to do full regression testing about twice during the sprint. To resolve this, we decided to invest in an automated testing tool and to create a set of automated regression test cases that could be run each time we did a new build of the software (daily). You can learn more here: http://www.pragmaticsw.com/WhitePaper_TestCase_Automation.pdf.

Summary

The Retrospectives from the two prior sprints identified critical issues that needed to be addressed and allowed us to finish our third sprint with more functionality than was originally planned and with higher quality than our prior sprints.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com
Agile Training - http://www.PragmaticSW.comServices.asp

Agile Scrum - Reporting and Metrics

2009-12-21T15:33:00.002-07:00

Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm
Apr 2008: Agile Scrum - Understanding Scrum Rules http://www.pragmaticsw.com/newsletters/Newsletter_2008_04_SP.htm
May 2008: Agile Scrum - Scrum Kickoff and Product Backlog http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm
Jun 2008: Agile Scrum - The 30 day Sprint and the Daily Scrum Meeting http://www.pragmaticsw.com/newsletters/Newsletter_2008_06_SP.htm

Overview
From a metrics perspective in Agile, you will want to collect metrics that answer 2 questions:

Will all my sprint requirements get completed by the end of the sprint? To answer this, we will use burn down charts that show the number of hours remaining each day of the sprint. As the sprint progresses, the chart should incrementally trend downwards, showing whether you will be done with all requirements at the end of the sprint.
Will all requirements completed in the sprint have high quality? To answer this, we will use test cases and defect statistics. Test Case statistics will let us know if we have thoroughly tested the software and defect statistics will alert us as to the quality of the software.

When collecting statistics and metrics, you can use spreadsheets or an Application Lifecycle Management (ALM) tool to generate the information needed to answer these critical questions. Using a spreadsheet is less costly (no purchase of a tool required) but it does require that you key your data into the spreadsheet daily and keep it updated. ALM tools can prevent double data entry and can provide a more comprehensive statistics and a better view of your progress.

Using a Spreadsheet to Capture Metrics
For companies that do not have a budget for an ALM tool, they can collect statistics at enter them into a spreadsheet. The most difficult issue with this approach is that you must keep the spreadsheet updated and you must have a way of collecting the statistics. For example, each day you must ask each developer how many hours they have remaining on each task they are working on. You also must manually keep track of the number of test cases, the status of them, the number of defects and the status of them.

Below is an example of a spreadsheet that shows a burn down chart of each requirement and it charts how many hours should be remaining day-by-day and the actual hours remaining day by day. By reviewing the chart daily, you can determine if you are progressing towards plan or not.If you would like to download the spreadsheet above, go to http://www.pragmaticsw.com/Template_PADDailyScrum.xls

Using an Application Management Tool to Capture Metrics
The advantage of having an ALM tool to provide statistics is that you do not have to ask your developers each day for their hours remaining -- they will enter their time in the ALM tool daily and it will automatically update the statistics. Your quality assurance team can also use the tool to manage requirements, test cases and defects, and statistics will always be a click away -- no need to do any double data entry. There are many ALM tools available, below are some screen shots that show how Software Planner (http://www.SoftwarePlanner.com) generates statistics that provide the metrics needed for Agile sprints.

Burn Down Charts
As you can see below, burn down charts are available without double entry of data -- it pulls from the timesheets entered each day by your developers. A key advantage is that you can easily toggle between sprints, comparing one to another.

Quality Assurance Analysis
You can quickly see how many test cases are run for each sprint, and how many passed and failed, day-by-day. You can also trend defects day-by-day to ensure that as the end of the sprint approaches, the quality of the release is high. Another key advantage is that it does allow you to quickly toggle between sprints, comparing one to another:

If you would like to download a free trial of Software Planner, go to: http://www.softwareplanner.com/FreeTrial.asp?AppName=SP

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com
Agile Training - http://www.PragmaticSW.com/Services.asp

Agile Scrum - The 30 Day Sprint and The Daily Scrum Meeting

2009-12-21T15:27:00.002-07:00

Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm
Apr 2008: Agile Scrum - Understanding Scrum Rules http://www.pragmaticsw.com/newsletters/Newsletter_2008_04_SP.htm
May 2008: Agile Scrum - Scrum Kickoff and Product Backlog http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm

30-Day Sprints
Agile differs from standard Waterfall development in that development has a smaller timeframe with a smaller feature set. Agile Scrum implements releases every 30 days (called 30 day sprints). In the purest implementation of Scrum, the 30 days is 30 calendar days. We have found that 30 working days works best.Upon completing a sprint, you can move the software to production (if production-ready) or move into another 30 day sprint to implement additional features.

At the conclusion of the PAD Planning Week, you should have a set of detailed requirements and estimates and the Scrum Master can create a project plan that contains each feature (represented by a work order) and the individual assignments. The items that appear in the project plan for the sprint are referred to the Sprint Backlog.

Each feature should have a priority and should be worked in priority order so that if the team falls behind, you can ensure the highest priority items make it into the sprint. Features not completed at the end of the sprint will be reprioritized for possible inclusion in the next sprint.

Best Practices for 30-Day Sprints

Create Test Cases before Coding Begins
As each feature is detailed, it is important to create a set of test cases before coding begins. Developers should always run all the established test cases before making the feature available to the Software Quality Engineer(s) for testing. This approach will drastically reduce defect count and significantly speed up the quality assurance testing.

Daily Code Builds
Each day, each team member should check their code into their source control system if their code is compilable (never check in code that is not compilable). If SQL script changes were made, these also need to be checked into the source control system. It is wise to utilize an automated build tool that can run at the end of day and will do a GET on all source code and SQL Script changes that were made. It can compile the code into DLLs and run the SQL scripts to upgrade your database. This allows you to have a new build on your quality assurance server daily so that your Software Quality Engineer(s) can test new features and run regression when needed. There are a number of tools available for automatic builds, a popular one is called Automated Build Studio by Automated QA (see it at http://www.automatedqa.com)

Code Inspection
It is important to know that code should not be considered complete until it is fully coded, fully unit tested, all established test cases have been run, code has been refactored (if needed), and technical documentation is written (when needed). Upon indication that code is complete for a feature, the team should do a code inspection by reviewing the code in the source control system related to the feature. The code review should look for standards adherence, identification of logic errors or performance problems, and reusability. If the code inspection finds failures, defects should be created and assigned -- allowing the developer to fix the issues before the code is tested by the Software Quality Engineer(s).

Daily Hours Entry
Each day, every team member should log the hours they worked on each task during that day. When logging time, it is important to enter the percentage complete or estimated remaining hours (this is the preferred method). By entering the estimated remaining hours for each task worked on, your team will know how many hours remain for all tasks and can determine if you are progressing on a pace to finish the sprint with all the desired features. From a metrics perspective, inspect burn down charts daily. A burn down chart is simply a chart that shows day-by-day the number of estimated hours, actual hours and estimated hours remaining. As the sprint progresses, you should see the estimated hours trend downwards and it should be on pace so all the committed work is accomplished in the sprint.

Daily Scrum Meeting
Each day, your team should hold a Daily Scrum Meeting. In the purest version of Scrum, this daily meeting is restricted to 15 minutes and each team member is asked 3 questions:

1. “What did you do yesterday?”
2. “What will you do today?”
3. “Are there any roadblocks or anything impeding your progress?”

In our experience, 15 minutes is not always enough time to have a good dialog and a meaningful meeting. Many days we will complete this in 15 minutes, but most often it takes about 30 to 45 minutes. To speed this up, we have each team member post a summary of what they did yesterday and a summary of what they plan to do tomorrow in a daily discussion forum that is automatically distributed to all team members (see example below). This allows you to spend the Daily Scrum meeting talking about roadblocks, design decisions, and impediments to progress.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com
Agile Training - http://www.PragmaticSW.com/Services.asp

Agile Scrum - Scrum Kickoff and Product Backlog

2009-12-21T15:09:00.007-07:00

Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm
Apr 2008: Agile Scrum - Understanding Scrum Rules http://www.pragmaticsw.com/newsletters/Newsletter_2008_04_SP.htm

30 Day Sprints
Agile differs from standard Waterfall development in that development has a smaller timeframe with a smaller feature set. Agile Scrum implements releases every 30 days (called 30 day sprints). Upon completing a sprint, you can move the software to production (if production-ready) or move into another 30 day sprint to implement additional features.

Pragmatic Agile Development (PAD) and Agile Scrum It is important to note that the way we use Agile Scrum varies from a purist version of Scrum as we have made modifications to Agile Scrum to work well for our development environment. Our version of Scrum is called Pragmatic Agile Development (PAD) and differs from a more purist Scrum implementation in these ways:

Scrum Planning - In Scrum, planning for an upcoming sprint is accomplished in 1 day, in PAD the planning spans 1 week. This is because we write more detailed specifications than a purist Scrum does (see next bullet item).

User Stories vs. Specifications - In Scrum, requirements are written on index cards (called User Stories) and does not contain prototypes or detailed explanations of the feature set. In PAD, we spend time detailing the requirement specifications with prototypes to ensure that time is well spent on the feature, reducing rework.

30 Day Sprints - In Scrum, development is done in 30 calendar days. In PAD, development is done in 30 working days, skipping holidays. This provides us with more evenly distributed sprints.

Team Composition - In Scrum, developers are expected to perform all duties (analysis, design, coding, test case development, execution, and documentation). In PAD, developers help with analysis and design and perform all the coding. We have specialized team members (Software Quality Engineers) for test case development and specialized team members for documentation. We do this because our experience has shown that we need specialists in these areas.

The goal of software development is to deliver your software quickly and with high quality, so tweaking a methodology to meet your needs makes sense.

Product Backlog
As your existing clients request new features or as you come up with new features that make the product more marketable, these items are called the Product Backlog. In the PAD Scrum Planning week, you will set the goal for the sprint and prioritize product backlog items to determine which ones can fit within the sprint.

Scrum Kickoff and Planning Week
In the purest version of Scrum, you have only 1 planning day for the sprint and requirements are written on index cards (called User Stories). We believe this is not enough time or detail to deliver quality features, as we have shown that taking the time to fully detail the feature saves time once the client (or your internal team) receives the features, it takes less re-work. So you should devote a week to planning.

Each release (or sprint) will begin with a PAD Planning Week. The first day of the PAD Planning week will begin with defining the goal for the sprint and identifying features you wish to have in the release (from the product backlog), in priority order.

In the purest version of Scrum, releases are done in 30-day sprints. The 30 days are calendar days, so with holidays and weekends, this may equate to 19 to 23 working days. We have found that sprints are best implemented in 30 working day sprints (excluding holidays), as this provides more evenly distributed sprints. The 30-day sprint begins after the PAD Planning week concludes.

During the first day of the PAD Planning Week, each team member will identify the number of hours they can contribute to the sprint, allowing you to determine the maximum velocity for the sprint (velocity simply means the number of hours that can be worked in the sprint). By knowing the maximum velocity, you can determine what features will fit in the sprint. After the high level features are identified in the first day of PAD Planning, you will assign specific work order numbers to each high level feature and assign a set of work orders to each team member.

The team members will spend the week defining the detailed requirements for their assigned work orders. Note: Work Orders are simply a hard copy document of each functional specification.

User Interface Design Guidelines
Because you will have multiple team members creating requirements, it is critical for your team to define your user interface styles in a style guide and ensure all your team members adhere to those standards.

Decomposing Work Orders
Since sprints are limited to 30 working development days, you will be forced to make hard decisions about the features that can fit into the sprint. When you are assigned a work order for a feature of the sprint, you should decompose the feature into multiple work orders so that you can prioritize specific pieces of the feature.

For example, let’s assume that you are redesigning your user interface for a more pleasing look and feel, and the aesthetics are the most important issue for the sprint. You also would like the screens to be more user-friendly, so you have some issues you wish to address (like prompting to save changes when changes are made and they switch between tabs on the screen). In this case, you should decompose these into 2 separate work orders (one for the aesthetics and another for the tab switching). By doing this, it allows you to prioritize the tab switching lower than the aesthetics.

User Stories vs. Work Orders
As mentioned, we favor work orders over a user story. Here is an example of a user story written on an index card:

Here is an example of a work order, notice how much more detail is presented and how having a prototype of the item you are delivering reduces ambiguity of the feature:

If you would like an example of a work order, download one here:

http://www.pragmaticsw.com/Template_WorkOrder.doc. Other templates for the PAD process are available at http://www.pragmaticsw.com/templates.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com
Agile Training - http://www.PragmaticSW.com/Services.asp

Agile Scrum - Understanding Scrum Rules

2009-12-21T15:03:00.009-07:00

Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm

Understanding Scrum Rules
For Agile Scrum to be successful, you must have buy-in from the highest stake holders to the individuals doing the work and every individual must follow the rules. Below are the rules for Scrum:

Obtain Number of Hours Commitment up Front - Before beginning an Agile 30-day sprint, each team member must commit to a certain number of hours for the 30 day sprint.
Gather Requirements / Estimates up Front - The Product Manager will specify the sprint goal and the team will gather the requirements and provide an estimate up front. Once the estimates are done, the requirements are prioritized and only the ones that will fit into the sprint are worked on (based on estimated hours of all tasks vs. hours committed to by team members).
Enter Time Daily - Each person on the team agrees to enter their actual hours and estimated hours remaining EVERY DAY.
Daily Builds - Each programmer will check code in daily or more frequently if possible. The checked in code must be compilable. An automated process will create daily builds to prevent manual merging of code and allowing the Quality Assurance Engineer to test features of the sprint.
No new Requirements for a Sprint - No new requirements can enter into the sprint unless all features of the sprint are completed. Management and other parties that are not directly involved in completing the features for the sprint are not allowed to direct actions of team members on items not included in the sprint. If an emergency feature is required by management, the sprint must be aborted and a new sprint must begin with the new feature set.
Keep the Daily Scrum Meetings Short - Daily Scrum meetings are held to determine what things were done since the last Scrum meeting, what things will be done in the next Scrum meeting and what impediments stand in the way of any person on the team. The Daily Scrum meeting is designed to be completed in 15 minutes. If it takes 30 minutes, this is OK, but it should not extend longer than that without a solid business reason for it. Team members that show up to Daily Scrum meetings late are required to pay the Scrum Master a $1 fine.
Code Inspections are Paramount - Upon completing a particular feature, the programmer should illustrate the feature to the team and show the code that drives the feature. The team should inspect the code for re-usability, cleanness, and adherence to established coding standards.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com
Agile Training - http://www.PragmaticSW.com/Services.asp

Agile Scrum - Team Composition

2009-12-18T14:35:00.005-07:00

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile.

This newsletter is one in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases. Here are the prior newsletters in this series:
Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm

Team Composition
Managing Scrum development requires a major change in how teams work together. In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists. Each team member has specific duties which normally do not normally overlap and they have a specific reporting structure (most team members report to the project manager).
With Scrum, you have just 3 team roles and is normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint. This is normally the Product Manager, CTO, in some cases the CEO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product. Before a sprint begins, the Product Owner communicates the goal of the sprint to the team and what features should be analyzed for the release. This does not mean that all the desired features will make it into the sprint, the team estimates and prioritizes items for the sprint (during the Sprint Planning sessions), and only the items that can fit in the sprint are done.
ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspections happen, and ensuring everyone plays by the rules. The ScrumMaster coordinates and runs the daily sprint meetings. The ScrumMaster is not a task master, they are a leader that empowers the team members to deliver the assigned tasks and to help eliminate roadblocks that slow them down.
The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists. With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation. The Team is responsible for staying focused on assigned tasks, soliciting help as they encounter road blocks, fully testing their code, refactoring code, logging their time daily (including estimated time remaining on each task), and for checking their code daily or more often if possible.

Our Experiences with Team Composition
In our experience, it is unrealistic to assume that The Team can handle quality assurance and documentation well. We have improved the team composition to include 2 additional roles:

Software Quality Engineer - This individual is responsible for the quality of the sprint. In our experience, programmers do not test code with the same mentality as a Software Quality Engineer (SQE). Once specific requirements are defined, the SQE develops a set of test cases (manual or automated) to test each requirement fully. Before coding begins, the test cases are made available to the programmers on the team. The programmers are expected to run each test case before marking coding as being complete. Once a requirement is marked as being complete, the SQE is responsible for running the test cases again to ensure they all pass. The SQE also runs a weekly regression to ensure that legacy features are not compromised by the release. If the SQE has developed automated test cases for regression, those are run daily or more frequently, if needed. The SQE does not wait until the end of the sprint to begin testing, they test once a requirement is completed. By the end of the sprint, all testing has been done and regression has been run frequently.
Documentation Specialist - The Documentation Specialist (DS) is responsible for creating User Guides, Administrator Guides and other training materials. In our experience, programmers do not always have the written communication skills to write documentation in a way that a laymen can interpret it, that is why it is important to have a separate resource for this function. Once a requirement has been fully tested by the SQE, the DS begins the documentation of that requirement. The DS does not wait until the end of the sprint to begin this, the end of the sprint includes all completed documentation.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com

Agile Scrum - An Overview

2009-12-17T16:48:00.002-07:00

Agile Scrum - An Overview
Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile.

This blog is the first in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

So what is Agile?
According to Wikipedia, Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. Simply put, Agile allows your team to identify the most critical features of the software that can be completed within a short time frame (normally 1 to 2 months), and it delivers a complete build with this set of limited features as the first iteration. Once that is done, you can move those features to production or continue on to the next iteration.

By breaking the releases into shorter stints, it allows you to gain quicker releases and to capture return on investment more quickly by putting the working (but limited) features into production sooner. This is in stark contrast to the more traditional "Waterfall" approach, where you design all features upfront, code each one, test each one, then move into production. Agile projects are iteratively released to production months where Waterfall projects normally span a year or more before they are released to production.

So what is Scrum?
Scrum is process of implementing Agile, where features are delivered in 30 day sprints. Scrum borrows its name from Rugby, where a sprint is the process of stopping play, then vigorously playing until the sprint ends and a new one begins. The same idea applies here, where you define the requirements for a 30 day sprint and work on them with vigor for 30 days without being sidetracked by other things or having things re-prioritized. A specific feature is not recognized as being completed until it is analyzed, designed, coded, tested, re-factored and documented. At the end of the 30 day sprint, most features defined in the 30-day sprint should be completed. If some did not get finished (because of being underestimated), the uncompleted features can be moved to a later sprint. A sprint is considered successful if all the completed features have high quality and can be put into production (or beta) upon ending the sprint.

Do Team Member Responsibilities Change?
Managing Scrum development requires a major change in how teams work together. In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists. Each team member has specific duties which normally do not normally overlap and they have a specific reporting structure (most team members report to the project manager).
With Scrum, you have just 3 team roles and is normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint. This is normally the CEO, CTO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product.
ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspection, and ensuring everyone plays by the rules.
The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists. With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation.

So how does Scrum Work on a Day-by-Day Basis?
Scrum begins with an 8 hour Scrum Kickoff Meeting. The Scrum Kickoff meeting is divided into (2) 4 hour segments, where you first determine what features are desired for the 30 day sprint. The last 4 hours are used to provide rough estimates for the items identified for the sprint. If the estimates exceed the available resources, the features are prioritized and less important features are dropped from the sprint. An important component of Scrum is using a time-box approach, where meetings and events have a definite time period (e.g. no more than 8 hours for the kickoff meeting) and this time-box is strictly enforced. Once the features are locked in for the 30-day sprint, no changes are allowed (new features can not be introduced until the next sprint). When estimating features for a sprint, the estimates must include time for analysis, design, coding, testing, re-factoring, and documentation. A feature is not considered complete until all those things are done.

Each day, a Daily Scrum Meeting is held to determine how the features are progressing. The meeting is no longer than 15 minutes, and each team member is asked 3 questions:

What have you accomplished since the last Daily Scrum Meeting?
What will you do before the next Daily Scrum Meeting?
Is there anything that is impeding your progress (and remedies are discussed)?

From a programmer's perspective, Scrum development is a new paradigm which is very empowering but does require them to follow specific rules:

Code is only checked out for the duration needed to complete a feature. No exceptions. Most code will be checked in daily, as most features are broken down into small feature sets.
Time must be entered daily. For each feature, you will have estimated hours, actual hours and hours remaining to complete the feature. This information must be updated at the end of every day so that the ScrumMaster can determine if the release progress is trending as required.
Programmers are not allowed to be pulled off on tangent projects, they must stick to the features they have been assigned for the sprint.
All team members must attend the Daily Scrum Meeting and must be on time.

Code is compiled and deployed to a test server daily. Teams can use automated build tools to speed this process. Automated tests should be run against the daily releases to discover any issues introduced by the release.
Once a Scrum 30 day sprint is completed, all features that were completed can then been moved to a beta or production environment. Following the sprint is a Retrospective (post mortem), where team members discuss and document things that went well and things that can be improved upon in the next sprint.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
Software Planner - http://www.SoftwarePlanner.com