Basics of Test Driven Development (TDD)

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:

1. First fully understand the requirement
2. Create automated test(s) that test the requirement
3. Create the coding logic -- test it by running the automated test(s)
4. Once the automated test(s) pass, the coding then fulfills the requirement
5. 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

Agile Scrum - Tailoring Scrum to Your Needs

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 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:

1. 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.
2. 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).
3. 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.
4. 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.
5. 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%.
6. 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 - Understanding Scrum Rules

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
• 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

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

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:

1. What have you accomplished since the last Daily Scrum Meeting?
2. What will you do before the next Daily Scrum Meeting?
3. 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