The Magazine for Agile Developers and Agile Testers

Testing challenges for distributed team

www.agilerecord.com free digital version made in Germany ISSN 2191-1320

issue 9

February 2012

Pragmatic, Soft Skills Focused, Industry Supported

CAT is no ordinary certification, but a professional journey into the world of Agile. As with any voyage you have to take the first step. You may have some experience with Agile from your current or previous employment or you may be venturing out into the unknown. Either way CAT has been specifically designed to partner and guide you through all aspects of your tour. The focus of the course is to look at how you the tester can make a valuable contribution to these activities even if they are not currently your core abilities. This course assumes that you already know how to be a tester, understand the fundamental testing techniques and testing practices, leading you to transition into an Agile team.

The certification does not simply promote absorption of the theory through academic mediums but encourages you to experiment, in the safe environment of the classroom, through the extensive discussion forums and daily practicals. Over 50% of the initial course is based around practical application of the techniques and methods that you learn, focused on building the skills you already have as a tester. This then prepares you, on returning to your employer, to be Agile. The transition into a Professional Agile Tester team member culminates with on the job assessments, demonstrated abilities in Agile expertise through such forums as presentations at conferences or Special Interest groups and interviews. Did this CATch your eye? If so, please contact us for more details!

Book your training with Daz & Hilterscheid!

Open seminars: 23.04.1227.04.12 in Berlin, Germany
(German tutor and German exam)

05.03.1209.03.12 in Helsinki, Finland 19.03.1223.03.12 in Amsterdam, The Netherlands 11.06.1215.06.12 in Stockholm, Sweden 02.07.1206.07.12 in Orlando, USA

Sergejy Galushko Fotolia.com

Daz & Hilterscheid GmbH / Kurfrstendamm 179 / 10707 Berlin / Germany Tel: +49 30 747628-0 / Fax: +49 30 747628-99 www.diazhilterscheid.de training@diazhilterscheid.de

Editorial
Dear readers, Happy New Year! I wish you and your families health and a pleasant 2012. I hope you had a good party to celebrate the new year. I was home and cooked for my friends and family. We drank some Spanish wine! It was very nice. Back to the real life, we face a big amount of work in front of us. The new year has started quite promising. As a consultancy, we are almost sold out and the conferences are looking quite good. The numbers of attendees for the Belgium Testing Days are higher compared to last year. We expect to have a new record number of attendees. If you havent registered by now, dont miss it. We would love to meet you there. We are also preparing for the Testing & Finance in London. The conference will also be quite agile. The decision to move the conference to the UK seems to have been a good one. We have plenty of requests from exhibitors and sponsors. We are really looking forward to the first conference in the UK with Paul Gerrard and Susan Winsor from Gerrard Consulting Ltd. In the fall we decided to create an editorial board for the magazine to help us raise the bar and also to spread the word about the magazine. We are very happy to count on David Alfaro, Josh Anderson, Fabio Armani, Plamen Balkanski, Andreas Ebbert-Karroum, Pat Guariglia, David Hussman, Ciaran Kennedy, Roy Maines, Darian Rashid, Jos Manuel Beas, Steve Rogalsky, Dave Rooney, Steve Smith, Zuzana Sochova and Declan Whelan. Please have a look at the magazine and website. We will be implementing a new system for the article submission. This will help the editorial board to rate and choose the articles for the magazine. We hope that in that way we will improve the magazine. We are happy with any comment from your side, please dont hesitate to send it to us. Last but not least, we thank the authors, supporters, advertising companies and, of course, all our readers for making this new issue of the Agile Record possible.

Best regards

Jos Daz

www.agilerecord.com

Contents
Editorial 1 Editorial Board 3 Agile Testing in the Real World Training a New Agile Tester 6 by Lisa Crispin Technical Debt and Load Testing 10 by Peter Varhol An agile testing future 13 by Huib Schoots Agile practices for revision control 18 by Carlos Ble Continuous integration to test large distributed systems 22 by va Takcs & Istvn Forgcs Distributed Agile: The Maturity Curve 26 by Raja Bavani Your Perspective, My Perspective and Retrospective Who Wins? 30 by Mithun Kumar S R Why Agile Works 32 by Martin Bauer Scenarios of Agile Success 38 by Alex Adamopoulos Agile methods for (phase-oriented) test managers? 42 by Jessica Schiffmann Experiencing Agile 46 by Bart Fessl Understanding Test Driven Development with Python 50 by Chetan Giridhar & Vishal Kanaujia Lean Startup The Most Extreme Agile Method by Far 53 by Tom and Kai Gilb The Agile Project Manager Fail NOW as a Strategy 56 by Bob Galen Introduction to Scrum An Agile Process 60 by Avnish Tyagi From destruction to construction 64 by Antonio Robres Management of Development Team 68 by Piotr Trojanowski Masthead 72 Picture Credits 72 Index Of Advertisers 72

www.agilerecord.com

Editorial Board
David Alfaro is Certified Scrum Professional and Scrum Master with many years of experience in dedicated Agile (Scrum, Kanban and XP, being TDD a practice of XP), custom tailor coaching for collocated and distributed teams, aspiring Agile Programmers, and ScrumMasters and Product Owners David was the first Costa Rican to get training and successfully implement Scrum in the country. He has been the Scrum promoter in Costa Rica since 2007. He is founder and board member of the Costa Rica Agile User Group. He is a Certified Scrum Professional (recognition awarded only to those that have proven seasoned experience in Scrum implementation and adoption). He is the founder of Prontitud. He is the reference speaker regarding Agile topics in national conferences. Josh Anderson Josh Anderson is an Agile Activist and Coach located in Raleigh, NC. He currently serves as the Director of Engineering at Aprimo|Teradata. Having spent the last decade building and leading effective and efficient software development teams, Josh brings a wealth of experience in areas such as Agile adoption/implementation, team building, leadership development, attracting/hiring/ retaining top-notch technologists, and software architecture. Josh co-hosts a bi-weekly podcast with fellow Agile Methodologist, Bob Galen. Meta-Cast, available at www.meta-cast.com, involves discussions covering Agile/Scrum, team building, management techniques, and various other items that affect everyone involved in software development. Josh can be reached in various ways: Podcast Website: www.meta-cast.com Podcast Twitter: www.twitter.com/@MetaHyphenCast Personal Twitter: www.twitter.com/@nosrednAhsoJ Fabio Armani Plamen Balkanski With over 14 years of experience in IT, I come from software development background and Ive worked in Agile, Scrum/ XP and Kanban/Lean environments. I have been involved in co-organizing events for the Agile South Coast User Group and ScrumFest.org. I am passionate about helping teams, individuals & companies discover how to work better together and how to continue learning while delivering high quality solutions to business problems. Matt Block During my career I have played the role of developer, development manager, and product manager. I have learned what development practices and processes are critical to the success of agile and how to drive that adoption process. I have learned just how critical and how difficult the Product Owner role is in enabling the business to realize the full potential agile can bring. Learn more at http://www.developmentblock.com. Jose Manuel Beas One of the best known agile activists in Spain. Over the last years, as the first president of Agile-Spain (organizers of two main conferences every year) and cofounder of Agilismo.es (promoters of new formulas for training professionals, like coding-dojos or backlog workshops), Jose Manuel Beas had a significant participation in the upgrowth of the Spanish agile community. He is also aware of the importance of sharing experiences, that is why he also writes technical articles in his blog and appears in podcasts, webinars and very different professional events and even has prologued the first TDD book in Spanish. His motto is leave the knowledge where it has to be: among people. He is also helping teams by coaching and mentoring and can be found in http:// jmbeas.es or as @jmbeas in Twitter. Andreas Ebbert-Karroum leads the Agile Software Factory (ASF) at codecentric. For more than four years, he is a certified Scrum Master. Since then he could contribute his competencies in small and large (> 300 persons), internal and external, or local and global projects as developer, scrum master or product

www.agilerecord.com

owner. Meanwhile, hes also a Professional Developer Scrum Trainer, conducting a hands-on training for Scrum team members, which codecentric has developed together with scrum.org and in which he shares with joy the knowledge gained in the ASF. More than 15 years ago, his interest in JavaSE/EE awakened, and it never vanished since then. His focus at codecentric is the continuous improvement of the development process in the Agile Software Factory, where technical, organizational and social possibilities are the challenging, external determining factors. Pat Guariglia is an agile coach for Elegant Agile, Inc. He is certified as a PMP with the Project Management Institute, a Certified Scrum Practitioner (CSP) and Certified Scrum Master (CSM) with the Scrum Alliance. Pat has been leading information technology projects and coaching agile teams for the last twelve years. Pat continues to champion agile practices and Scrum in the Upstate New York and New York City areas. He speaks at conferences, seminars and holds workshops across the Northeast and worldwide. Pat contributes articles to the ScrumAlliance.org web site, is the organizer for the Upstate New York Agile User Group, and participates in the organization and networking of regional northeast US agile groups. David Hussman owns and leads DevJam, coaching and producing products with companies of all sizes around the world. His coaching style is non-dogmatic, challenging and pragmatic. Davids maps tools to contextual needs in a way that seeds self-discovery and avoids the expert trap of simply telling people what they should do. David works within and across each project communities, pairing on coding and testing work, design and redesigning products, and helping leadership teams pragmatically introduce lasting agility that fosters innovation and competitive advantage. When David is not coaching or teaching, he is speaking at conferences around the world and publishing to a variety of sources. His newest publication is Cutting an Agile Groove, a series of instructional videos that cover topics such as coaching, product design and planning to learn. David was given the 2009 Gordon Pask Award for his coaching contributions to the Agile Community at large. Ciaran Kennedy (MSc Technology Management, CSM, CSP) hails from Dublin and has a huge passion for Technology and all things Agile. He founded Scrum Ireland (www. scrum.ie), a leading and free Social Network dedicated to Agile IT professionals across the globe. With many leading companies and individual members including Mike Cohn and Jeff Sutherland, Scrum Ireland is growing fast in

the community. During the day Ciaran runs his own Agile Company, Chillistore Technologies Ltd (www.chillitech.ie) providing Agile Office Services to leading blue chip and high tech innovative start-ups. He also does some part time lecturing on Agile Project Management in his spare time and has been a guest speaker at PMI and Engineer Ireland events. Roy Maines graduated Cum Laude from Chapman University with a BS Degree in Computer Information Systems. With over 30 years experience in the IT Technology field, Mr. Maines has an extensive background in multiple disciplines in Technical Project Management. Mr. Maines is a certified Project Management Professional (PMP), Certified Scrum Master (CSM) and Certified Scrum Professional (CSP). Mr. Maines has broad experience supporting the full SDLC engineering efforts, Test & Evaluation, Formal Information Assurance Certification efforts. Mr. Maines has held various technical and Project Management positions with a number of fortune 500 companies including Microsoft Corp, Perot Systems, Wachovia Bank NA, and Mantech Systems Engineering Corp. Mr. Maines diverse experiences enable systematic analysis and troubleshooting of large scale technical issues and management of key business metrics. Darian Rashid

Steve Rogalsky gets a thrill out of solving problems, working with teams, and helping people learn and improve. I apply this to software development using lean and agile techniques as a process hacker, coach, analyst, tester, developer, speaker, and agile advocate. I blog at winnipegagilist.blogspot.com and work at protegra.com. Dave Rooney is a veteran Agile Coach in Ottawa, ON, Canada with 25 years industry experience, and a Co-founder/Consultant with Westboro Systems. He has been involved with Agile Software Development since 2000, helping private and public sector organizations from pre-funding startups to the Fortune 15 improve their software delivery process. Dave is also a co-founder of the Agile Ottawa Group, and an active writer, speaker and advocate of agile methods in Canada.

www.agilerecord.com

Steve Smith is a software developer with a passion for building quality software as effectively as possible. Hes a Microsoft Regional Director and MVP, a frequent speaker at developer conferences, an author, and a trainer. Hes the co-founder of NimblePros. com, an agile software studio located in Hudson, Ohio, which builds custom software for clients with an emphasis on quality and craftsmanship. Zuzanna Sochova is a leader of the Czech agile community Agile Association AgilniAsociace.com, organizing conferences and events and sharing the agile experience all around. She works as a trainer, consultant and coach for software organizations, support them in tailoring their agile adoption processes to company culture (agile-scrum. com). She regularly speaks at international agile conferences. She is Managing Director of LOTOFIDEA (http://lotofidea.com/).

Declan Whelan I strive on building great software with great teams. During my career, I have found agile/lean principles and practices to be the best way to do that. So I now spend a lot of my energy training, coaching and mentoring teams to build the environments in which they can truly succeed: open, supportive environments where everyone brings their genius selves to work each day to deliver continuous value.

Book your CAT training in USA!

CAT is no ordinary certification, but a professional journey into the world of Agile. As with any voyage you have to take the first step. You may have some experience with Agile from your current or previous employment or you may be venturing out into the unknown. Either way CAT has been specifically designed to partner and guide you through all aspects of your tour.
Sergejy Galushko Fotolia.com

Open Seminar in USA: July 0206, 2012 in Orlando, Florida Daz & Hilterscheid GmbH / Kurfrstendamm 179 / 10707 Berlin, Germany Tel: +49 30 747628-0 / Fax: +49 30 747628-99 www.diazhilterscheid.de training@diazhilterscheid.de www.agilerecord.com

Column

Agile Testing in the Real World Training a New Agile Tester

by Lisa Crispin
Finding a tester with the right attitude and mindset to work well on an agile team is no small feat. Ive written several articles and blog posts on recruiting and interviewing1 agile testers. My team recently searched for five months before we found ONE person to bring in for an interview for our open tester position. Luckily, he was the right person, and accepted our offer. Our new tester, Michael, has many years experience as a tester and QA manager on more traditional software teams, albeit in fast-paced industries. He had no experience with agile before joining our team. He was eager to learn, and we wanted to find good ways to help him transition to being part of a self-organized agile team. Preparation For several years, weve kept notes on training a new tester on our team wiki. These were our starting point for deciding how to get our new hire up to speed. The wiki page is designed to give the tester links to other important information on the wiki, such as a list of go to people and documentation about test environments. In the days before Michael joined our team, we spent a lot of time updating this tester training program. The main part of the page is titled Stuff to learn. Its divided into sections (we tailor the gender to fit the new hire): What does the new tester need to know by the end of his first day? What does he need to know by the end of his first sprint? By the end of the first month? By the end of the first quarter? These sections include a wide range of topics, from intro to own machines and test environments to Learning about agile and how we work. Some subjects include the name of the team member who will provide information. For example, our ScrumMaster will give an overview of Scrum, and our senior architect will provide a high level look at our application architecture. Everyone on the team contributed to updating the training the new tester page. My favorite addition was from our system administrator, who noted: Lunch protocol Lunch talk starts at around 11:20. If you ask Where are you going, be prepared for some goofy looks, as we never know in advance. This detail is usually figured out en-route.

This is good fun, but on a more serious note, every new person must learn the team culture! The day before Michael started, I wrote task cards for all the different things he needed to learn in his first month, and put them on a separate story row on our task board. Training a new team member, regardless of their role, involves the whole team, and thus we must budget time for it. It will slow us down for a few sprints, as we invest time in bringing the new team member up to speed. We expect this, and we plan fewer user stories to allow time for training the new person. On-the-Job Training On Michaels first day, we showed him the wiki page, and explained that though we had a training program in mind, we also expected him to pull information as he needed it. We knew he wouldnt be shy about this, based on our interview with him. We also tried to impress on Michael that his main job for the next several weeks is to learn. Its so easy to get sucked into the day to day routine of cranking through user stories. Our business is

1 http://lisacrispin.com/wordpress/2011/10/07/improving-our-interviewprocess/

www.agilerecord.com

complex, and Michaels first few months are the time for him to learn many aspects of both the software development and business sides. In Michaels first week, different people paired with Michael to work on his various tasks. The system administrator showed him his new MacBook Pro, Windows 7 PC, and Linux server. He made sure Michael could install the necessary tools, such as the version control, IDE, and defect tracking system client. Our DBA helped Michael set up SQL Developer and walked him through the database schemas. The other tester and I helped him set up his test server, learn to deploy new builds, install the various test tools we use, and helped him learn how our Jenkins Continuous Integration (CI) works. You may notice a pattern here. Most of the time, someone was pairing with Michael to help him learn something new. Weve found this the most effective way to help a new team member learn. After a couple of weeks, Michael felt confident enough to jump in on actually testing the code for a new user story. As it happened, one theme we were working on involved one of the most difficult areas of our financial services application. Michael assigned himself the manual exploratory testing tasks for the user stories in this theme. This testing would have been difficult even for me. The programmer working on the code paired with Michael and they worked together to better understand the requirements for the stories, and how best to code and test it. No formal arrangement made this happen Michael simply picked up the testing tasks and the programmer naturally came over to pair with him. They delivered the new functionality with great success. Next sprint, Michael took on another difficult user story, involving a complicated batch process. I paired with him, and the synergy of having someone new to the functionality, asking questions, and me trying to explain the answers caused us to discover some issues right away that Im not sure Id have found on my own. Pairing is powerful even when one of the pairs is brand new to the system. One outcome of Michaels training is that we realize we need to spend more time pairing, not only for training or working on a particularly complicated problem, but for any user story. Having the fresh viewpoint of someone new to the team is a big advantage, which we want to leverage. Even though all of us are quite experienced, pairing helps generate new perspectives. Whats next? Its been six weeks since Michael started, and hes moved his training task cards to the done column. Hes already added plenty of value, but we want to keep his focus on learning. Hell spend time sitting with business users, learning their jobs and how they use our software. Hell be updating our wiki page for training new testers to help with the next new person we bring on board!

Our past experience has proven the value of making a big investment of time in training new team members. Our business stakeholders understand that we must devote a significant amount of our time to bringing a new teammate up to speed, and thus, we will deliver fewer new user stories for a few sprints. We know that this investment will pay off when our new tester has a good understanding of the domain and application. If youre hiring a new tester on your agile team, invest time in formulating a training program. Prepare to have various team members pair with the new tester to help him/her learn. Take advantage of your new testers fresh perspective, but let him/ her take time to get comfortable with the application, database schemas, test environments, test tools, IDEs and the business domain. Agile is all about learning and improvement. Bringing a new tester on board is a reminder of why we love quick feedback loops and close collaboration.

> About the author

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (AddisonWesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002), and a contributor to Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011) and Beautiful Testing (OReilly, 2009). She has worked as a tester on agile teams for the past ten years, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine. For more about Lisas work, visit www.lisacrispin. com. @lisacrispin on Twitter, entaggle.com/lisacrispin

www.agilerecord.com

March 1214, 2012 Brussels, Belgium Belgiums most popular international 3-day testing event www.belgiumtestingdays.com

Belgiums most popular international 3-day testing event

This years theme

QA versus Testing! Antagonism or Symbiosis?

43 speakers delivering High Level Knowledge Transfer 5 tutorials

27 tracks 4 keynotes 1 exciting lightning talk

4 workshops

Exhibitors & Supporters

Daz & Hilterscheid Unternehmensberatung GmbH Kurfrstendamm 179 10707 Berlin (Germany) Phone: +49 (0)30 74 76 28-0 Fax: +49 (0)30 74 76 28-99 www.diazhilterscheid.de

AQIS bvba Uilstraat 76 3300 Sint-Margriete-Houtem (Belgium) Phone: +32 16 777420 Fax: +32 16 771851 www.aqis.eu

Follow us @BelgiumTD

Technical Debt and Load Testing

by Peter Varhol

There are few hard-and-fast rules in software development projects. There are many possible choices of methodology, design, programming language, and overall best practices, and which choice is the best for a particular project typically boils down to: It depends. However, an observation first made by Ward Cunningham of Extreme Programming fame is one rule that seems to fit all projects. He noted that teams face many design and coding decisions during the course of a project, and there are two possible approaches to such decisions: the quick and dirty approach, which likely works for the majority of cases, or a more comprehensive and complete approach. The more complete approach typically takes longer, often too long for a project to remain on schedule or to keep up a good pace for the team. Many teams opt for the quick and dirty approach, and commit to revising the code with a more robust and complete solution later when/if time allows. Cunningham called this practice technical debt1, based on the notion that anything less than a complete solution results in designs that must be revisited and code that must be refactored. It is analogous to financial debt because it must be repaid, usually with interest, in the form of additional project time at some point in the future. Technical debt may be undertaken wittingly, in that team members make a conscious decision to incur the debt due to schedules or technical considerations; or unwittingly, in that the team doesnt realize that the decisions it makes are not comprehensive or optimal. In either case, identifying and measuring technical debt is an important part of any successful project. If the team understands where it has taken on debt, and how much debt it has undertaken, it can better plan to pay it back over time.
1 http://en.wikipedia.org/wiki/Technical_debt

Testers need to be aware of technical debt because it almost invariably influences the quality of an application, as well as its readiness for production use. At first glance, the need for that awareness may not seem to follow logically. Testing, especially functional testing, involves outward-facing functionality and conformance to requirements, while technical debt concerns internal implementation details in the application. Asking testers to create tests and make assessments of implementation strategies seems both unproductive and a poor use of testing resources. However, testers are ready-made to perform this role. They are the objective assessors of application quality, and often hold sway over when an application under development is ready for production. They also have the tools needed to identify and measure at least some aspects of technical debt. Whether or not the team as a whole knows they are taking on technical debt, testers are in an ideal position to help identify that debt, its size, and when the debt has been repaid. How to Manage Technical Debt Lets be clear, technical debt is not necessarily a bad thing. Taking on some judicious technical debt can be an appropriate decision to meet schedules or to prototype a new feature set, as long as the decision was made with a clear understanding of the costs involved later in the project, such as code refactoring. However, the consequences of failing to identify and measure technical debt can be significant. An application with a lot of technical debt may not be able to fulfill its business purpose and may never reach production. Or technical debt may require weeks or months of remedial refactoring before the application emerges into production. At best, it could reach production, but be limited in its ability to meet users needs. I would like to propose a means of identifying and measuring technical debt as a part of the quality process in an agile methodology. That process involves frequent load testing of the ap-

10

www.agilerecord.com

plication, usually toward the end of an iteration, either during or immediately after functional testing. Why load testing? Load testing exposes weaknesses in an application that cannot be found through traditional functional testing. Those weaknesses are generally reflected in the applications inability to scale appropriately. Testers are also typically already planning to perform load testing at some point prior to the production release of the application. Load testing involves enabling virtual users to execute predetermined actions simultaneously against the application. The scripts exercise features either singly or in sequences expected to be common among production users. Load testing looks at the characteristics of an application under a simulated load, similar to the way it might operate in a production environment. At the highest level, it determines if an application will support the number of simultaneous users specified in the project requirements. However, it does more than that. By looking at system characteristics as you increase the number of simultaneous users, you can make some useful statements regarding what resources are being stressed, and where in the application they are being stressed. With this information, the team can identify weaknesses in the application that are generally the result of incurring technical debt, therefore providing the basis for identifying the debt. A Testing Lifecycle for Technical Debt To use load testing as a way of identifying and measuring technical debt, use a lifecycle similar to the following. First, create and maintain automated load test scripts that will be used in a defined sequence to drive load testing. Second, just prior to the conclusion of an iteration, when the build has been functionally verified, testers execute a load test running the appropriate test scripts. These test scripts should focus on user stories that exercise the features added in that iteration, as well as a more complete set of regression tests against existing use cases. Third, testers analyze the resulting data. Much of the data can be assessed visually, using time series graphs or bar charts. Some data may require further analysis using statistical methods. However, it is important to identify potential debt quickly, so standard techniques should be developed and used. Fourth, any performance, scalability, or resource utilization deficiencies should be discussed among the team to determine if any were the result of technical debt. Any significant differences from expected scalability should be discussed, and if deemed to be technical debt, noted and tracked. In time, the debt should be retired through refactoring or rewriting code, or it should be documented as a limitation to the deployed application. Last, IT management needs to understand the concept of technical debt and how it applies to their applications. This necessitates periodic reports and briefings on the limitations of the ap-

plication as identified by load testing, and how those limitations will be addressed in future development iterations. Identifying and Analyzing Technical Debt Some automation and measurement tools are required to successfully identify and assess technical debt with load testing. Manual load testing is not an effective solution these days, given the hurdles to organizing and managing the simultaneous actions of dozens or even hundreds of testers. An automated testing solution, like Seapine QA Wizard Pro, enables testers to run a given number of virtual users, executing scripts that simulate the activities these users might perform in the application. QA Wizard Pro also includes a set of reports that provide summary information on application behavior. At the same time, a wide variety of system characteristics can be measured using Windows Perfmon or similar tools. Perfmon, built into all editions of Windows, provides a flexible and highly customizable way of measuring dozens of system characteristics and saving that data in a spreadsheet format for later analysis. There are a variety of measures that testers can examine while running load testing. These include: CPU utilization, including individual processors and processor cores. The CPU is often one of the limiting factors preventing an application from scaling. While its not uncommon for a fully loaded application to utilize 90 percent or more of the CPU, reaching that plateau too soon might mean the application is executing too much code to use the computer efficiently. Todays multi-core processors and multiprocessor systems also play a role in CPU utilization practices. Poor or inappropriate programming practices could cause an application to show affinity toward a particular processor or core, which results in unused processing power not using large amounts of the available CPU power. Memory working set. Upon starting an application, memory use will climb rapidly to a plateau often referred to as the working set. The actual size of the working set isnt as important as its trend over time. If the working set continues to grow gradually over time, as virtual users come and go, that is a clear indication of a memory leak memory that is being used by the application but not being returned to the system when the application is finished with it. Memory leaks can occur from incorrect coding or attempts to circumvent or shortcut good practices. They can negatively affect application performance and scalability and, under some circumstances, even cause an application to crash. While on the surface a memory leak is more of an internal defect than a debt taken, it could be the result of inconsistent use of memory management practices in the application framework. Disk activity. As one of the only mechanical processes involved in computing, data access from disk is at least an order of magnitude slower than from memory or cache. There is always disk www.agilerecord.com 11

activity because much of an executable application resides on disk prior to being pulled into main memory. However, disk access also occurs during reads and writes to a database. If the project team hasnt planned out its data usage, code can perform data reads and writes haphazardly, rather than organized as a few data objects typically kept in memory. Such haphazard coding practices are a clear example of technical debt. Depending on the application, other possible characteristics include network activity, .NET or Java Virtual Machine behaviors, and thread creation activity. All can have an effect on the ability of an application to scale, and may be the result of the team consciously or unconsciously taking on technical debt. While on the surface testers are ensuring conformance to requirements on application scalability, they are also looking deeper into the application to determine debt and make it visible to the team as a whole. Once load testing has identified such application weaknesses, testers offer them up as questions or issues to be addressed prior to the completion of an iteration. If the team agrees they represent technical debt, those weaknesses are documented and tracked until the debt is repaid or otherwise discharged. This raises the question of alternative methods of dealing with technical debt, including production methods. Many teams assume that IT operations can address limitations in scalability or other application weaknesses through more and larger servers and server farms, faster networks, and more robust data administration and tuning. Some technical debt may be hidden successfully through production practices. Often, debt is not amenable to the addition of computing power or database tuning. In most cases, sooner or later the debt will cause an application slowdown or failure in production. Because load testing helps testers verify requirements as well as gain insight into internal application weaknesses, it enables teams to identify areas inside the application that may have acquired technical debt during development. Load testing can be especially useful when used with agile methodologies because multiple iterations enable teams to examine their debt at the end of each iteration, allowing for planning to retire technical debt in subsequent iterations.

> About the author

Peter Varhol is a well-known writer and speaker on software and technology topics, having authored dozens of articles and spoken at a number of industry conferences and webcasts. He has advanced degrees in computer science, applied mathematics, and psychology, and is currently solutions evangelist at Seapine Software. His past roles include technology journalist, software product manager, software developer, and university professor.

12

www.agilerecord.com

Column
An agile testing future
by Huib Schoots
In November 2011, I attended the Agile Testing Days in Potsdam. I had a great week, met a lot of interesting people and was very much inspired. However, I noticed something: only two of the nine keynotes were about testing. Not that they werent interesting. They certainly were! But its remarkable. Is this an evolution? Is testing not important in agile? I think it is at least underexposed. What does the future bring us? The future of software testing At the moment Im writing a book with a group of enthusiastic testing colleagues for the Dutch testing association TestNet (*). The anniversary book by the jubilee book committee (JuBoCo) is about the future of software testing. There is nothing more difficult than predicting the future, and we dont have the illusion that we can. Yet writing a book with seven colleagues is a great experience: discussions with each other, investigating topics, the new insights, but also developing my own vision of the future. What will you do as a tester in the future? How do you prepare yourself for the future? What choices will you make? For the tester it is slowly becoming a balancing act: does he opt for generalization by knowing a bit of all aspects, or does he choose to specialize and know everything there is to know of a certain aspect? And if a tester is going to specialize, which specialization to pick? Which choice should a tester make to be of value in about five years or later? In our book we choose to use different personas to look into the future. A persona, which is a characterization of a particular type of user, is commonly used in IT. We use the personas in our book to describe various scenarios: they all make a different choice to prepare for the future. Andr believes that testing will end up in the business: I want to become a business analyst or product manager, so Ill learn all about how users think and work. Dennis believes that testing will immerse in development: All the innovations come from the development: ATTD, TDD, SCRUM are all development techniques. Ilona says that testers are going to specialize in non-functional aspects such as security, performance, etc. As the demand for testers is waning, I am still asked because I know more than others about these topics. Yasmine thinks that if you are really good, you always have work: Im a jedi-tester and find errors earlier and better than anyone else. Scripted, Exploratory, technical or user level. I quickly understand each system and advise on the value of the system. These four scenarios could become reality. Or maybe they already have become reality in some places? I like the fourth scenario best. Old school testing? Look at projects we do in a traditional setting with characteristics like Waterfall, Prince2 and the V-model. I almost wanted to say in former times, but in many cases we still do it. A designer consults the users and makes his design on paper. A programmer builds the system based on his interpretation of the design in a development environment. When the tester starts, the various components have to communicate with the infrastructure and with other systems. Often it is the first time the whole system is integrated. The tester is a spider in the web. When he does well, he communicates with all parties: technical experts, designers, developers, business analysts, environment coordinators, project managers, users, etc. But he still tests as much as possible himself, and testing is a separate phase. Projects are becoming increasingly agile and use more and more agile elements: short iterations, stand-ups, whiteboards, user stories, burn-down charts, work items, etc. The testers skills (the learned capacity to carry out pre-determined results often with the minimum outlay of time and energy) will have to change with this. Collaboration becomes more important and thus we see that the tester is becoming more assertive and pro-active. Different role The tester gets a different role. In agile projects everyone is responsible for the quality of the delivered products. And in the future, I think development will be even more in that direction. A tester is not alone in this, after all its the whole team that tests. Testers will get a coaching role and will coach their teammates. They will teach and distribute their expertise over the team. A tester must be able to work with everyone and know that software development is a team sport. Software development is done with a team, and the tester should therefore actively look for ways to collaborate with the team. The tester knows that he is even more effective when he works together with developers

www.agilerecord.com

13

for example. Developers are complementary and can help him test faster and smarter. In agile projects test automation is very important. And again: cooperation between testing and development is essential to make this work. You cannot hide In former times, the tester was finding errors in the testing phase when the software was ready. In the future, testers will get involved much earlier. Agile means building a good product from the start. This will change the testing craft. In the past we saw a strong focus on finding errors and a procedural way of testing. Under the influence of agile and context-driven trends testing is becoming increasingly exploratory. This is necessary because of the way and the speed in which we do projects: iterative with short feedback loops. The quantity, but also the less detailed level of documentation available in advance, calls for different approaches. I think exploratory testing is an important one. This requires different skills of a tester. To cope with the ever-growing complexity and ever-changing world around us, the requirements of a tester are getting higher (or at least: they should be). It requires a higher level for the skills that make a good tester: critical thinking, questioning, but also mastering testing skills, for example, applying testing techniques or doing (risk) analysis. In the past testers could get away with not having good testing skills. Because of the mainly confirmative way of testing, coverage of requirements was important. If the report was fine and all requirements were covered, testing was okay. However, finding the major bugs in a short time is a different story. In preparation for test execution, writing the test cases, the tester formerly had plenty of time and the opportunity to hide. In future, expectations will go up: with limited preparation he must show his testing skills applying testing techniques while he tests (exploratory). In projects testers collaborate increasingly closely with their teammates. The tester will quickly fail and not be taken seriously if he cant show his skills. Pairwise learning Back to the Agile Testing Days. I spent some time in the test lab doing some exploratory testing paired with a developer. It was an interesting session: he wanted me to show him how a tester does his job. And I learned how a developer looks at my way of testing by asking him questions and watch his reactions. He was nicely complementary on some points and some critical questions helped me generate new ideas. A nice learning session for both of us, and this can be done in projects as well! Lets learn! So is testing important in agile? Yes, it is! Things will change for testers, that much is certain. Agile teams really do need testers or at least people who have strong testing skills [Hendrickson, 2008]. And there is still plenty to learn! Can we therefore agree that at the Agile Testing Days 2012 there will be more about testing? I love to discuss the issues of testing in agile projects. Which issues do we see? What will the future look like? Where can we improve? How can we learn from each other?

(*) TestNet is a Dutch network of, by and for testers: TestNet offers its members the opportunity to meet other testers and share knowledge and experience. TestNet organizes regular monthly evenings and has approx. ten special interest groups like agile testing, usability, privacy and model based testing. TestNet also organizes two major events every year and publishes a newsletter. Next year TestNet celebrates its 15th anniversary. The initiative for establishing TestNet was taken late 1996. The reason was the growing interest in structured testing. TestNet was formally established on May 15th, 1997 and currently has about 1,600 professional testers as members. [Hendrickson, 2008] Agile Testing, nine principles and six concrete practices for testing on Agile teams Elisabeth Hendrickson http://testobsessed. com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

> About the author

Huib Schoots has 15 years experience in IT and software testing. After studying Business Informatics he became a developer. Soon he discovered that development was not his cup of tea and software testing is fun. Huib has experience in various roles such as tester, test coordinator, test manager, trainer, coach, but also in project management. He is currently Team Manager Testing at Rabobank International. He tries to share his passion for testing with others through coaching, training and giving presentations on different test subjects. Huib sees himself as a context-driven tester. He is curious, passionate and has (unsuccessfully) attempted to read everything published on software testing ever written. He is a board member of TestNet, the association of testers in the Netherlands. He is a member of DEWT (Dutch Exploratory Workshop on Testing), student at the Miagi-Do School of Software Testing and maintains a blog on magnifiant.com

14

www.agilerecord.com

May 1617, 2012 London Marriott Hotel Grosvenor Square The Conference for Testing & Finance Professionals
www.testingfinance.com

A Daz & Hilterscheid Conference

iStockphoto.com/STILLFX

Conference (Day 1) May 16, 2012

Time 08:00 09:10 09:15 10:15 10:20

Track 1

Track 2 Registration Opening Speech Jos Daz Keynote: TBD Break

Vendor Track

Model based testing using acceptance tests as oracle Adrian Rapan Whats so special about Testing Financial applications, anyway? Bernie Berger

Testing the Financial cloud Bart Knaack Coee Break Help!, my supplier works agile and I dont Chris C. Schotanus Break Keynote: The Future of Testing and Finance Paul Gerrard Lunch TBD TSG

11:10 11:25

12:15 12:20

13:20 14:35 TBD

Practical approaches to systematic test case design Dr. Hartwig Schwier Coee Break Experience in Multinational Banks with Advanced Stakeholder-Value Requirements: Quanti ed Critical Project Requirements for Testability and Tracking Tom & Kai Gilb Coee Break Identity fraud and the use of electronic identity Robin John Lee Break Keynote: Online Crooks, Governments, Banks, You and me! Peter Kleissner Cocktailparty

15:25 15:40 Test specialist on agile teams: A New Paradigm for Testers Henrik Andersson

16:30 16:45 Financial Software Testing Jean-Paul Varwijk

17:35 17:40

20:00

We would like to invite you to the first Testing & Finance conference in London, UK. The two-day conference Testing & Finance, which is held once a year and for the first time in the UK, brings together quality assurance specialists and experts from the financial world from both home and abroad. Since 2005, Daz & Hilterscheid has been inviting well-known international speakers to this event. Testing and Finance in Agile Projects, Social Media and Regulation is the main theme of next years Testing & Finance, taking place on 1617 May 2012 in London, UK.

The focus lies on technical subjects in Software Testing, as well as on Regulatory Reporting and its impact both from a business and technical perspective. Well-known organizations from the industry oer information about their products and services during the exhibition which is held parallel to the conference. We hope you will enjoy the Testing & Finance conference 2012!

Conference (Day 2) May 17, 2012

Time 08:0009:00 Time 08:00 09:15 Track 1

Early Keynote TDB TBD (Capgemini) Track 2 Registration Keynote: Agile Testing in a Regulated Environment Peter Varhol Break Test Data Management Adressing Data Sensitivness and compliance without sacri cing productivity Dr. Klaus Haller Speci cation by example applied to Cpp legacy code using FitNesse Cslim Laurent Decorps Assuring the success of Agile in a regulatory environment Matt Robson (CAPITA) Vendor Track

10:15 10:20

11:10 11:25 Visualising Quality David Evans & Gojko Adzic

Coee Break Filling the Gap Testing what BDD doesnt Matthew Archer Lunch Automated Testing For Financial Feeds Made Easy Glyn Rhodes & Stuart Walker Co-operative Banking Group and Infosys Approach for Successful QA Transformations Paul Shatwell & Kiruba Vijayaraka Coee Break Fords Lean Jorrit-Jaap de Jong ATDD with robotframework done right Sajjad Malang & Catherine Decrocq Testing Credit Risk Rating Models Ron Coppejans Coee Break Regression Testing Live Systems Doing It Better Scott Summers Break Keynote: Back to the future: the changing role of QA Gojko Adzic Closing Session, Jos Daz
Please note that the program is subject to change.

12:15 13:30

14:20 14:35 15:25 15:40

16:30 16:35

17:35
25-minute presentation

Exhibitors & Supporters If you want to support the Testing & Finance 2012 conference please contact us at info@testing nance.com.

Testing & Finance Europe 2012 A Daz & Hilterscheid Conference Daz & Hilterscheid Unternehmensberatung GmbH Kurfrstendamm 179 10707 Berlin Germany

Phone: +49 (0)30 74 76 28-0 Fax: +49 (0)30 74 76 28-99 info@testing nance.com www.testing nance.com www.xing.com/net/testing nance

Agile practices for revision control

by Carlos Ble

Distributed version control systems (DVCS) are a very important tool for agile teams, especially for distributed ones. If your team uses the tool as a mere backup system, you are losing productivity. These tools are much more than that. If you are still using Subversion, CVS or any other centralized system, its time to switch to a distributed system. Even if the whole team or the project cant be switched to a DVCS, every developer can still use one on her local machine, to check in code locally prior to sending changes to the central repository. I consider a DVCS to be a two-step system where you can create snapshots of the source code in your local machine as many times as you need to, without affecting your colleagues work. Afterwards you canmerge code with them, once you know it is stable, complete or just needs to be shared. This is a major advantage. People will not be afraid of the commit command anymore because it wont break anyone elses work (commit is the same command in Subversion, Git and Mercurial). There will be no conflicts at the moment of taking a snapshot of the code. Committing the code is just that, its taking a picture of the code to save your changes. One of the popular arguments in favor of DCVS is that you can merge with any colleague, not just with a central repository. That s great, but most of the time you just send your changes (push) to a central place where all changes are shared among the team. So the actual benefit that everyone leverages is being able to check in code when they want and to have the tool merge the changes easily. Now, how often should I commit and what should that snapshot contain? The code review is a key aspect of eXtreme Programming. Along with pair programming, it leads to collective code ownership, which is something fundamental in a team that is committed to deliver a great product. For productive code reviews, the information in the DVCS has to be human readable. 18 www.agilerecord.com

In order for the commit to be understandable by others, it must contain a single change. Usually, this should be no more than 20 lines of code. If we rename a method which is called in many places, then the commit will contain several files, but still the change would be easy to understand, its just a method rename. If we need to tabify or change the indentation of a file, that change has to be committed separately. We do not commit a file which contains different indentations plus a new feature. We commit the indentation change after or before the behavior modification. The commits comment or descriptionhas to be very precise, specifying what the change is. Special tags can be used to express typical operations like tabify. These are some examples of descriptions (one by line): 1: FeatureX: do not send email if address is wrong 2: tabify 3: refactor: extract method The first one tells us what feature is involved along with its details. The second and third express common operations and we use a hash to mark them down. As we practice TDD, we commit on red and then on green and eventually commit after the refactor. Several members of my team are learning TDD now. For me its a great way to review their progress and see the way they test drive the code even when I am not pairing with them. As an example of this technique, Ive been practicing TDD with a simple code kata# to record the changes the same way we do in our daily tasks. This is what Mercurial history says (starting from the first change). You can see the whole process reading the commits information:

(A line starting with a plus symbol means a new source line added. A line starting with a minus symbol,means it has been removed.)
================================================ changeset: files: production.py tests.py 0:0ab8b696da6a

description: red. first test diff tests.py: +import unittest

+from production import * +from hamcrest import * + + + + + +

+class TemplateEngineTests(unittest.TestCase): template = this is the template

def test_parsed_template_is_equal_to_original_template_if_nothing_to_replace(self): parsed = parse_template(template, {}) assert_that(parsed, _is(template)) 1:b246c5ade5b2

================================================ changeset: files: production.py tests.py

description: green. first version of the template engine API is defined diff production.py: + + +

+def parse_template(template, replacement_pairs): diff tests.py: return template

assert_that(parsed, _is(template)) assert_that(parsed, is_(template)) 2:d6f86b60b043

================================================ changeset: files: tests.py

description: red. trying to replace a variable. Id like the braces to mark variables diff tests.py: + + + + + def test_it_knows_how_to_replace_a_variable_within_the_template(self): template = this {PLACEHOLDER} is great parsed = parse_template(template, {PLACEHOLDER: magazine}) assert_that(parsed, is_(this magazine is great)) 3:b3d3fe405e36

================================================ changeset: files: production.py

description: green. the simplest replacement algorithm that I need so far diff production.py: + def parse_template(template, replacement_pairs): return template return template.replace({PLACEHOLDER}, magazine)

================================================ changeset: files: tests.py 4:53da3c6e332a

description: red. working towards replacement generalization diff tests.py: + + + + def test_any_single_variable_should_be_replaced(self): template = I {VARIABLE} TDD parsed = parse_template(template, {VARIABLE: enjoy})

www.agilerecord.com

19

================================================ changeset: files: production.py 5:f8218db6df87

assert_that(parsed, is_(I enjoy TDD))

description: green. it can replace any variable name, but just one variable so far diff production.py: + + + + + + def parse_template(template, replacement_pairs): pairs = replacement_pairs.items() if len(pairs) > 0: pair = pairs[0]

return template.replace({PLACEHOLDER}, magazine)

key = {%s} % (pair[0],) return template

return template.replace(key, pair[1])

================================================ changeset: files: tests.py 6:06580fb759a9

description: red. it needs to replace all the variables, not just the first diff tests.py: + + + + + def test_multiple_variables_will_be_replaced_too(self):

template = Welcome {USERNAME}, you have {MSG_COUNT} new messages

parsed = parse_template(template, {USERNAME: Carlos, MSG_COUNT: 3}) assert_that(parsed, is_(Welcom Carlos, you have 3 new messages)) 7:1f96db614ce9

================================================ changeset: files: production.py tests.py

description: green. it is generic now. a typo was fixed in the test diff production.py: def parse_template(template, replacement_pairs): pairs = replacement_pairs.items() if len(pairs) > 0: pair = pairs[0]

+ + +

key = {%s} % (pair[0],) for pair in pairs:

return template.replace(key, pair[1]) key = {%s} % (pair[0],)

diff tests.py: +

return template

template = template.replace(key, pair[1])

assert_that(parsed, is_(Welcom Carlos, you have 3 new messages))

assert_that(parsed, is_(Welcome Carlos, you have 3 new messages))

Short/atomic commits are also very useful for refactoring, especially for legacy code. Sometimes you cant tell the impact of a transformation, or you dont know exactly if the new design is going to fit in the system. If you committed your previous changes just a few minutes ago, then you can discard the new changes and nothing but a few minutes get lost in the exploratory session. If the transformation is going to take more than half an hour, you should commit to a new temporary branch in your local machine, again, adding a few changes in every snapshot. You can go back any time to explore other choices minimizing the risk and the waste. I always encourage people to commit their changes before starting a refactoring, a spike or a new test.

Pair programming brings healthy discussions sometimes. The best way to stop them before they take too long is to ask your colleague to let you change the code a little bit to see if both agree on the design. Its easier to talk about code which is already written. If you dont like it, just discard the changes or use another branch to save them for a later discussion. The number of commits in a day is a good productivity metric. Every pair or every developer should be committing every 10 minutes. When the repository history shows less commits than that, we know there have been some issues with legacy code, fires or any other drawback.

20

www.agilerecord.com

Branching and merging are the other powerful capability of DVCS. Unless two commits contain changes in exactly the same line of code, they will be merged without any problem. Every machine contains already a whole repository which can be considered a branch itself. However, there are also named branches (branches shared with others have a name). We use named branches because we want to see a colleagues code every day. It is part of the code review session, even if the job is being developed in another branch. Although branching and merging is easy, we try to merge branches every day; not always in both directions but at least from the main/default branch to others. Without this, merges might be painful. We open a new branch for every new feature, but the rules are: Bring the changes from the main branch to your feature branch several times a day. If you have to change code which is shared with others, apply that commit to the main branch too. Try to merge in both directions at least once every two or three days.

> About the author

Carlos Ble Passionate software developer and entrepreneur. Blogger at www.carlosble. com. Always looking for better ways to develop software products and raise the motivation of the team. Main author of the first book on TDD in the Spanish language (www. dirigidoPorTests.com/el-libro). As XP and agile mentor, Carlos visits companies to teach developers and management. Coach apprentice. Founder of iExpertos.com. Currently living in the beautiful Canary Islands (Tenerife).

This technique is not exactly feature branch (as explained by Martin Fowler, http://martinfowler.com/bliki/FeatureBranch.html). It gives us the ability to share code daily, so as to be aware of what everyoneworking on quickly. At the same time, you can work on your branch resting assured that your changes will not compromise the main branch with a feature that is not finished. The idea behind this is that the main branch should be ready to go live any time. Distributed teams may suffer from communication problems. Giving the team a tool where people can talk about code easily (even if they dont pair) makes an important difference. In addition, I would recommend pair programming over the Internet. We are using Skype plus Teamviewer to chat and work on the same computer, and the experience is very positive.

Readers Opinion Youd like to comment on an article? Please feel free to contact us: editorial@agilerecord.com
www.agilerecord.com 21

Continuous integration to test large distributed systems

by va Takcs & Istvn Forgcs

The Large Hadron Collider (LHC) in CERN results in 15 petabytes of data per year. This should be processed to find Higgs boson, whose importance is described by its nickname: The God Particle. The software system necessary to process this huge amount of data was developed by an international team consisting of about 70 teams. A special software management tool became necessary to coordinate the work and assure high quality. The ETICS team successfully developed such a tool fulfilling these requirements. An augmented version of ETICS is currently working to help different EU research and development projects and industrial teams as well. This article presents an overview of ETICS, its key features and how it helps agile testing in a new EU project called SCI-BUS. The original, open source ETICS (eInfrastructure for Testing, Integration and Configuration of Software) was implemented inside a project co-funded by the European Commission, and the consortium was led by CERN (http://etics.web.cern.ch). ETICS, a software management tool with advanced continuous integration features for large distributed system provides software professionals with an out-of-the-box build and test system, powered with a build and test product repository. The main features of the system can be summarized as follows: Distributed, multi-platform builds and tests-ETICS distributes builds across different machines exploiting the computing power of a distributed environment. Rich build/test configuration options Advanced dependency management for build and runtime software dependencies Support for automatic creation of distribution packages Collection of test information as metrics

www.lpds.sztaki.hu/) and involving e-Scientiest representing different e-Science communities, and a couple of industrial partners from different European countries. The SCI-BUS project aims at easing the life of e-Scientists by creating a new science gateway customization methodology based on the generic-purpose gUSE/ WS-PGRADE (http://guse.hu/) portal family that provides seamless access to major computing, data and networking infrastructures and services. The project will create and maintain a Liferay portlet repository that enables the quick creation of user specific customized gateways on top of the generic-purpose gateways. In that sense SCI-BUS creates a generic-purpose gateway technology that provides seamless access to major European DCIs (Distributed Computing Infrastructures) including clusters, supercomputers, grids, desktop grids, academic and commercial clouds. SCI-BUS elaborates an application-specific gateway building technology and a customization methodology based on which user communities can easily develop their customized gateways. Science gateways are frameworks (or toolsets) which incorporate applications, data and tools to enable running applications on Grid infrastructures. They also provide services to upload, search, manage and download (or share) applications and data. The gateways are integrated via portals or sets of applications. Gateways enable user communities to use computer and data resources through a common interface. The developed gateway technology (P-GRADE framework) and customization methodology will be applied to create applicationspecific gateways customised for various types of user communities including astrophysics, seismology, helio-physics, computational chemistry, bioscience, biomedicine, PireGrid SMEs community, Blender community, citizens web-2 community, DCI application developer communities, and business process modelling community (http://www.sci-bus.eu/partners). Having the P-GRADE framework, the communities behind the

SCI-BUS is an eInfrastructure project sponsored partly by the European Commission having as coordinator MTA SZTAKI (http://

22

www.agilerecord.com

customized gateways did (and do) not have to start to build their gateway from scratch. Rather they could use all the thoroughly tested internal services of P-GRADE, and after a relatively easy adaptation and extension procedure they were able to successfully create, deploy and operate their own customized gateways as a production service for their local and public DCI platforms. In that sense, the QA team of the project has a really challenging task. Particularly, the QA team has to adopt a customized agile methodology and the associated toolset to be applicable for a geographically distributed team coming from different areas (academic and business) developing distributed systems based on generic gateway service (gUSE/WS-PGRADE) with underlying grid and cloud infrastructures. Processes and tools are only as good as they help solving problems and increase productivity#. As such, in SCI-BUS a lightweight development and release process is used, taking into account the research and development nature of the project, the homogeneity of the portals to be implemented, and also the homogeneity of the partners (academic and industrial). Agile concepts such as early builds and automated tests, continuous integration, advanced collaboration facilities of project partners and managers and end-users are of particular importance. To implement these concepts, advanced continuous integration processes and supporting tools are put in place. ETICS has been extended to fulfill all the requirements with regard to the SCI-BUS project and other industrial partners, resulting in 4D ETICS.An instance of the 4D ETICS portal (etics3.4dsoft.hu) serves as a unified environment for building, testing, software packaging for the SCI-BUS partners needs. Also, this portal acts as a technical communication channel between project partners and allows the project manager as stakeholder to follow the technical work.

The augmented 4D ETICS portal has the following multiple roles in SCI-BUS: It is a software management and project technical collaboration tool supporting organizations in managing the synchronization of developers and teams that are geographically separated It is one way for project managers to follow the technical progress It is a continuous integration and testing environment It is a multi-platform building, testing and packaging infrastructure for the SCI-BUS It has a distributed test execution environment for deployment, API, system tests and others It provides tools and resources to configure, manage and analyze build and test runs It provides a common interface for diverse projects to facilitate knowledge sharing and operations management It has an open repository of configuration metadata, packages and reports. The goal is to share information, but also to reliably store and preserve information It has a plug-in based architecture and APIs to allow integrating ETICS into existing processes and extending it with custom actions

Automated tests are also crucial for a distributed project where more than ten portal developers rely on a common framework (gUSE/WS-PGRADE portal). Firstly, the automated unit tests are implemented by individual developers and these tests are run by the software management tool (4D ETICS) as part of the builds and the continuous integration processes. In addition to unit tests, static analyzers, metric calculation tools and code checkers can be run inside the builds as integrated plug-ins.

figure 1 shows the auto deployment configurations

www.agilerecord.com

23

figure 2 is the result of the gUSE deployment scenario

Moreover, inside the continuous integration process after integrating the individual components, deployment tests will be run. The underlying grid and other middleware infrastructures necessary to run the deployment tests are provided by individual project members and are accessed through the 4D ETICS portal. In addition to deployment tests, scalability, platform, load, stress, and finally user acceptance web tests are going to be implemented. All these tests are run within the 4D ETICS environment. The QA team supports the individual portal developers by creating different kinds of configurations for build, tests and deployment purposes. This way the portal developers could have easy access to the latest releases of the underlying services (gUSE/WS-PGRADE portal) together with all the necessary environment settings. So they could concentrate on their individual additions rather than spending too much time with setting up the environment. As for the release procedure of gUSE services, 4D ETICS offers a way to auto-build software packages based on an SVN repository. As of the next release of gUSE, the developers will move the active development from its internal SVN into SourceForges SVN.

Thus, 4D ETICS can be used to build gUSE packages based on the SourceForge repository. Additionally, 4D ETICS will be used to perform some automated tests based on the packages built. This will ease the life of testers as they will not have to run a number of basic tests. Conclusion. We realized that the introduction of agile concepts such as continuous integration, instant collaboration with project partners and managers (stakeholders), running of automated tests, etc. is absolutely necessary for large distributed projects. However, regarding agility the project is heterogeneous; some of the partners are familiar with agile concepts, others are trying now. The QA team has to offer really useful solutions that every project team could benefit from, and the continuous integration services and collaborating features of the 4D ETICS portalboth fall into this category. Finally, the QA team introduces more advanced agile concepts such as BDD and also recommends tools for applying them.

24

www.agilerecord.com

> About the author

va Takcs currently works as a project manager for 4D Soft Kft. One of her tasks is to work out a comprehensive software engineering service package for IT companies and software development teams. This service package relies on a couple of software engineering and testing tools. One of them is 4D ETICS, the industrialized version of the ETICS project output. Before holding this position, she was the test services related work package leader in the ETICS2 EU FP7 project. Prior to working for 4D Soft, she worked as software engineer in the mobile telecommunication industry. email: eva.takacs@4dsoft.hu Dr. Istvn Forgcs received his PhD in Computer Science in 1993. His research interests include software testing, data flow analysis, slicing and program maintenance. Istvn Forgcs has published articles in leading journals and has spoken at conferences. He was program committee member for leading software engineering conferences, such as ISSTA, ESEC-FSE, etc. After leaving the academy and research, he participated as the inventor and project leader of Y2K.O., the only product which is able to automatically test programs after the Y2K remediation process. As one of the managing directors of 4D Soft Ltd. he led several significant EU and Hungarian projects, for example: Leader of the consortium of JARTA and JARTA+ projects (static regression tester and analyzer for Java) Project leader in JATEST, development of a JAVA continuous testing tool selecting the test cases to be reexecuted Project leader in Hungary of the EU IST 6th Framework, ETICS project (continuous integration tool for large distributed systems) Leader in the JIDEBUG project aiming at developing a debugger based on dynamic influences. After 25+ years in software testing with both academic and industrial experience, his current focus is on agile projects and leading tool developments. email: istvan.forgacs@4dsoft.hu

www.agilerecord.com

25

Distributed Agile: The Maturity Curve

by Raja Bavani

Last month, I came across an interesting question from one of my friends in the industry. He asked, How does a distributed agile team start on a project and make progress in delivering results? I said, It depends, and paused for a while before discussing it at length. The next day at leisure I recollected a series of incidents from one of my previous agile projects and created a visual on how my team matured over a period of time. This project had multiple release cycles and hence ran over a period of three years. We had two teams a team of 20 engineers in India and another team of 5 in the US. Right from our initial struggles

to adopt Agile I reflected on the way we matured. Also, I thought about what I would do differently if I were to start all over again. Let me share my thoughts and conclusions in this article. In simple terms, adherence to the Agile Manifesto and Agile Principles is the essence of Agile. Agile teams choose either a popular methodology (e.g., Scrum) or put together a methodology that follows agile principles and practices. In reality it takes several months for agile teams (either collocated or distributed) to mature and reach the other end of the spectrum.

Improvising
Short iterations (<=4 weeks) Delivery of working software Reviews & Retrospectives Team members use email, chat, phone, meetings for daily interactions Sandboxes (Dev, Staging, Test) Manual Testing Tools for Configuration Management and Defect Tracking Coding Standards Build - Once or twice a week

Practicing
Goal or Theme for Iterations Tracking of Velocity, Burn down Fulltime Leader (or Scrum Master) Team members are experienced in Agile Effective use of communication tools Robust sandboxes Tool for Iteration/Release Management Rigor in resolving queries Code Refactoring Build Scripts, Daily Build

Streamlined
Clear definition of done (DoD) Task Boards, Sticky Notes, Video Conf Confidence in Estimation Technical Debt Management Automated Unit Tests Static Analysis Tool Reusable Test Data Test Automation Defect Analysis Exploratory Testing Automated Build & Deployment Release Management

Governed
Prioritized Product Backlog Change Management at all levels Governance Meetings Knowledge Management Focus on long term product roadmap Additional Metrics related to Build Management, Code Quality, Testing, etc.,)

Matured
Application of Metrics in Analysis and Prediction Periodic Governance Meetings Continuous availability of infrastructure Decision on using TDD and other advanced techniques More than 60% automation of tests Defect Prevention Frequent Builds (once or several times a day)

0 to 2 months

2 to 4 months

4 to 6 months

6 to 12 months

12 to 18 months

Figure-1 Maturity of Distributed Agile: The Past

26

www.agilerecord.com

Over the past eight years, I have seen many projects transitioning through these levels as shown in Fig-1, which is nothing but a refined form of the visual I created. In this figure, the duration specified for each level is the time taken from the beginning of a project or group of projects to reach that level. In distributed projects, because of multi-site communication and coordination, the first two months lapse sooner than expected. This is the crucial period that requires a lot of attention in making the right start in projects. Looking back, my findings are: 1. The longer you stay at the first two levels, the worse it gets. Nowadays, 4 months is a longer time than it used to be.

2.

If your comfort zone is Improvising, beware. Either your agility will dilute or your team and other stakeholders will express dissatisfaction because of your teams inability to deliver results. Moving through the second and third levels involves a steep curve. It is a complex affair in distribute agile. Experience and availability of experts can help you go through this tough journey. Taking a long pause after reaching the third level is not a good idea. It is wise to push through level four and five as well. These levels are essential to deliver results in distributed agile projects.

3.

4.

Improvising
Short iterations (<=4 weeks) Delivery of working software Reviews & Retrospectives Team members use email, chat, phone, meetings for daily interactions Sandboxes (Dev, Staging, Test) Manual Testing Tools for Configuration Management and Defect Tracking Coding Standards Build - Once or twice a week

Practicing
Goal or Theme for Iterations Tracking of Velocity, Burn down Fulltime Leader (or Scrum Master) Team members are experienced in Agile Effective use of communication tools Robust sandboxes Tool for Iteration/Release Management Rigor in resolving queries Code Refactoring Build Scripts, Daily Build

Streamlined
Clear definition of done (DoD) Task Boards, Sticky Notes, Video Conf Confidence in Estimation Technical Debt Management Automated Unit Tests Static Analysis Tool Reusable Test Data Test Automation Defect Analysis Exploratory Testing Automated Build & Deployment Release Management

Governed
Prioritized Product Backlog Change Management at all levels Governance Meetings Knowledge Management Focus on long term product roadmap Additional Metrics related to Build Management, Code Quality, Testing, etc.,)

Matured
Application of Metrics in Analysis and Prediction Periodic Governance Meetings Continuous availability of infrastructure Decision on using TDD and other advanced techniques More than 60% automation of tests Defect Prevention Frequent Builds (once or several times a day)

0 to 2 months

2 to 4 months

4 to 6 months

6 to 12 months

12 to 18 months

Figure-2 Maturity of Distributed Agile: The Present & Future

There are several ways to tweak these transitions in order to improve results during the early stages of agile projects. In a way, moving some of the items into the first level will provide us with immense benefits. Obviously, we need to be proactive in doing certain things early as shown in Fig-2. This is just the beginning and the following should be considered: 1. It is good to have agile aware team members. However, it is better to have at least one or two team members who are experienced in agile. Besides, the availability and support of agile experts or coaches will have a positive impact on the teams performance. It is good to have email, chat, phone and other communication mechanisms. Effective use of communication tools is necessary to ensure efficiency. Agile teams cannot afford to use chat for lengthy conversations. They must know when to communicate over the phone.

3.

It is good to have sandboxes (or environments) for development, staging and testing. However, it is necessary to ensure that the environments are robust. Introducing a tool for iteration/release management is very important. The build process needs to stabilize during the initial month. Prioritized product backlog needs to be maintained from early stages. Change management is essential. Otherwise the teams may not have a clear idea on how changes can be managed in practical situations. There has to be a governance team (especially in case of distributed agile projects) with a commitment to have review meetings at regular intervals. Governance in distributed team is paramount for timely decision-making in variwww.agilerecord.com 27

4. 5. 6. 7.

2.

8.

ous areas that are outside the purview of the project team. A very good example is initiating and providing consistent support or sponsorship for the visits of team members at all levels across sites. In distributed Agile, there are several factors that influence the ability of teams to become better in a reasonably short duration. Some of the key factors that consume significant efforts in communication and coordination include, Refinement of user stories: When user stories consume significant effort to refine, Agile teams struggle to find adequate time to focus on implementing engineering practices in the right way. Engineering practices: When there is no consistency or commonality across sites in implementing engineering practices such as unit testing, static analysis, continuous build, test automation, etc., teams will have to spend considerable time to make these work. Technical debt management: When teams do not have a common understanding about managing technical debt, the situation will lead to severe technical risks in the project. Such risks will surface within the first three or four months from project initiation and hence will consume the efforts of team members in paying back technical debt rather than maturing existing practices. Work standards: Differences in work standards mean differences in implementation of process and engineering disciplines across sites. This is the so-called double standard phenomenon. In distributed agile teams, this is not acceptable and can lead to a situation where teams cannot work toward maturing their practices. Long-running projects provide an opportunity to improvise, practice, streamline and mature over a period of time. This means an opportunity to maximize the benefits of continuous improvement. How do we execute projects that need to be completed in a short duration of 6 months or less? We can do this by being proactive as shown in Fig-2. Also, this means that projects need to rapidly transition from one end of the spectrum to the other. This is possible when teams exhibit an agile mindset, belong to an ecosystem that has experts who can coach agile teams, and have the necessary infrastructure to execute agile projects. I am sure you are able to relate this discussion to your experience. In essence, the objective of this article is to emphasize that projects belong to a maturity spectrum or maturity curve. Project sponsors and stakeholders need to understand this aspect and encourage teams to move towards higher maturity levels in order to gain benefits from Agile. In distributed Agile, this becomes very complex. However, with experience and capabilities, one can demonstrate success.

> About the author

Raja Bavani is Technical Director of MindTrees Product Engineering Services (PES) group and plays the role of product engineering evangelist and Agile coach. He has more than 20 years of experience in the IT industry and has published papers at international conferences on topics related to code quality, distributed Agile, customer value management and software estimation. His areas of interests include global delivery model, Agile software development, requirement engineering, software architecture, software re-use, customer value management, knowledge management, and IT outsourcing. He is a member of IEEE and IEEE Computer Society. He regularly interfaces with educational institutions to offer guest lectures and writes for technical conferences. His product engineering blog is available at http://www.mindtree.com/blogs/category/software-product-engineering. His articles and white papers on Agile software development are available at: http://mindtree.com/category/tags/agile. He can be reached at raja_bavani@mindtree.com.

28

www.agilerecord.com

Call for Papers until February, 26th!

November 1922, 2012 Potsdam (near Berlin), Germany

www.agiletestingdays.com

Your Perspective, My Perspective and Retrospective Who Wins?

by Mithun Kumar S R

Retrospective meetings are part of the agile framework to evaluate the pitfalls the sprint had and to take remedial measures as well as to identify the success stories and keep them going. Many times, however, retrospective meetings do not yield the desired result due to various reasons. This article sheds light on them. The forbidden U word Team members get into offensive mode when provoked with the YOU word. Blaming one another is the easiest way for failing the retrospective and to increase personal grudges. This blame game could potentially spoil the sport. Care should be taken to focus on actions rather than on persons and on the ways in which mistakes can be rectified or omitted. Globally dispersed teams Teams which are geographically dispersed pose a problem with finding a common time for meetings, especially when the time difference is large. Although participation is possible virtually, the value addition that all team members make might not be on an equal scale. One example to cite is that an otherwise proactive team member was not participating in the retrospective meetings though she was on the call. It took some time to figure it out that this meeting was held even before dawn at her local time and it was difficult to get into the meeting mode on par with others. Though a very minor issue which often is neglected, taking into account human behaviors and the environments they are in for active participation can get better results. Taking the views through mails beforehand can be one way of bridging the time gap and of also taking everyone into account.

Boss o Phobia Inhibition of team members to speak out increases when the boss is around, especially when it comes to saying something unpleasant about the project, which might be the boss brainchild. As far as possible avoid people managers, who account for appraisal, outside the meetings. Even if that is inevitable, set guidelines and protocol to ensure that everyone, including the managers, abide by them. Also conditioning the managers to hear unpleasant comments and improvising the process can be inculcated. Silent spectators A few people tend to shy away from speaking in retrospectives, possibly due to the natural fear of speaking in public or for being bullied by their colleagues later on. This may lead to the potential loss of information that they have buried in their minds. Pave the way for creating an open environment so that even shy characters are given an opportunity to participate. If required, the scrum master can make it mandatory for people to speak at least for a turn to say the good things which worked and those which didnt. Dominators It can be just as difficult to keep dominating people quiet at meetings as it is to encourage shy people to speak up. A few tend to swallow the time allocated to others and make a speech for the entire time available. This can also be seen with telephone meetings where members meeting in a conference room may ignore the lone member connected through a call and not give him/her an opportunity to speak. The scrum master should be quick enough to identify if the meeting is moving in such direction and act to give enough time for everyone.

30

www.agilerecord.com

Short-term memory Human memory is usually short-term and only the latest events stay fresh. During retrospectives, sprints over time spans of 3 to 4 weeks may have issues connected to activities done early on, which may have been forgotten. Sometimes only those issues that have occurred just before the meeting are highlighted. It must be ensured that any important events that had occurred earlier are not omitted. It could be one of the best practices for the team members to note the points on a daily basis in a work diary and use this for the retrospective meeting. Time boxing As the iteration and the functionalities increase, points to be discussed in the retrospective also increase. Noting the time and boxing it to the allotted time is essential to optimize the effort used. Identifying time wasters is important to channel efforts and utilize the available time to the best possible extent. All in one day approach Even though its important to have retrospectives during the sprint, its just as important to not link these together with sprint planning meetings in a back to back fashion. Projects that have sprint retrospectives on Monday mornings and sprint planning in the afternoon tend not to perform well. Projects can think about completing sprints by Thursday and conduct the retrospectives on Friday. Teams can again meet on Monday and have the sprint planning meeting for the next sprint and start it on Tuesday.

Not acting on the committed points Though many points come up during retrospective meetings, they are easily forgotten in the next sprint because of other activities having higher precedence. Tracking the noted points from the retrospective and acting on them is the key point to invoke interest with everyone for better participation in the future and for retrospectives to be taken seriously. Retrospectives offer a great opportunity to turn back, look at how the team has performed and take remedial actions at an early stage. Conflicting points of view turn disastrous in most teams because of personal attacks. Nevertheless, a little effort could turn around the differences to compliment each team members capability and progress in a better way for the benefit of the project.

> About the author

Mithun Kumar S R works with Schneider Electric on its Building Automation products. He previously worked with Siemens on MRI scanners and with Tech Mahindra for a major Telecom project. An ISTQB Certified Test Manager, he regularly coaches certification aspirants. Mithun is also a LONMark certified Professional and holds a Bachelors degree in Mechanical Engineering and Masters in Business Laws.

The tool for test case design and test data generation
Pitopia / Klaus-Peter Adler, 2007

www.casemaker.eu

Why Agile Works

by Martin Bauer

Agile works and it works well. But so can Waterfall, RUP and home grown methodologies as well as having no particular method at all. And they can all fail. The question is: Why does Agile work? What is it about Agile that is different? What is it about Agile that provides a better chance of being in the 32% of projects that actually succeed?1 And, most importantly, can it work for you? What is Agile? If youre willing to embrace Agile, it pays to understand what it is, whether its right for you and how to avoid the common mistakes that lead to Agile adoption horror stories. Lets start with what the term Agile actually means. In my experience, when people use the term Agile, they are either referring to a particular Agile methodology, such as Scrum, or to particular techniques used in Agile methodologies, e.g., daily stand-ups, user stories or pair programming. Ive also heard people refer to agile development without necessarily elaborating on what exactly they mean by that. However, in general it seems that, more often than not, people most likely refer to a scrum-like methodology when they use the term Agile. Of course, thats somewhat misleading. The origin of the term Agile comes from the Agile Manifesto that defines four values and twelve principles. The methodologies that are considered Agile are particular methodologies that attempt to, for better or worse, embody the values and principles set out in the Agile Manifesto. The first and most common mistake I find is that people think Agile means Scrum or XP or FDD (Feature Driven Development). Well, it doesnt. Separating out the term Agile from Agile Methodologies is the first and probably the most important step in understanding and becoming Agile. Lets look at a few of the principles of the Agile Manifesto and compare them to the practices defined in Scrum and FDD. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Scrum has the concepts of sprints, typically a 2 to 4 week period in which the team commits to building a deliverable working product. FDD has the concept of feature sets, and features. A feature is between 2 hours and 2 weeks of work. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.

In Scrum, at the end of a sprint, theres a sprint review meeting where the stakeholder gets to view the working product and is able to make changes to it which is then added to a future sprint. In FDD, when a feature set is delivered, it is demonstrated to the stakeholder. If during that demo changes are required, they are captured as new features to the existing feature set. Business people and developers must work together daily throughout the project.

In Scrum, there are daily meetings called daily stand-ups where all core roles, Product Owner (stakeholder or client), the team (e.g., developers) and the Scrum Master (similar to a traditional Project Manager) are present. In FDD, before development begins on a feature, the domain expert (often a key stakeholder) walks the team through where the feature fits into the overall solution. Whats important to understand is that Agile is actually about values and principles. Agile methodologies are particular ways of implementing those principles. Some agile methodologies deal with all of the 12 principles, some deal with only a subset. An approach taken by Scrum might work well in one situation and poorly in another, the same with approaches taken by FDD or XP. Once we understand the distinction between Agile and agile methodologies, we are free to choose the method that is right rather than assuming Agile means Scrum and therefore to be Agile we have to do what Scrum says, even if we dont agree with it or it doesnt make sense in our particular situation.

1 The Chaos Report, 2009 http://www1.standishgroup.com/newsroom/ chaos_2009.php

32

www.agilerecord.com

Knowledge Transfer The Trainer Excellence Guild

Specication by Example: from user stories to acceptance tests by Gojko Adzic

Course Description: The winner of the MIATPP award presents: This two-day workshop teaches you how to apply emerging practices for managing requirements, specications and tests in agile and lean processes to bridge the communication gap between stakeholders and implementation teams, build quality into software from the start, design, develop and deliver systems t for purpose. The workshop is aimed at testers, business analysts and developers and based on Gojko Adzics books Specication by Example and Bridging the Communication Gap. Through facilitated exercises and discussion, you will learn:
the key principles of specication by example, behaviour-driven

how to ensure a shared understanding of testers, developers, business how to extend specications with examples to create a single source how to avoid functional gaps and inconsistencies in specications how to run specication workshops to facilitate collaboration best practices for designing specications and automating them as how to create a living documentation system to facilitate change how other teams, from small web startups to large distributed teams how to apply this process in your project

analysts and stakeholders on future functionality of truth for testing and development and tests

tests

and improve your process long-term

development, effect mapping how to create and maintain effective specications and tests in agile and lean projects

in investment banks, apply specication by example in their contexts

Date March 2223, 2012

Place Berlin

Price 1,200 + VAT

TDD in .NET by Lior Friedman

Course Description: This three-day program provides a highly interactive exploration of unit test automation, principles and practices. Companies such as Microsoft, Google, and IBM have already realized the potential that lies in Unit Test automation. Following these practices reduces the amount of defects in your software decreasing the effort involved in product development and result in more satised customers.

Learn how to use frameworks for test writing and how to isolate your code in an efcient and easy manner.

Date May 0709, 2012

Place Nrnberg, Germany

Price 1,450 + VAT

Website: http://www.diazhilterscheid.de/en/knowledge_transfer.php

What is it about Agile that makes it work? Now that we understand what Agile means, the next thing to understand is why it works. There are a number of reasons, but one stands out above all, and that is that its focused on delivery. Seems obvious, doesnt it? After all, the main reason for a methodology is to help you deliver a result. right? Wrong. Thats the key difference between Agile and traditional methodologies. If you look at Agile, the values are the following: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

The Agile Manifesto recognizes that while there is value in processes, documentation and plans, theres greater value in individuals, and in working software. If you look at Prince2, the defacto standard methodology in the UK, its key features according to its website2 are: Focus on business justification A defined organization structure for the project management team Product-based planning approach Emphasis on dividing the project into manageable and controllable stages Flexibility to be applied at a level appropriate to the project.

3 months between the client signing off the specification and them seeing a piece of working software, and in that time, they had forgotten half of what they had asked for in the first place. Whether its FDD, Scrum or XP, collaboration is key. The principle of Agile that best captures this is Business people and developers must work together daily throughout the project. Why is this so important? For me its to ensure everyone is on the same page. It avoids what I call the over the fence mentality. Thats where one person fulfills their part of the project, e.g., writing the business case, writing the requirements, writing the functional specification and hands it over the fence to the next person who does the technical analysis, does the development, does the testing...etc. Each person takes responsibility for their part of the process, but just that and only that. They pass it over the fence to the next person and it becomes their problem. For example, if an issue arises with a particular element of the functional specification, the business analyst may have moved on and its up to the developer to resolve this issue. If they get it wrong, they blame the business analyst who may or may not be around. And more importantly, the key stakeholder may only find out months later. Its the not my fault syndrome and one thing you can be sure of, its NOT going to be the stakeholders fault. Agile ensures the risk of this is minimized by having regular interaction on a daily basis. Issues surface earlier and are easier to solve because business people are involved during the process. Knowing the problem Delivery and collaboration are the key to what makes Agile work. Making Agile work for you, however, isnt as simple as saying lets go Agile. Theres a bit more to it than that. As John Dewey3 said, a problem well stated is a problem half solved. Clearly understanding the challenges you are facing in delivering projects is the first step. Based on this understanding, you are well placed to evaluate the different agile methodologies and practices to determine which one is best suited to solve your problems. It might be the case that your challenges arent with the current methodology, but that theres actually a people problem or management setting unrealistic deadlines. Using an agile approach isnt going to make the impossible possible. If the fundamental issue is that timeframes and resources arent sufficient to deliver the project, Agile isnt going to solve the problem. It might make it less worse, but its not going to change a fundamentally flawed project. As Brooks stated long ago, there is no silver bullet4 and Agile is no exception. Picking the right agile methodology If you are clear on what the key issues are, the next step is to pick the right agile methodology for your situation. A good place to start is looking at the Cockburn scale5. As not all projects are alike, so too not all agile methodologies are alike. The scale and nature of a project will determine how formal an approach is required and which agile methodology is best suited. Cockburn looks at projects in terms of size, i.e the number of people, and
3 John Dewey US Philosopher (1859-1952) http://en.wikipedia.org/wiki/ John_Dewey 4 5 http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/Cockburn_Scale

Not once does it mention actually delivering an end result. Thats not to say Prince2 is not a good way to manage projects, it certainly has its strengths, but a focus on delivery is not one of them, its focus is on control. Agile states Working software is the primary measure of progress, Prince2 focuses on business justification. If the problem you want to solve is not being able to deliver on time and budget, its pretty obvious which path to take. This distinction between delivery versus control deserves further scrutiny. The Chaos Report states that for all projects in 2009 44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used. Controlling a project that is late, over budget or with less features than required, let alone being cancelled, is somewhat pointless. Delivering working software is the point. Agile doesnt state specifically how to do that (Agile methodologies do), but does define the principles that will lead to results. Thats the key distinction between traditional and agile methodologies: the focus on delivery. After delivering, the next main reason why Agile works is the recognition of the value of collaboration. This is well illustrated in the practice of daily stand-ups in Scrum. Every day, the core members of the team meet. Ive seen projects where theres been
2 http://www.prince2.com/what-is-prince2.asp

34

www.agilerecord.com

Online Training ISTQB Certied Tester Foundation Level (English & German) ISTQB Certied Tester Advanced Level - Test Manager (English) ISTQB Certied Tester Advanced Level - Test Analyst (English) ISTQB Certied Tester Advanced Level - Technical Test Analyst (English) ISEB Intermediate Certicate in Software Testing (English)

Our company saves up to

60%
of training costs by online training.
The obtained knowledge and the savings ensure the competitiveness of our company.

www.te-trainings-shop.com

iStockphoto/Yuri_Arcurs

criticality, i.e. the impact if something goes wrong, will there be loss of life (e.g. software for car safety) versus loss of comfort (e.g, the search feature on a website is not working). Theres a big difference between a project with a team of 100 working on anti-lock braking software versus a team of three working on a website for a new soft drink. The following figure takes the Cockburn scale and overlays the different agile methodologies and where they are best suited.

As the diagram indicates, XP works better with smaller projects, FDD with medium to large and Scrum applies across the board. That being said, dont forget that just because this diagram indicates that Scrum can work for all size and importance of projects, doesnt make it right for your particular situation. If you deal with projects that are larger in nature, it simply indicates that XP may not be best suited. Implementing Agile If the first step is to understand Agile, the second to understand your challenges, and the third to select the methodology best suited to your particular situation, the fourth and most difficult is to introduce the new methodology into your organization. The difficulty of introducing change should not be underestimated as Machiavelli observed many centuries ago. There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things.6 Change is difficult, scary and unsettling, but without change there can be no improvement. There are so many challenges in introducing change that entire volumes have been dedicated to the subject. Change management is an entire discipline in itself and cannot be easily summarized. The best approach to change will depend on the particular situation just as the best agile methodology will depend on the particular types of projects. In my own experience7 I faced two major challenges. It was back in 1999, before the Agile Manifesto was even written. I was Development Manager for a large web development firm (over 150 staff). There was a general agreement that we needed to do bet6 The Prince, Niccolo Machiavelli, 1532 7 http://www.martinbauer.com/Articles/Successful-Web-DevelopmentMethodologies

ter, our record in project delivery was as bad if not worse than the industry standard set by the Standish Group8 at the time. The development team had evaluated a number of methodologies and found one they wanted to use, FDD. It was up to me to convince the rest of the organization that we should give it a try. That was a lot harder than it seemed. Because I had, somewhat foolishly in hindsight, done the evaluation of methodologies as a part of the development team only, getting buying from the Business Analysts and, more importantly, from the Project Managers was difficult. It took a series of meetings to even get acceptance to give it a go on a pilot project. But I didnt want to fall into the trap that many people make do when trying something new, I wanted to get training first. This meant spending money, not a small sum of money either, as I needed to make sure I had the key developers, business analysts and project managers at the training to ensure we all knew what we were doing. Funding was nigh impossible and I had to raise the funding myself (out of a previous business I had owned) to get started on the understanding I would be paid back by my employer at the next quarter. Fortunately my punt paid off (yes, I was paid back) and we had a cross-discipline team who understood how our chosen methodology worked. This lead to a pilot project and over time we got better at project delivery, slowly but surely. An important point to note is that after our training, we realized that FDD wasnt going to work perfectly for us, we would need to make some changes to the methodology to adapt it to our environment. As a part of a group workshop, we decided what elements we would adopt and what we would adapt and what we would leave out. Being selective about what we took from FDD helped us to ensure it would work. I would be lying if I said that we applied this adapted approach to all projects, but the underlying mindset was definitely in the forefront when we tackled each project, and because of that we did better as a whole. It was more of an evolution rather and an overnight revolution. Change takes time, expecting to get instant results because youve decided to go Agile is only going to lead to disappointment. Another aspect of change to keep in mind is that its rare to try something new and get it right the first time. Learning new skills takes time and persistence, making mistakes and learning from them is a part of the process. Trying an agile methodology for the first time may lead to worse results than the usual approach as people learn how the methodology works in practice. Ideally theres both training beforehand and someone with experience on hand when first trying to implement an agile methodology to help guide you through the challenges that will inevitably arise when first trying something new. Setting expectations upfront that its a learning experience will help to avoid the backlash when it doesnt work perfectly and prevent the natural inclination to revert to a known approach. To sum up, Agile works because it focuses on what matters, delivery and collaboration. Making it work is the hard part. The first step is to understand the issues you are currently facing and seeing if Agile, whether its a particular methodology or a set of
8 http://www.standishgroup.com/

36

www.agilerecord.com

Agile practices will help you solve the issues at hand. If so, then you can look at how to move towards an Agile approach, preferably with expert support, before, during and after to help make the transition. Knowing what the problem is and how you intend to solve it helps sets more realistic expectations and a greater chance of Agile helping. Blindly adopting an Agile methodology and assuming its the answer to all your problems is mistake. Agile does work, but its upto you to make it work.

> About the author

Martin Bauer is the Programme Manager for Vision With Technology, an award-winning digital agency based in London. He has over 15 years experience in Web development and content management. Mr. Bauer is the first certified Feature-Driven Development Project Manager, an advocate of Agile development and a qualified lawyer. His experience covers managing teams of developers, business analysts, and project managers. Mr. Bauer can be reached at martin@martinbauer.com; Website: www.martinbauer.com.

Testen fr Entwickler
Beschreibung Whrend die Ausbildung der Tester in den letzten Jahren groe Fortschritte machte es gibt mehr als 13.000 zertizierte Tester alleine in Deutschland wird die Rolle des Entwicklers beim Softwaretest meist unterschtzt. Dabei ist er beim Komponententest oftmals die treibende Kraft. Aus diesem Grunde ist es wichtig, dass auch der Entwickler Grundkenntnisse in Kernbereichen des Softwaretestens erlangt. http://schulung.diazhilterscheid.de

800,00 zzgl. MwSt

iStockphoto.com/arlindo71

Termine* 12.04.1213.04.12 Berlin

2 Tage

*nderungen vorbehalten

www.agilerecord.com

37

Scenarios of Agile Success

Two Fortune500 Companies tell their story
by Alex Adamopoulos

In recent years, agile adoption has proven to be beneficial for numerous companies worldwide. Today, companies are looking at IT to improve project delivery success, reliability and increase productivity, whilst taking out cost. As organizations began to see the value of IT from a business process and cost-saving perspective, they began to look at how to change the relationship between IT and the business, and how to best improve the overall flow of value to the customer. Below are two short stories about large international businesses that have found and continue to find value in agile, but have also had to overcome obstacles of the wider organization and be mindful of a couple of best practices in order to achieve success. In the first scenario we have a more concrete example of how a global logistics company has applied agile thinking to begin an enterprise-wide transformation effort. In the second scenario we discuss the common approach of many organizations that still see agile practices best suited for software development projects. Scenario I: Information technology plays a huge role in enabling organizations to improve the way they serve their customers, by turning ideas for improvement into solutions. To beat the competitors, you need to be able to develop solutions faster. Speeding up IT development is the main focus for this global logistics company. The emphasis is to help apply new thinking to the IT development process. The goal is to make their systems more responsive to change. The team has worked with both the Business and IT delivery teams, and made substantial changes to the way they develop solutions focusing on three outcomes: Value, Flow and Quality. One of the most important systems for the company is their global booking application. Approximately 4,500 staff currently use the system to make up to 25,000 customer bookings per day. 38 www.agilerecord.com

Its important that this system is reliable; but it also needs to be adaptable, in order to better serve customers. The business receives hundreds of ideas on how to make the system easier to use, to produce better results for customers. However, it was taking far too long to implement these ideas, leading to frustration for the business and customers. Improving prioritization The new approach gives us an objective framework to prioritize requirements, irrespective of who raises them. One of the business representatives says: We have become better at prioritizing new requirements. We have started talking about the changes most important to the business instead of my changes. And, most importantly, the new process allows us to react faster to market and customer demands. Reduce size of requirements To improve the development process, one of the changes implemented was the process of breaking down selected ideas into bite-sized requirements. This helps to smooth the flow of work through the development process, resulting in more manageable, sustainable delivery of changes with reduced risks. The Release Manager says: Before implementing the changes, we had a long and drawn-out process for scoping and design. Requirements would take a long time to go through the development pipeline. The new framework allows us to implement smaller changes much faster to keep up with the changing business and customer needs. Early signs are positive The above changes, alongside others based on the Value, Flow, Quality framework, are already starting to make a big impact on the speed of IT development. As a result of these changes to our global booking system, we have made a huge reduction in the average time it takes to go from a raw business idea to a working solution. IT Director, global logistics company

Scenario II: Scenario II discussed a US insurance giant that recently decided that introducing agile into their enterprise at the project level was necessary in order for the company to launch a new and improved product for their field organization within a limited timeframe. This companys CIO had participated in an executive forum where he learned how other large organizations had successfully used agile as a strategic differentiator and how the use of agile significantly improved traditional KPIs, such as time-tomarket, competitive advantage and potential market share. Misunderstanding agile The CIO went on to communicate openly within the organization and to some media outlets that IT needed to be viewed as a partner to the business and an investment area vs. a cost center. He stated emphatically how the value of IT would be seen in cooperating with the business as an advisor and enabler. This CIO had several other goal-oriented statements, but was clearly motivated by what he saw at the executive forums he attended. What happened next is the puzzling part. Instead of being involved in understanding how agile could help enable the organization, the CIOs remit was passed to procurement to find an agile vendor and get someone in to work with the team on the product they were meant to improve. While this seems entirely normal, the reality is that this scenario represents a common misunderstanding of how agile works or rather what it is. Not all about the tech The genesis of agile suggests it is a software development methodology, but it has actually gone beyond that and now needs to span organizational boundaries. Where its being successfully deployed, its also a discipline, a philosophy, a way of working and a set of practices, principles and values that are important in what products and services are provided and how these are delivered to customers. In some cases, the principles are being applied in a way that doesnt look like the methodologies created a decade ago, but the outcomes of Value, Flow and Quality are still being delivered. Many organizations that want to leverage the good they hear about agile introduce it at the project level without looking at the wider strategy and its possible application beyond that project. Another often overlooked point is that companies will choose a vendor to come do it for them instead of enabling their own people through the process. Sometime later a product is launched but the client team has learned very little about the principles used with the exception of having participated in the common practices you expect in an agile run project. The external dependency continues and the opportunity for empowering the companys employees, exploiting their creativity and understanding how to get beyond that project is diminished.

> About the author

Alex Adamopoulos is an executive with more than 20 years experience in global services organizations. He has extensive international experience with a deep understanding of culture, work, and life ethics especially in relation to establishing alignment and crossing cultural barriers. Over the years, Alex has brought know-how and practical business experience to companies that want to excel and compete globally. With a focus on performance measurement, business value and bottom-line profitability, Alex has successfully applied working models and practices to accelerate the solutions and strategies of companies to drive results.

www.agilerecord.com

39

Can agile be certified?

Find out what Aitor, Erik or Nitin think about the certification at www.agile-tester.org

Training Concept
All Days: Daily Scrum and Soft Skills Assessment Day 1: History and Terminology: Agile Manifesto, Principles and Methods Day 2: Planning and Requirements Day 3: Testing and Retrospectives
Sergejy Galushko Fotolia.com

Day 4: Test Driven Development, Test Automation and Non-Functional Day 5: Practical Assessment and Written Exam

27

tra

inin

gp

rov i

de

rw

orl

dw

ide

Supported by

We are well aware that agile team members shy away from standardized trainings and exams as they seem to be opposing the agile philosophy. However, agile projects are no free agents; they need structure and discipline as well as a common language and methods. Since the individuals in a team are the key element of agile projects, they heavily rely on a consensus on their daily work methods to be successful. All the above was considered during the long and careful process of developing a certification framework that is agile and not static. The exam to certify the tester also had to capture the essential skills for agile cooperation. Hence a whole new approach was developed together with the experienced input of a number of renowned industry partners.

Barclays DORMA Hewlett Packard IBM IVV Logic Studio Microfocus Microsoft Mobile.de Nokia NTS Oc SAP Sogeti SWIFT T-Systems Multimedia Solutions XING Zurich

Agile methods for (phase-oriented) test managers?

by Jessica Schiffmann
For the future role of test manager and tester, agile methods gain in importance, both in agile and in phase-oriented development processes. This is justified by the increased use of agile methods, with the largest proportion for Scrum. According to a Forrester survey of 2009, 35% of companies work with an agile method, with 10.9% of the total votes going to Scrum [CIO2010]1. In the same survey, 50% of respondents indicate that they use not one agile method, but a mix of different agile methods. There are also projects that use agile methods in addition to their phase-oriented development process; Dave West summarizes this fact in the formula Water-Scrum-Fall Is the Reality [West2011]2. What are the reasons for the broad acceptance and high penetration of agile methods (e.g., Scrum) and their mixture? How can this be reached in phase-oriented management models, or specifically in phase-oriented test management? Due to short release cycles in agile projects, test automation is considered as indispensable and techniques like test driven development, unit testing and automated acceptance tests are used. All of them are welcome to the test manager of a phaseoriented development process. However, the techniques are the same in the different process models, so considering different process models is not necessary. Scrum consists of three basic roles: the team (cross-functional; implements, the increment of the product), the product owner (manages the requirements in the so-called product backlog) and the ScrumMaster (ensures that the team can work productively). All three roles together form the Scrum team. The ScrumMaster is responsible for ensuring that all participants understand the Scrum process and comply with it [Schwaber2010]3. Since controlling the test process is the responsibility of the test managers, the methods of a ScrumMaster are probably the most appropriate for a test manager. Additionally the (phase-oriented) test manager is responsible for test resources and testware [Spillner2005]4. Besides ensuring the understanding and implementation of the Scrum process, the main tasks of the ScrumMaster are to support the team when communicating with each other, keeping out external influences during the sprint and the cooperation between team, product owner and management. Scrum defines itself as empirical process control [Schwaber2010]5 and rests on three pillars: transparency, inspection and adaptation. Possible methods for creating transparency and inspection are examined in the following with regard to their potential in phaseoriented development methods. Since the self-determination of the team is a key point in Scrum, the possible influence for test management will be discussed. Methods for creating transparency Transparency in Scrum is ensured by different meetings and artifacts, e.g., in the daily scrum meeting (Daily Scrum). All team members who work on a user story report to each other. Problem areas will be noted and resolved (mostly by the ScrumMaster). Is this meeting possible in phase-oriented process models? Scrum teams are smaller (7 +/- 2) and the meeting is short (max. 15 minutes). In larger teams the time can quickly be longer. Transparency, however, will only be reached if all team members actively participate in the discussion. In Scrum com3 Schwaber, Kenn; Sutherland Jeff; SCRUM Guide; 2010

1 Nicolas Zeitler; Agile Anwendungsentwicklung Scrum verlangt neue Teamarbeit; March 2010 http://www.cio.de/strategien/methoden/2224795/ 2 West, Dave; Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today; http://www.forrester.com/rb/Research/water-scrumfall_is_reality_of_agile_for_most/q/id/60109/t/2; 2011

4 Spillner, Andreas; Linz, Tilo; Basiswissen Softwaretest; dPunkt Verlag; 2005 5 Schwaber, Kenn; Sutherland Jeff; SCRUM Guide; 2010

42

www.agilerecord.com

panies,, projects with more than 15 people are organized as multiple Scrum teams, each focused on a different aspect of the product development, with close coordination of their efforts [Sutherland2007]6. Splitting the team into sub- teams and holding a meeting to improve communication and transparency could be a good idea, but one person has to attend all meetings in order to get the whole picture and perhaps give short summaries in the different meetings. Another possibility for the test management to get transparency from a daily meeting could be to hold a short meeting with the all testers in the test phase. All persons involved in testing give a short feedback of what they are doing. This may possibly be very helpful to inform all test team members of any show-stoppers or other important defects and changes, which need retesting. At any time the work which should be done for the product (Product Backlog with all the currently known and prioritized user stories), and in the next development cycle in Scrum called sprint (Sprint Backlog and the demonstration of the next user stories in the Sprint Planning Meeting) is known to all team members. In the sprint backlog the work packages are written down in user stories. Mike Cohn [Cohn2009]7 suggests that the acceptance criteria could also be written down on the card, so that not only the test case design simplified, but also so that the programmer could be reminded of a situation which would otherwise have been forgotten. Furthermore the work in development is known, as the tasks which are worked on and which are in the queue are all shown on a board (electronic or mechanical), the so-called task board. As the work is visible for all team members, helping hands can be offered, synergies are shown and feedback can be provided. The advantage for test management is that the completed functionalities are easy to identify, so that it is clear whether a part of the application is being reworked and what the content of the current sprint is. All this information is helpful for getting the right test priorities and test strategies (explorative testing, unit testing, etc.). Another approach is to add a test board where all necessary steps for testing a user story are shown as tasks to the Scrum room [Carter2010]8. In this article, the automated tests tasks and the steps for testing (infrastructure assembly, test case design, etc.) are added to the test board just like errors found by automated regression tests. The work which is already done in the sprint is visualized on the Sprint Burndown Chart. Everyone is informed about how much work is already done, and if the sprint objectives can be reached. The same could be done in a GANTT chart (or something similar) for phase-oriented development. A phase-oriented project has more work packages than one sprint of a Scrum project, and
6 Sutherland, Jeff; Schwaber Ken; The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process; Draft 10/14/2007 7 Cohn, Mike; User Stories Applied; Addison Wesley; 2009

often a work package may only be finished at a later stage; it can be a difficult (and confusing) task to visualize that e.g. the first half of a work package is done and the other half will be done later. Breaking tasks into sub-tasks and visualizing them for phase-oriented projects means extra effort and extra work for keeping the overview. Methods for inspecting the product developed In phase-oriented projects, the requirements are defined at the beginning and after that the implementation starts. The acceptance test by users or stakeholders is usually at a late stage. Scrum on the other hand collects feedback after each sprint. In the Sprint Review meeting the teams demonstrate the newly developed increment to the other team members and the Product Owner. Even if the role of the Product Owner is not available for other development methods, the product manager or (premium) customer can serve as a feedback source. Feedback and acceptance criteria are very important for test management, because late feedback means that the product is changed at the last minute and side-effects are difficult to find. Having more feedback sources helps test management and development to avoid misunderstandings in requirements. Such problems lead to change requests and bugs and therefore more maintenance effort (changing, retesting). Is there a point in phase-oriented development when a presentation could be held? Milestones could be a good point for a presentation, but all components need to be stable at that time and the user interface should be in a presentable way. The possibility to hold a demo depends on the sequencing of the different components, the kind of milestone and the kind of development (new development, further development, etc.). The demo date could be hard to predict (as the release) and a moving date will not be accepted by customers. Having a peer demo or a demo for different product managers could be a good source of feedback (and the scheduling should be easier). The time required for the preparation has to be compared with the benefit of the feedback. Perhaps it could be more helpful to get feedback on mock-ups, use case descriptions or comparison of the requirements over the development time. Methods for inspection of the process The process is inspected in the Sprint Retrospective. This meeting, which should be held after each sprint, is the main tool of the ScrumMaster. A good Sprint Retroperspective shows the weak points of the process and helps to find improvements. Adaption of the process is desired in Scrum. The short period of time to the next Sprint Retrospective brings to possibility to try out new things and to discard them again, if necessary. In phase-oriented development processes, this kind of meeting is often held at the end of a project as the project review meeting. Lessons Learned and perhaps Best Practices are possible outputs of such meetings. Review meetings from individual www.agilerecord.com 43

8 Carter, JoEllen; THE AGILE TESTER; 2010; http://www.infoq.com/ resource/vcr/1619/file/WP_AgileTester.pdf

phases (e.g. the test phase) are possible, but as no phase can be considered in isolation and the test process is also split into phases, the appropriate viewing frame is not easy to choose. The problem of a project review meeting is that after a project teams are often dispersed and team members work in other teams. In addition, any possible improvements are not tested under similar circumstances. Splitting the process into milestones and starting a review of milestones could address some problems in the team communication, but the process adaption for the project phase will still not be tested under similar circumstances. Self-determination Self-determination is not a method in the strict sense, but it is one of the Scrum principles, so it should be considered here. How does the possibility of the team to choose its workload (i.e.,

the team decides how many user stories are in a sprint backlog) and to be responsible for the definition of done improve the quality of the product? Having commitment on the definition of done, including the testing criteria puts the responsibility for quality on the whole team and on the whole development period. Picking the workload should help to avoid over-working and stress (mostly finding the right amount of work needs some sprints) and so helps to avoid mistakes. Can a test manager in phase-oriented projects get this benefit? Using the self-determinate work load selection with the help of a product backlog (or a work package list) and having specific criteria for done in testing is a possibility, and could help to provide a better estimation of the time needed for testing.

Summary
Methods Daily status meeting (Daily scrum) Recurring demo meetings for feedback (Sprint Review Meeting) Make all work packages public (Sprint and product backlog, and sprint planning meeting) Make current work packages visible (taskboard) Include acceptance criteria in user stories Testboard Improving transparency of development process and communication between developers Simplified test design Reminder for programmer Improving transparency of test process; shows work of tester to all Makes regression test errors more visual. Visualize completed work (Sprint burndown chart) Adapt the process in small iterations (Sprint Retroperspective) Work package load is visible and already reached points are shown, easy to see any deviations Possibility to change the process to help in becoming more effective. Either a new work package structure needs to be created for this (effort) or the visualizing is hard to understand. Changing process while project is still running => uncertainties and difficulties to manage, only helpful for team intern problems (communication, etc.) Changing process after project => new project teams => changes will not be tested under same circumstances Self-determined work package load Commitment for work Better estimation Definition of done (for testing) Consistent use of done and therefore a equal quality level Work packages could be piling up, not all work packages could be done (but this should be shown at an earlier stage of the project) Preparation time, difficulties to ind a sufficient definition for all kind of testing activities. Could be seen as a control mechanism (the same could also happen in agile methods) Work packages have to be split into user stories => effort Effort for adding tasks to the board Pro Improving transparency and communication Early feedback (increases customer satisfaction) Coordination between team and product owner Improving transparency of product => feedback for product design none Contra in phase-oriented Time consuming, even if team is split Preparation time and scheduling difficulties (complete product has to be stable)

44

www.agilerecord.com

> About the author

Jessica Schiffmann works as Senior Consultant at Prism Informatics Deutschland. As Dipl. Informatiker (FH) she has worked in software development projects for several years, before choosing the software quality area as her working field. In different companies she could expand her experiences in the fields of test automation, functional testing, test design and test management. In different roles and projects, she could bring in not only her practical experience but also her theoretical knowledge from the ISTQB Full Advanced Certification. Since agile development and methods has gained her attention, she tries to combine agile and phase-oriented development methods for project success.

Certified Agile Tester

together
DATES AND LOCATIONS 13 FEBRUARY 2012 LONDON APEX CITY OF LONDON HOTEL 14 FEBRUARY 2012 LEEDS PARK PLAZA LEEDS 15 FEBRUARY 2012 BIRMINGHAM COPTHORNE HOTEL BIRMINGHAM
www.agilerecord.com 45

MEET OUR EXPERTS IN MAJOR CITIES ALL OVER THE UK AND FIND OUT MORE ABOUT THE EXCITING TRAINING AND CERTIFICATION PROGRAM CERTIFIED AGILE TESTER.

Register today at http://www.agile-tester.org/roadshow.html for the free event and get in touch with Certified Agile Tester.

www.agile-tester.org

Experiencing Agile
by Bart Fessl

How can you explain what Agile is? That shouldnt be too hard. A quick search on Google reveals there are about 15 million hits just looking for Agile, but to make sure the hits are most probably relevant, another quick search for Agile Testing leaves about 8 million hits. Plenty of information! What about literature? Another quick search, this time using Amazon.com, reveals about 250 relevant books, but this number is limited to the books published in English. Expanding the search on other sites including other languages will almost certainly result in more than 1,000 titles. Still, when you start reading the articles and books it becomes clear that Agile is not something you can learn from just reading. It does help to understand the definitions and buzz words that are used in agile development, but to completely understand what Agile can offer, how it differs from the more conservative, strictly phased methods, there is apparently only one way to find out: you have to experience Agile. And although the number of agile projects is growing day by day, there are still a lot of testing professionals who have not experienced Agile yet. Understanding the agile approach does give professionals an advantage during interviews! So we came up with a workshop where our goal was to make people feel what Agile is all about. Who are we? We are a group of testing professionals organized in what we call an Expert Group focused on the topic of interest: Agile. This Expert Group included: Joop Barink, Leon Commandeur, Bart Fessl, Frank de Leeuw and Hylke Schaapman. How can one quickly experience what working with an agile mindset can do for a project? We figured that, in order to achieve this goal in one workshop, we needed to come up with two versions of a mini project; one using a strictly phased approach, one using an agile set of rules. The goal was not to introduce testing professionals to the complete set of knowledge available about Agile testing, but to make them experience what the major differences are between projects using a phased approach and agile projects. To make the professionals focus on the experience and not let their IT-experience get in the way, we came up with the following approach. 46 www.agilerecord.com

Setting up the workshop We prepared for an audience of approximately 100 testing professionals, ranging from very experienced employees to those who had just started their career. We divided this group into subgroups of seven people, each participant with a distinctive role: one client, two analysts, two developers and two testers. The resulting groups were assigned to either a phased approach or to an agile approach. To ensure that all the teams would be able to compare an agile approach to a phased approach, two projects needed to be executed by each team, one acting as an agile team and one using a phased approach. To make sure the results of the assignments would be comparable, we set up and distributed a specific set of rules of engagement. Rules of engagement: the project The duration of the project is 30 minutes. Each participant sticks to the specific rules and role that are given upfront. Each team aims to create the required deliverable using the given building blocks and set of rules. Each team receives an equal set of building blocks consisting of: Lego Duplo, Knex, some yellow sticky notepads, some paper and a couple of pencils. Each professional acting as client has been briefed upfront and knows what to expect and how to behave.

Rules of engagement: phased approach There are 3 phases: a design phase (10 minutes), a building phase (10 minutes) and a testing phase (10 minutes). During the design phase, only the client and the analysts are allowed to speak. The other participants are allowed to listen, but are not allowed to speak. The analysts are supposed to design on paper what the client wants, using

drawings, written language or other means. During the build phase, the client is not available. The developers are supposed to build what has been designed, and the testers are supposed to start writing test cases using the design with the goal to verify that the deliverable works and looks as designed. When the testers or developers have questions, they are supposed to ask the analysts, but if the questions result in changes to the design, both testers and developers are supposed to stop working. Changed designs have to be approved by the client, who is by now drinking a cup of coffee in an adjacent room. Only the analysts are allowed to go into the other room and ask the client for permission to change the design. After the assigned 10 minutes, the building phase is stopped. During the testing phase the testers execute their prepared tests and write down any differences they find while checking if the deliverable meets the specified design. These findings are given to the developers, who are allowed to make changes to the deliverable, but if they make changes, testing is to stop until the changes have been made. After the given 10 minutes, the testing phase is stopped and the project is finished.

During round 2, the assignment is to build a playground, consisting of 3 structures: a slide, a seesaw and a rollercoaster. One twist needs to be mentioned: after a bit more than 20 minutes a change is introduced in both cases. In the windmill case, the explicit requirement is stated that the living quarters require one additional window. Because of the rules of engagement, this is likely to have an enormous impact on the phased approach, but is quickly incorporated in the agile teams. In the second case, due to budget constraints, the rollercoaster is cancelled and replaced by a swing. Again, this will have a major impact on the phase-oriented teams and less impact on the agile teams. The results The results of the workshop were even more impressive than we had anticipated. Apart from physically better results using the agile approach, the agile teams were much more enthusiastic and full of energy, whereas the waterfall teams were quite frustrated. The clients of the agile teams were very happy, whereas the clients of the waterfall teams were not very happy, ranging to not happy at all. Without exception, all teams reported in the evaluation that they felt to have performed better during the agile assignment than during the waterfall assignment. Indeed, the changes added during the cases turned out to have the desired and expected results, causing the phase-oriented teams to either not deliver on time or to deliver a model which was clearly built under stress and not quite finished. The agile teams delivered slightly less functionality but to a happy client. Although we realized that our Rules of engagement could only partially create an agile-like and a phase-like environment, we observed that the essential differences were felt by all participants. The fact that, even though they knew what the client wanted, they had to build and test what had been designed, turned out to create frustration in the phase-based projects. And although reality in this case is quite different from the half hour project, the situation does point out this weakness in phase-oriented ap-

Rules of engagement: agile approach During the first 5 minutes, the whole group discusses about what the deliverable is supposed to be, but not in detail. The aim is to come up with an approach where 3 sprints are to be delivered. The client has been instructed how his priorities are to be set, so after 5 minutes the whole team understands what they are supposed to deliver during the 3 sprints. Then, 3 sprints of 8 minutes each start. During the sprints, the analysts are supposed to ask questions to the client, who is available on site. While listening, the developers are supposed to start building what they hear. The testers are supposed to listen, look at what is being built, advise on any issues that may become critical in the upcoming sprints and are even allowed to help out with the development. The client is constantly asked if he will be satisfied with what is about to be delivered. At the end of a sprint, the analysts sketch what the result looks like.

The assignments for both groups of teams are the same. In round 1: build a model of a windmill. The client is instructed upfront and told that he is a miller wanting a new windmill. As the windmill is also supposed to be his home, he has requirements regarding the windmill itself, but also regarding his home. The project is supposed to deliver a working device consisting of 3 parts: a rotating set of blades with the ability to connect to machinery (it is up to the client to decide if he will use the windmill to produce paper, flour, or to pump water), a room where the activities can take place, and a home. As an example, the professionals acting as the client are shown the following picture which they are not given but are supposed to keep in mind while explaining to the analysts what they want.

www.agilerecord.com

47

proaches. Looking at the physical results (see pictures) we realized that it didnt matter what the actual result eventually looked like, as long as the client was happy. Agile requires the client to be heavily involved, which helps in the process of making the client happy. It wasnt necessarily the product which made the client happy, but it turned out that the whole experience during the development process contributed significantly to the acceptance of the product by the client.

> About the author

Bart Fessl is an experienced testing professional with approximately 10 years of experience in testing. As a product manager Bart looks after the SYSQA professionals involved in testing, ranging from coaching and supporting clients and other SYSQA professionals to developing new services and training about current and new hot topics concerning testing.

Conclusions Are the 100 participants fully prepared to start an agile assignment? Not necessarily. The agile method we introduced does not prepare them for the real thing. For the professionals who just started working as a testing professional we had to make clear that the model of the phase-based approach which we had created does not in any way reflect the usefulness this approach has in daily practice. However, the happy client, the productive team, the creation of value instead of the creation of intermediate products, the way in which the agile teams were able to incorporate changes because these are expected and encouraged, are all things we have been able to familiarize the professionals with. And by experiencing these specific consequences of working in an agile environment, we have at least prepared the professionals for their next interview and given them an experience they can certainly use in their own working environment. A useful lesson for the professionals, and a very good experience for all of us.

48

www.agilerecord.com

Prof van Testing recommends

iStockphoto.com / davidnay

Follow me @vanTesting

IREB Certied Professional for Requirements Engineering - Foundation Level

Description The training is aimed at personnel mainly involved in the tasks of software requirements engineering. The tutorial is designed to transfer the knowledge needed to pass the examination to become an IREB CPRE-FL. After earning a CPRE-FL certicate, a certicate holder can assess whether a given situation calls for requirements engineering. He understands the fundamental characteristics of the discipline and the interplay of methodological approaches, e.g. interview techniques, description tools or forms of documentation. More information regarding the required knowledge can be found in the IREB Syllabus, which can be downloaded from the IREB web site: http://www.certied-re.com Dates* 28.30.03.12 06.08.06.12 16.18.04.12 19.21.06.12 3 days Berlin/Germany (de) Berlin/Germany (de) Helsinki/Finland (en) Oslo/Norwegen (en)
*subject to modications

iStockphoto.com/numbeos

Website: http://training.diazhilterscheid.com

www.agilerecord.com

49

Understanding Test Driven Development with Python

by Chetan Giridhar & Vishal Kanaujia

Objective Test Driven Development is still a nascent concept for many. Developers often have erroneous assumptions, preconceived notions about the concept, and may fail to understand its potential. This article explains TDD with an intuitive Python example. Lets start with what TDD is? TDD stands for Test Driven Development. According to Wikipedia, Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. A typical TDD cycle comprises: Writing a test Run to fail Develop the functionality (complete or partial in chunks) Make the test pass Refactor code (clean up) Repeat the iteration

prime.py

Step1: Writing a test myTest.py Here we use the unittest module of Python and develop a test class called TestPrime. We have the setUp() and tearDown() methods that create and destroy the object of class Prime with the method test_if_number_is_prime() that tests the actual functionality implemented in class Prime.

Ok! Ok! Enough of theory! Lets get to the code! Example: Developing code for validation of prime numbers with TDD. As a first step, lets write a test. As there is no functionality developed, the test would fail. In the example below, the prime.py module contains a class and has a method isPrime() that aims to validate prime numbers but is not yet implemented.

Step2: Run to fail In TDD, tests are written first and then the code for the functionality is developed. Hence, we expect the test should fail.

50

www.agilerecord.com

As expected, the test fails as the assertion is not true. Step3: Develop the functionality prime.py Now, lets develop the functionality. We do that by developing code that validates if the number is prime in method isPrime() of class Prime. In the snapshot below, we observe that the one test passed and other test_for_negative_number() failed.

Step4: Make the test pass The test remains the same. As the functionality is now in place, the same test (myTest.py) should pass.

Lets now again develop the functionality and improve module prime.py to handle such error conditions. We say, if the number is less than or equal to 1, return False. As expected, the test passes. Step5: Refactor the code Lets do some clean up here and add documentation.

Run the test now and it should pass.

Step6: Repeat the iteration We now repeat the process and start developing the tests again. Lets write tests for error conditions, e.g., the input number is a negative integer.

www.agilerecord.com

51

Conclusion This article demonstrated the usage of TDD by implementing a sample application consistent with the philosophy. We discussed the steps involved in TDD methodology, and how it could be easily adopted for development in Python. Test Driven Development could prove useful for various reasons: It enables a shorter feedback loop of development It produces better quality of code since it is more reliable (pre-tested) It improves product understandingbetween developer and QA It allows the design to evolve with rigorous tests

> About the author

Chetan Giridhar (http://technobeans.com/ about) has experience in working as a software engineer in agile environments and takes an interest in agile practices and developments in Python. You can learn more about his work on Agile and Python at his website TechnoBeans. com. Feel free to contact him at cjgiridhar@gmail.com. Vishal Kanaujia is a tech enthusiast and has written articles for the Linux-For-You magazine on topics including virtual machines, Android OS, Agile and Python. He has special interest in compiler development, performance tuning, and algorithms. You can reach him at vishalkanaujia@gmail.com

Python is suitable to leverage TDD for the following reasons: Rapid development of applications Dynamically typed Availability of automation testing frameworks

References Test Driven Development in Python http://agilepainrelief.com/notesfromatooluser/2008/10/ advantages-of-tdd.html Advantages of TDD http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf Test Drive Development with Python http://www.slideshare.net/Siddhi/test-driven-developmentwith-python

Advertise at
www.agilerecord.com
52 www.agilerecord.com

Gilbs Mythodology Column 4 Lean Startup The Most Extreme Agile Method by Far
by Tom and Kai Gilb
We love Lean Startup, the book by Eric Ries (2011). We are recommending it to all our adventurous and open-minded professional friends. We enjoyed reading it as an ebook alternately on iPad and iPhone. The length is nice and short, the practical examples still rich. The deep understanding of a high risk, high uncertainty learning process is impressive. Eric believes in the same basic ideas of development that many of us have championed for years. Clear quantified ideas of real world progress, being tested rapidly and frequently in feedback cycles. The emphasis being learning what is real and true, asap. The difference is that Eric applies these ideas at an extreme that we personally have not dared to think or experience. He is operating at the 30 to 50 real changes a day being measured and learned from, from the real world. This is about gathering requirements from the real world by continuously (every day) and frequently (dozens of measured hypothesis per day). This is about testing alternative designs just as early and continuously, and letting design and architecture emerge, as whatever really works in satisfying the simultaneously emerging requirements. This is revolutionary! But for the sceptic, Eric documents in detail how it works in real named businesses. Eric is very clear about his sources of ideas, the classical gurus like Deming, Drucker, Toyota-Ohno, and many such more. He is equally clear that his methods role is primarily a framework to allow extremely rapid learning about what really works, and for whom it works. He clearly positions Lean Startup as a way of managing systembuilding processes such as agile methods like XP and Scrum. We and our professional friends have long campaigned for much better multidimensional quantified quality requirements, for a rich variety of stakeholders (gilb. com). Lean Startup makes these
Source: http://www.slideshare.net/venturehacks/the-lean-startup-2

a centerpiece of the method. However, the majority of agile developers dont want to know about such disciplined quantified thinking. They would rather fail. Eric speaks openly of his earlier failed projects (using conventional wisdom), and those of other businesses and clients. The conventional startup, and software development methods are inevitably highly failure-prone, and have been for decades. That is because there is too little clarity of purpose (clear quantified quality requirements), and too little understanding of the variety of stakeholder values. The Lean Startup ideas convincingly show how to avoid the embarrassing pervasive development project waste. History shows that the developers themselves, while intelligent enough to use these disciplined Lean Startup methods, are not likely to jump in and adopt them on their own initiative. They (developers) clearly prefer to get well paid to code fast using Agile methods alone, using relatively little engineering discipline (and Lean Startup is a rigorous scientific method and engineering discipline). They seem to feel no real responsibility for successful outcomes. Failure still gets well paid, at their level.

www.agilerecord.com

53

So this brings up the question of who this book is for. And who will in fact make sure the ideas are implemented. This has to be the people laying the investment on the table, hoping to get a return for it: directors, CEOs, CTOs, angels (startup investors). They need to demand, as a precondition for their investment, the kind of rapid learning, and rapid early pivoting (major changes in architecture, stakeholders, markets, product design) that Lean Startup teaches. It is this level of power and responsibility that needs to understand the basics of Lean Startup, and to demand their use. We think this executive level has for far too long, in the history of software development, totally abdicated their responsibility to ensure serious management of IT and software projects. Our extensive experience shows they rarely bother to even have clear quantified trackable requirements for massive (like $100 million) investments. Business schools have not been helpful in training managers to deal with multi-dimensional critical project requirements. If history is any guide, we are not going to change our irresponsible software investment culture in the short term, but Lean QA is a clear opportunity for the wiser top managers to make sure THEY will succeed, and hopefully in the longer term the amateur, non-scientific, non-engineering methods of the current software culture will die out. Get the book, read it now, spread the word, and see Erics many good presentations and videos as a supplement (see references). References www.theleanstartup.com/ The official website of all things Lean Startup presented by Eric Ries. www.slideshare.net/venturehacks/the-lean-startup-2 Eric Ries presentation on lean startups. From Steve Blanks Customer Development course at Berkeley. Learn more and hear the audio at http://bit.ly/ 3qsvJ. www.startuplessonslearned.com/2008/09/lean-startup. html 8 Sep 2008 (Update April, 2011: In September, 2008 I wrote the following post in which I (ER)published my thoughts on the term lean startup for the first time http://eng.wealthfront.com/2011/03/lean-startup-stageat-sxsw.html http://www.slideshare.net/venturehacks/the-lean-startup-2 Slides by Steven Blank and Eric Ries. The Lean Startup, Low Burn by Design, not Crisis http://www.slideshare.net/startuplessonslearned/200905-01-how-to-build-a-lean-startup-step-by-step/download

> About the authors

Tom Gilb and Kai Gilb have, together with many professional friends and clients, personally developed the methods they teach. The methods have been developed over decades of practice all over the world in both small companies and projects, as well as in the largest companies and projects. Tom Gilb Tom is the author of nine books, and hundreds of papers on these and related subjects. His latest book Competitive Engineering is a substantial definition of requirements ideas. His ideas on requirements are the acknowledged basis for CMMI level 4 (quantification, as initially developed at IBM from 1980). Tom has guest lectured at universities all over UK, Europe, China, India, USA, Korea and has been a keynote speaker at dozens of technical conferences internationally. Kai Gilb has partnered with Tom in developing these ideas, holding courses and practicing them with clients since 1992. He coaches managers and product owners, writes papers, develops the courses, and is writing his own book, Evo Evolutionary Project Management & Product Development. Tom & Kai work well as a team, they approach the art of teaching the common methods somewhat differently. Consequently the students benefit from two different styles. There are very many organizations and individuals who use some or all of their methods. IBM and HP were two early corporate adopters. Recently over 6,000 (and growing) engineers at Intel have adopted the Planguage requirements methods. Ericsson, Nokia and lately Symbian and A Major Mulitnational Finance Group use parts of their methods extensively. Many smaller companies also use the methods.

54

www.agilerecord.com

Sie suchen das Besondere?

The Agile Project Manager Fail NOW as a Strategy

by Bob Galen
my head. I simply didnt understand the big deal about failure. About using the word. About a team sayingwe failed. In my coaching practice and in my day jobs, Ive been able to steer and evolve our views so that failure is not a bad word, i.e., failure is good, failure is ok, failure leads to improvement, failure is a natural part of life. So in this article, I want to discuss failure from a few perspectives. The discussion isnt intended to be exhaustive. Instead, I just want to share some thoughts and get you thinking about failurehow you view it in your organization, what is your tolerance for it, and re-considering your normal reactions to it. I also think this leads you towards your risk handling as well, because I think the two are inextricably linked. (Please note: there is a survey mentioned at the end of this article. If you dont read all the way through, please consider taking the survey.)

I was at a conference not that long ago speaking and sharing on various agile topics. As often happens, a young man stopped me to ask a few questions after one of my presentations. We struck up a nice conversation that eventually slipped out into the hotel corridors. We started talking about sprint dynamics within Scrum teams and I happened to mention that I usually coach teams towards declaring their sprints a successor (pause for meaningful effect) a failure. That we do this as part of the teams Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s). He was visibly upset with my view. He said that they (he was working at a well-known Atlanta company) had never failed a sprint. Never! They could not nor would not use that WORD in their culture. I asked him point-blank have you ever failed a sprint? He said of course they had. Many times. But instead of using the term fail, they used the term challenged. That way, stakeholders wouldnt get the wrong idea and question the skills or motives of the team. We went round-and-round for another 10-15 minutes in our discussion, but we never really settled our differences. We simply agreed to disagree. Although it wasnt a terribly wide chasm between us, I distinctly remember walking back to my room shaking

Coaching to avoid failure In his blog post from June 20, 2011, entitled Coaching is Not Letting Your Teams Fail1, Giora Morein makes the case that agile coaches should be leading or guiding their teams away from failure. He brings up an analogy of a Sherpa guiding mountaineers. And yes, in the mountain climbing example I will have to agree that failure is probably not the result we want.
1 http://www.bigvisible.com/2011/06/not-letting-teams-fail/

56

www.agilerecord.com

Wir auch!
Wachsen Sie mit uns wir stellen ein! Zur Verstrkung unseres Teams IT Management & Quality Services suchen wir engagierte und qualifizierte Kolleginnen und Kollegen. Wir sind eine marktorientierte und innovative Berliner Unternehmensberatung mit 40 Mitarbeiterinnen und Mitarbeitern. Neben unseren hochwertigen Beratungsleistungen in den Bereichen Financial Services, IT Management & Quality Services, Training Services und IT Law schtzen unsere Kunden ebenso die durch den Unternehmensbereich Events & Media verantworteten internationalen Konferenzen und Publikationen rund um die IT-Qualitt. Profitieren Sie von unserer Erfahrung. Wir bieten interessante und anspruchsvolle IT-Projekte in den Bereichen IT-Prozesse und Projekte, MA-Qualifikation und Coaching, Softwaretest und Testmanagement sowie Architektur und Sicherheit eine direkte Zusammenarbeit mit der Bereichsleitung IT Management & Quality Services sowie den Teamleitern die Weiterentwicklung in einem flexiblen Unternehmen

Lassen Sie sich anstecken von der kollegialen Arbeitsatmosphre in einem starken und motivierten Team. Zum nchstmglichen Termin stellen wir ein: Senior Consultants IT Management & Quality Services (m/w) fr Agile Softwareentwicklung und Softwaretest Deutschland und Europa Sie haben eine fundierte Ausbildung oder ein Studium absolviert (z. B. Informatik, BWL, Mathematik) sowie mehrjhrige Berufserfahrung als IT-Consultant in einem Fachbereich bzw. in der Organisation eines Unternehmens oder bei einer Beratung in entsprechenden Projekten Erfahrung mit agilen Entwicklungsmodellen, -standards und -methoden sowie mit in diesem Umfeld bewhrten Testverfahren und Tools Kenntnisse in der praktischen Anwendung von Methoden und Standards, wie CMMI, SPICE, ITIL, TPI, TMMI, IEEE, ISO 9126 Erfahrung in der Fhrung von groen Teams (als Projektleiter, Teilprojektleiter, Testmanager) Vertriebserfahrung und Sie erkennen innovative Vertriebsanstze

Sie verfgen ber Eigeninitiative und reprsentatives Auftreten eine hohe Reisebereitschaft gute Englischkenntnisse in Wort und Schrift

Dann sprechen Sie uns an wir freuen uns auf Sie! Bitte senden Sie Ihre aussagekrftige Online-Bewerbung an unseren Bereich Personal (hr@diazhilterscheid.de). Ihre Fragen im Vorfeld beantworten wir gerne (+49 (0)30 74 76 28-0). Daz & Hilterscheid Unternehmensberatung GmbH Kurfrstendamm 179, D-10707 Berlin www.diazhilterscheid.com

However, in non-life threatening cases I think I disagree with Giora. I wholeheartedly believe that failure can actually be good for a team. I also think the role of the coach is to help a team look at their performance through two lenses. The easier of the two is the success-lens. This is the lens where you give the team positive feedback; where you tell them that they need to repeat those practices that work for them. Indeed, those practices they need to amplify and do more of so as to achieve greater and greater results. These conversations are clearly easier. What about the failure-lens though? As a coach, do you provide constructive criticism? Do you show a team where they missstepped both individually and as a team? I think so; certainly not in a malicious or heavy-handed manner, but as a fair and accurate observer. I think if youre effectively coaching a team, you must explore their errors and mistakes with equal passion and energy as you handle their successes. And I dont think you do this quietly, hiding behind closed doors and not externally acknowledging their challenges. No. I think you approach it in a completely transparent and matter-of-fact manner. Laying the groundwork that failure is appreciated and welcome. That from it, your teams need to look for improvement possibilities and move forward quickly towards delivering improved results. Agile exposure In agile teams, there are two key ceremonies that are focused towards success and failure results. In Scrum, that is the Sprint Review (demo) and the Sprint Retrospective (lessons learned). Typically, the sprint review is exposed to the world, so you might want to be careful in how you couch your failures so that stakeholders dont misconstrue the impact or the effort the team is putting forth. Nonetheless, I believe you should declare sprints either a success or failure as part of the introduction to the teams review. In Scrum, its the Product Owners role to determine thisand its relative to the goal(s) the team committed to at the outset of the sprint. Hopefully those goals were flexible enough to allow the team to adjust their work focus to creatively attain it. For example, I think a very poor sprint goal is something around the team delivering a set number of user stories or other indicators of by-rote execution. This leads to potential sand-bagging on the part of the team to hit a numeric goal rather than thinking of the true problem theyre trying to solve. Instead, better goals revolve around achieving some sort of demonstrated behavior that solves a specific set of customer problems. So success is measured against how well the team met the spirit of the goal and how well they applied the agile principles in their execution. For example, Ive seen teams that committed to 10 user stories, but had an extra three days of idle time at the end of their sprint, fail their sprint. Sure, they delivered to their commitment, but

their commitment was flawed. They sand-bagged and over-estimated. They also didnt make their additional capacity available to their Product Owner and ask for more work within their sprint time-box. Instead they planned ahead or gold-plated their deliverables. Ive also seen teams that committed to 10 stories, but delivered 7, have a very successful sprint. In it they worked hard against complexity and adversity. They were incredibly transparent and engaged their Product Owner in making daily adjustments on priority vs. their new understanding of capacity. And as a team, while they didnt deliver the originally perceived quantity, what they did deliver aligned with their goals and met the spirit of the Product Owners intent. Both of these cases should be discussed in the teams retrospective, exploring ways to improve their results. Not trivial ways and not ignoring the first teams behavioral problems. No. All of it the good, the bad (mistakes and failures), and significant improvement ideas should be explored. And the resulting actions should be focused towards the very next sprint.

But is failure embraced? Continuing with my earlier coaching example, I remember not that long ago I was talking to a group of our Scrum Masters at my employer iContact2. If you dont know about Scrum, the Scrum Master is the primary coach and guide and agile leadership voice within the agile scrum team. Theyre also responsible for maintaining core agile values within the team and for the teams overall performance. What I mean by that is guiding the teams improved performance over time. Continually asking questions like: Is the team improving in their overall performance? Is their velocity improving? Is their work quality improving? Are their teamwork and collaboration improving? And, is their focus on delivered customer value improving? So my point to the Scrum Masters was I felt we hadnt failed in quite a while. I defined failure in this case as a sprint failure or a stop-the-line incident where a team basically ran into a challenge and needed to re-plan or re-align their sprint. They all agreed with me that things had been going smoothly. And I received more than a few questioning stares as to why that was a problem. I tried to be careful in my reply, but my concern was that we might be playing it too safe. That we were becoming
2 http://www.icontact.com/

58

www.agilerecord.com

complacent in our agile practices and that we werent stretching ourselves enough. We werent taking chances or risks. I explained that these traits are fundamental to the growth and advancement of agile teams. And the fact that we werent seeing failures indicated that weve leveled off in our growth and performance. I felt this was a problemand I asked if they could drive more failures from the teams. Can you imagine the remainder of this discussion? Here I am, the Director of R&D at a successful company talking to my team of Scrum Masters and asking them to drive more failure to influence their teams towards more risk-taking and inspire more stretch goals. The point Im trying to make is that I truly embrace failure. That Ive learned to view it as a critical success criterion and that its absence is a problem for me. I wonder how many organizations and leaders have the same view. The notion of Failing Forward One of my favorite authors is John C. Maxwell3. Hes relatively well known as a leadership coach and hes quite a prolific author having written more than 50 books on various leadership topics. Hes got a strong Christian background to his life and writing, so if youre not so inclined, dont let that put you off. Hes truly mastered the art of leadership. A few years ago he published a book entitled Failing Forward Turning Mistakes Into Stepping Stones to Success4. In it he emphasizes failure as a truly transformative factor in our personal, professional, and team-based lives. However, he carefully frames failure with a leaning forward posture. That is, instead of viewing failure as a negative end-state and feeling sorry for ourselves, we should embrace it as a positive learning experience. That you should be leaning forward in your failure, leveraging the lessons learned towards improvement and trying new approaches. I dont think Maxwell is simply blowing positive smoke in our direction here. History is clearly littered with examples of successes that were inspired, forged, and hardened in the fire of failure; Thomas Edison being a famous example as he persevered to invent the light bulb. In my agile coaching I consistently use the terminology fail forward when I discuss team-based failures. Yes, I want a team to be honest with themselves and acknowledge they failed. But I also want them to embrace their mistakes instead of getting defensive, blaming others or denying it entirely. And I want their posture to be leaning forward, eager to try something new that will drive different results certainly never, ever being afraid of failure. I find that using this terminology helps teams to get the nature of failure and to behave appropriately. Beyond terminology, how3 http://en.wikipedia.org/wiki/John_C._Maxwell

ever, project and functional leadership need to fully support the idea too meaning the entire leadership team needs to be supportive of failure. ThereI said it. They need to create, foster, and support a culture that embraces failuresas well as success. Wrapping up But, Im a bit strange All of that being said, I wonder if Ive got a strange and largely minority view towards failure. I wonder if the right response is to indeed be fearful of it; to deny its existence; to spend countless hours trying to predict it; and to never mention it in public. Are those and similar actions the right responses? To that end, Im closing this article with a request of all readers. Ive put together a small, focused survey that Id like you to take. I know, I know, youre busy. But I really think your insights will be helpful here. The survey is focused on gathering a view towards organizational, group/team, and individual acceptance of failure and risk. Im trying to get to a root understanding of acceptance and also the root cause for those views. While Im particularly interested in agile teams, dont let your lack of agile experience prevent you from responding. Enter Survey Here https://docs.google.com/spreadsheet/ viewform?hl=en_US&formkey=dDJjeVFST0dDSjJrT0lyM2FmV0I wSlE6MQ#gid=0 What Ill do is collect comments and survey responses, consolidate them, and share them in a future article. I wonder if the survey will be a failure?

> About the author

Bob Galen is the Director, Agile Practices at iContact (http:// www.icontact.com/) and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership Balancing Value from the Inside Out (http://www.amazon.com/SCRUM-Product-Ownership-Balancing-Inside/ dp/0578019124/ref=sr_1_3?s=books&ie=UTF8&qid =1325898572&sr=1-3). He can be reached at bob@ rgalen.com

4 http://www.amazon.com/Failing-Forward-Turning-Mistakes-Stepping/dp/0785288570/ref=sr_1_1?ie=UTF8&qid=1310263078&sr=8-1

www.agilerecord.com

59

Introduction to Scrum An Agile Process

by Avnish Tyagi

Scrum is a framework based on agile development processes and techniques. The term Scrum comes from the idea of a rugby team made up of players supporting each other, working together to achieve a goal. This framework can be implemented in diverse fields such as software development, quality assurance, healthcare, manufacturing or any similar field which continuously transforms. Visibility is very important in any software development cycle, and in scrum you need to keep all the processes always visible. You should be ready to adapt to the changes, measure the progress Main Roles in Scrum
Product Owner Provide product requirements to the team Define goals Eliminate any confusion of different opinions Review/accept/reject user stories delivered in the sprints Prioritize product backlog by business value Provide timely feedback throughout product development Scrum Master Mentor the team

by the goals achieved and not by the effort it took to achieve them. The advantages of using scrum are: Reduced time to market High product quality Lower costs More employee commitment High productivity High job satisfaction

Team 72 full-time members Develop the product Business-value oriented self-motivated and organized Empowered and accountable

Educate the product owner and team to use scrum Facilitate the daily scrum Handle obstacles Protect team from any additional requirements during the sprint cycle

Product owner The product owner provides the details of product requirements and needs to ensure that only one set of requirements drives the development. The product owner eliminates any confusion caused by different opinions and interference, and is responsible for the business value delivered by the team. The product owner also attends every release/sprint planning session and sprint review. The product owner should communicate user story details to the team and provide timely feedback throughout product development.

Scrum Master The Scrum Master is a mentor who educates the product owner and the team to use scrum. The Scrum Masters role is to create and maintain an environment that allows the team to communicate, work effectively and continuously improve the process. The Scrum Master should also protect the team from any additional requirements during the sprint cycle and ensure that their commitment doesnt falter. The Scrum Master facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during the meetings.

60

www.agilerecord.com

Team The Scrum team is a 72 full-time development group that actually develops the product. The team is self-organized, motivated and has authority to do whatever is needed to meet the requirements. Scrum Framework

Scrum

Daily

Retrospective
Sprint Sprint [1-4 weeks] Tasks Wish-list Sprint Planning Team Decides How much to Commit
[1-4 weeks]

Review
No Changes in Sprint Backlog Duration or goal

Sprint

Potentially Shippable Increment Of product

Product Backlog

Product Owner

Scrum Master

Team

What is a Sprint? A sprint is a fixed time frame of 1-4 weeks, required to build something valuable for the Product Owner and to potentially deliver a shippable increment of product. It includes multiple tasks such as development, testing, deployment and so on. Sprint is a time frame which cannot be extended

Product Backlog (PB) The wish-list or product backlog is a collection of high level features that need to be prioritized by the product owner. User stories The backlog features are presented as user stories (requirement descriptions) that are presented from the end users perspective. A user story should be short, simple and small to fit on a small note that can be displayed during the sprint cycle. Product backlog items (PBI) Each feature in the Product Backlog is a product backlog item. These have a brief description and rough estimation, including their business value (set by the Product Owner) and the effort that will be required to complete. A PBI should be small so that the team can complete this task in a single sprint. If a PBI is larger than one sprint cycle, it should be split into multiple PBIs.

The progress of sprint tasks is commonly tracked on a board that divides them into states such as TO DO, In Progress, and Done.

Sprint planning This is usually a four to eight hour meeting where the team discusses high level priority with the Product Owner and comes up with Product Backlog items. The team then takes that information and separately decides how much time can be committed

www.agilerecord.com

61

and which items can be completed within the sprint. The Sprint Goal and Sprint Backlog (SB) are the outcome of sprint planning. Sprint Backlog The Sprint Backlog is the list of items from the product backlog that are selected for a sprint. This list contains the high level items from the product backlog. The team should select the items and size of the sprint backlog based on previous sprint experience. The team members should select their tasks during the daily scrum based on their availability. Daily Stand-Up The daily stand-up is the key meeting where the team members report their progress and the issues faced during development. The Scrum Master must make sure that the stand-up meeting starts at the same time every day and that everyone is ready with the status for the following available:

Each team member should only brief about the tasks they are handling and not try to resolve any issues in the meeting. Issues or obstacles must always be discussed offline and kept away from the daily stand-up meeting. Tracking progress The Scrum Master should track and measure real progress based on: How much more work is pending How fast is the team progressing Which milestone is the team at

Burn-down chart Based on the sprint data collected and tracked, the Scrum Master represents the current sprint progress using the burn-down chart.

Remaining efforts (Days) Planning efforts (Days)

Sprint review The team reviews the tasks that are completed and which were not completed during the last sprint cycle. The product is presented to the product owner for more feedback.

62

www.agilerecord.com

After review with the Product Owner, the team will discuss the following: Sprint deliverables Pending tasks Outstanding issues/bugs

> About the author

Avnish Tyagi is a Senior Technical Lead at McAfee Antivirus Lab. He currently leads the QA team. He has close to 11 years of experience in design, development, testing and maintenance of object-oriented frameworks. Prior to McAfee, he worked with Cisco System and iPolicy Networks. At iPolicy Networks, he worked with the security research group and developed various tools for testing IDS/IPS. He has extensive domain expertise and experience in network security and e-mail security. Avnish is a Certified Ethical Hacker(CEH), Certified Security Analyst(ECSA), Certified Scrum Master and holds a master degree in computers.

Retrospective The team, Scrum Master and Product Owner inspect how the last sprint went with regard to people and process, and the will openly discuss what went right, what went wrong, and what changes could be made to the next sprint to improve quality, productivity and morale. Closing remarks Even though the Scrum Framework helps you to achieve great targets in a shorter time frame, you must also note that there are a few things to bear in mind, such as: DO NOT try to fix all the product backlogs in the next sprint. Try to make continuous improvement. Once you have the team working smoothly, DONT break it.

License ISTQB and IREB Training Materials!

Daz & Hilterscheid creates and shares ISTQB and IREB training material that provides the resources you need to quickly and successfully offer a comprehensive training program preparing students for certication. Save money, and save time by quickly and easily incorporating our best practices and training experience into your own training.

Our material consists of PowerPoint presentations and exercises in the latest versions available. Our special plus: we offer our material in 4 different languages (English, German, Spanish and French)!

For pricing information, and all other product licensing requests, please contact us either by phone or e-mail. Phone: +49 (0)30 74 76 28-0 E-mail: training@diazhilterscheid.com

www.agilerecord.com

63

From destruction to construction

by Antonio Robres

Destructing the software Since the beginning of the software testing discipline, the main objective has been to find defects in the software implemented before clients find them. This objective tries to save maintenance costs and to prevent that those errors impact the final customers. With this philosophy, the waterfall model was created. In this model, the testing process is performed only at the end of the development process, and the only aim was finding defects in the software developed, e.g., by destroying the software implemented using techniques and heuristics. Some years later, the V and W models attempted a new approach with testing departments trying to involve the testers in several stages of the development. In this models the testers participate in all stages of software development and are responsible for the validation and verification of software requirements, software design and implementation. However, the role of testers using these methodologies continues to be a destructive one because the only aim of testers is to detect defects in all the development stages. With the above models, the testing team does not add quality to the product. It only determines whether the product has enough quality to pass to the next stage of development or not. This destructive role of the testing department is the reason why other departments (programming and business teams) see it as an enemy, because the only purpose of testers seems to be criticizing the product. This confrontation may influence the relationship between the testers and programmers, and it may impact on the quality of the product. Agile methodologies: New tester role? With the new agile methodologies, the testers role in software development changes radically. The testers or testing departments are not isolated from the development team. The tester

is a member of the development team and takes part in all the product development. The key point for this integration with the team is participating in all team activities, along with developers and stakeholders. In this set-up, testers are involved in the following activities: Sprint Planning Insprint planning, the tester has several important tasks for the proper planning and prioritization of user stories. The first is the possibility of planning the different test activities with the whole team including the programmers, business analysts and stakeholders. The participation in the planning of the tests activities helps programmers and stakeholders see the different activities performed by testers and the effort involved in every activity. Another task in sprint planning is to give the whole team another point of view about the different user stories. For example, it is possible that a user story for which the software implementation is very simple can require considerable effort from the testing team because the functionality has a big impact on the product. During sprint planning, the Product Owner explains the different user stories and their acceptance criteria. It is very important for the tester to understand all the functionality explained by the Product Owner. At this point, it is also essential to try to make a first version of the acceptance tests to set accurate acceptance criteria with the whole team. These tests can be useful for the development team for understanding the stakeholder requirements and for implementing the unit tests and software development. Finally, the participation of the tester in the definition of done, i.e., setting the requirements to close a user story, is very important. Depending on the complexity and the risks of the user story, the Product Owner and the tester can require documentation,

64

www.agilerecord.com

unit testing, performance testing, etc. The tester should review all the tasks included in the definition of done before closing the user story. Retrospective Another important activity included in the agile methodologies is the retrospective. This activity is used by the team for a continuous improvement in the whole team (not only in the source code). In the retrospective, the tester has the opportunity to expose, if needed, the handicaps or deficiencies detected in the testing process during the sprint development. It is also important to try to give feedback to all the team about the quality of the product and the development process in order to increase the product quality. The testers in the team can also ask for and get feedback from the rest of the team, including the programmers and stakeholders, to increase the efficiency of the testing process within the sprints. Demos At the end of every sprint, the team performs a demonstration to the stakeholders to show all the user stories and functionalities developed and implemented by the team. The testing presence is critical because the tester can obtain feedback from the stakeholders and customers, and information about their interests. This information can be used later to improve the acceptance tests and to apply to the test designs in the next developments. Finally, it is highly desirable to show the tester activities of the sprint during the demonstrations to explain all the tasks related to quality assurance and testing. It is also essential to show all the tests types performed by the team during the sprint (unit testing, functional testing, acceptance testing, integration testing, performance testing). Tester activities using agile methodologies To become a constructive member instead of a destructive one, some activities in the sprint developments need to be performed at several levels. ATDD (Acceptance Test Driven Development) One of the most important contributions in each of the sprints are the ATDD practices. Using ATDD, the testers can transform user stories or customer requirements into executable tests to verify and evaluate the software implementation of the programming team. The tests designed using ATDD become executable specifications and can be used to support the programmers and analysts to develop the functionality required by the stakeholders. The tests should be designed before development begins.

The tests designed using ATDD must be exhaustive, describing the whole functionality from the user story, and they must be very simple (KISS concept). These characteristics are vital to avoid ambiguity, errors or misunderstandings between programmers and customers. Using this practice, the testers provide a point of view which is aligned between the customers and programmers and which focuses on avoiding problems rather than detecting them. Testers add quality to the product and are valuable team members. The tests designed for ATDD should be expressed using business language in order to validate them with the Product Owner or with customers. Later, these tests can be implemented using a technical language aligned with the programmers to support and to help in the implementation of the functionality. Using this model, the team can achieve full alignment between business facing and technical facing aspects. Finally, it is also vital to automate the acceptance tests. This automation should, where possible, be at the behavioral level of the applications instead of via graphical user interface. Using this approach, the team can obtain tests without GUI dependency that are easier to maintain. This also has the advantage of being able integrate the acceptance tests into the continuous integration platform to execute the tests continuously. Integration Testing and TDD After the acceptance test implementation, tests must be designed and developed for the lower levels (unit testing and integration testing). These tests can be designed and implemented by developers using TDD (Test Drive Development) practices. Usually, unit tests are performed by the programmers using xUnit frameworks; this depends on the programming language used for the application. At the unit test level, the number of tasks for the testers in the team may be less, but they exist.The testers can support the programmers activities by helping them in the unit testing implementation and providing continuous feedback to improve the coverage of unit tests and make them efficient. The correct implementation of the unit tests depends also on the acceptance test designs, because they are a good input for the programmers. It is very helpful to request feedback from developers during the implementation of unit test to improve the previously designed acceptance tests. Maintaining good collaboration between testers and developers is essential during the acceptance and unit test design, and during the implementation. As a result, the quality of the tests will improve and trust between the teams will be increase from the points of view of both parties.

www.agilerecord.com

65

One practice recommended to improve the skills of programmers and developers is performing pair programming sessions that include the unit testing implementation. This practice allows all team members to learn testing and coding skills to improve the quality of the product and to maintain a good relationship between departments. Continuous integration Another significant tester activity during product development is the implementation of a continuous integration platform. Using the continuous integration platform, the team can automatically execute source code compilation, the acceptance tests, the unit tests and integration tests. It is also useful to obtain quality metrics such as coverage, or static analysis to evaluate the quality of the source code. With the metrics obtained and by using the continuous integration platform, the QA and testing team can analyze the product development and the quality in every component of the source code. This analysis can be useful to find the parts of software most critical in order to increase the effort to improve the quality of the respective code. If all the development team works within the platform, which enables the team to detect when an error has been introduced into the source code and fix it faster, thereby increasing the teams velocity. It is vital to analyze the impact of the new code introduced into the product and to detect the complexity of the different component of the source code. Exploratory testing It is commonly believed that exploratory testing has no place in agile methodologies because all the tests are performed in the acceptance tests and unit tests (except performance or security tests). This is absolutely false, because exploratory testing can bring much value in the sprint development by performing exploratory testing of the functionality and user stories already implemented. What advantages are obtained by using exploratory testing? The tester can interact with the software using other techniques or models, which are not part of acceptance tests and unit tests. The tester has the freedom to test without any script or pattern. This characteristic allows testers to be more creative than when using other test techniques. The testers can learn about the software during test design and test execution. The knowledge gained will be useful later to perform better designs and acceptance tests in the next sprints. Exploratory testing enables continuous improvement in the application and the business facing aspects.

A significant aspect during sprint planning is to schedule exploratory testing tasks in order to obtain another point of view of the product. This testing can be performed not only by testers, but also by the programmers. A good practice can be to plan some exploratory testing sessions where a tester and a programmer pair up to improve the testing skills for both. Other testing activities Other activities in the sprint can be the design and implementation of other testing types, such as performance testing, security testing or usability testing. It is essential that these tests are planned and prioritized in the sprint planning as a user story or as a task with established acceptance criteria. They must be aligned with the programmers and stakeholders. Using this approach, it is possible to design and implement activities as a user story or a requirement. For these activities, it will be mandatory to use specialized tools and to agree about the tests to be performed with the development team. This will enable support from all the component parts of the team to be obtained regarding the implementation. Skills required in agile testing The adaptation to a new role of the tester is not easy, and it may be necessary to have several skills to perform the associated tasks and activities described: Testing knowledge and testing concepts: This is needed as a basis for testing concepts to perform the testing activities. The tester needs to have knowledge about testing techniques, heuristics, oracles or tools to perform all the activities in agile testing. Coding skills: If testers are to be valuable for the development team, they should speak the same language. Coding skills are important to help the programming department in the unit testing tasks or to evaluate the software designs. This skill can be useful to build trust between testers and programmers. Testing tools: These skills are important to enable the testing activities to be carried out efficiently. It is also essential to use the tools to automate the tests and to facilitate the tasks in the sprint. Business skills: All the tests performed during the sprint should be aligned with the business and the product. For this reason, knowledge of the business domain is very important to create acceptance tests that are useful for the product. This knowledge is also useful to establish a good relationship between Product Owner and customers. Communication: The testers in agile methodologies mediate between the business layer and technical layer, so it is essential to have some communication skills. It is vital to be an active listener in order to obtain all possible information from both parties and act accordingly.The communication between team members should always be constructive to avoid problems.

66

www.agilerecord.com

Team player: As mentioned at the beginning of the article, one of the major changes in the tester activities is the relationship with the team. In agile methodologies, the tester is more involved in the team and participates in all the activities. One of the key points of the tester in the agile methodologies is the opportunity to be an active member of the team; somebody who adds value to the product. An additional task in the team is that of a preacher of quality who convinces the team that quality is the responsibility of the whole team, not only of the tester. Continuous learning: One desirable skill for the tester is curiosity and being prepared for continuous learning to offer a continuous improvement to the team. Improving knowledge and skills means improving activities performed during development. As a result, efficiency will be higher and the quality of the product is increased. Testers must be able to request and accept the feedback obtained by the rest of the team and apply it to perform continuous improvement personally and professionally.

Be a quality preacher in the team. Promote and encourage the development team to use good development practices and help them increase product quality. Remind the team that quality is the responsibility of the whole team. Enjoy! Make the rest of the team have fun with their work!

> About the author

Antonio Robres is a QA engineer at Telefonica I+D in Barcelona, Spain. He studied Telecommunications Science at the Polytechnical University of Catalonia in Spain and has a Masters Degree in telecommunication administration. Also, he is an ISTQB Certified Tester at Foundation Level. He has been working for 6 years in the field of software testing and quality engineering for different companies such as Telefonica, Gas Natural or Grifols. His work focuses on the design and execution of several testing projects, mainly in the fields of mobile devices and web applications. He is also involved in the design and development of test automation projects with open-source tools. He was a speaker at the QA&TEST 2010 and at VLCTesting 2011. He is a writer in the testing blog www.softqatest.com. He also is a member of the TestQA association and a member of the SSTQB.

Conclusions The tester role has changed in the agile methodologies. In the past, the waterfall or V model saw the role of tester as destructive; somebody trying to find as many defects as possible in the product at several levels to save money and decrease any adverse impact on the customers. With the agile methodologies, the role of the tester becomes more constructive and adds value to both the team and the product. To increase this value, the tester needs to help align stakeholders and programmers. They should be involved at all the stages of the product development. To be a valuable team member and to add value to the product, it is important to follow several recommendations: Be an active participant in all team activities during the sprint, such as sprint planning, retrospectives and final demos. Use ATDD to create executable specifications and evaluate them with the stakeholders and with programmers. Give support and help the programming team with the unit and integration testing. Try to perform pair programming and pair testing sessions. Use a continuous integration platform to compile and deploy all the code, and to execute all the acceptance and unit tests. Obtain the metrics from the continuous integration platform to analyze product quality. Give and receive continuous feedback using a constructive communication with all the team and to practice continuous improvement. Apply clear communication with the team members to create trust.

www.agilerecord.com

67

Management of Development Team

by Piotr Trojanowski

The whole range of different approaches for Project Managers (PM) for managing development teams extends between two extremes: PM-centric micromanagement and PM encouraged self-organization. One may expect that junior PMs tend to more often start from the former one. Junior PMs stick strictly to controlling execution of all micro-tasks as a result of their lacking an appropriate level of trust and/or courage to delegate work to development teams. As time elapses and junior PMs gain more experience, they gradually shift towards the latter option of modeling self-organization of development teams facilitated by task delegation and self-organization moderation techniques. The difference between these two approaches boils down to the difference between feeding starving people with fish or providing them with a fishing rod. A variety of intermediate approaches for managing development teams exist between these two extremes the road to mastership takes time. Lets have a closer look at the two extreme approaches first before switching to discussing Scrums built-in team management model and organizational aspects, which need to be considered when deciding on the appropriate approach of development management for a particular project. Micromanagement The first approach micromanagement focuses on addressing the current projects and development team members needs and current matters. The PM is highly involved in all current issues irrespective of how minor they are. S/he tries to cover all aspects of a project and be involved in literally every activity within the project. This is a natural approach for beginners who personally commit to deliver a project. However, such an approach creates handicaps for other participants of the project. First of all, it means that decision making gets fully centralized on the PM. As a result, the team will lack in motivation for proactive behavior, as nothing is likely to happen without the PMs knowledge and decision. The team switches to a passive role and waits to be assigned successive technical tasks. The development team mem-

bers focus on individual tasks that get assigned to them. This is very uncomfortable for individual team members as it significantly limits their natural need to make use of their intellectual potential. At the same time they focus less on the business goals that a product owner wants to achieve. They shift this responsibility to the PM as s/he keeps it all under control. Some individuals actually like this kind of set-up because it lets them stick to their comfort zones. Others, however, do not like such set-ups as they, in some sense, feel uncomfortable about competing with the PM for responsibility, especially if they feel they are in a better position to handle a particular area of the project. Both cases are harmful to the project. Such environments, created by an overacting PM, seriously decrease the development teams empowerment and commitment. A team can never become more mature under the above circumstances it is simply not given a chance to improve its maturity. This mode of PM work is called the micromanagement1 approach to development team management and project management in general. (In my opinion, Wikipedia takes it too extreme, referring to an obsessive-compulsive personality disorder as the root cause for micromanagement practices and behaviors). Personally, I also call this approach PM-centric management as opposed to team-centric management. It is needless to say that micromanagement has destructive results in the long term, not only negative connotations. In fact, micromanagement is one of the classic managerial anti-patterns. Please note that a need for micromanagement may originate not only from the PM, but also from the development team. Usually this is the case with recently-created teams that are still progressing on their way to establishing some initial self-organization, or teams that expect to be micro-managed based on past experience. The former case is pretty healthy a development team can and should expect a PM to support them towards mature self-organization. After all, it is one of the major goals
1 http://en.wikipedia.org/wiki/Micro-management

68

www.agilerecord.com

of a PMs work. The latter case, on the contrary, is a clear sign of a malformed organization culture, and solving it is more of a matter of organizational effort that is required to change the existing culture. A PM should discuss the limitations s/he sees in the current model and the proposals for change via the channels and mechanisms existing in a company for these purposes, rather than starting a lonely struggle with introducing the culture change locally. Notice that as long as the former PMs approach will be perceived well as a proactive action to building the companys culture, the latter approach can be assessed as an individual battle against the rest of the world. Any attempts of a PM to change the culture locally exclusively in his projects must be undertaken very carefully, and will as a matter of fact have limited chances to be successful. Such attempts may result in tensions between a PM and those development team members who have become used to the prevailing reality. They will hide their impedance for change and preference to stay in their comfort zone behind arguments praising the value of existing processes and culture. For them it is more of a PM problem to adjust to the existing organization culture. This is all understandable. Avoiding change is quite natural for some of us, and one of the quite reasonable approaches to change management. My recommendation in such cases is to start work on altering organizational culture using existing company channels dedicated for such purposes. The changes to existing reality will be much easier to push through and communicated to teams by people / committees / bodies who are widely recognized as accountable for an area of organization culture, i.e., heads of departments or heads of project management, PMOs, etc. Self-organization of development team The second approach PM encouraged or PM moderated self-organization is the complete opposite of the micromanagement approach. This is a team-centric approach. In this approach a PM lets the development team take full ownership of technical aspects of a project. The PM herself stays at a level of business requirements and not their technical solutions. In other words, the PMs duty is to answer question of what and when, and development teams duty is to answer questions of how. From the development teams perspective, such an approach opens doors for all the good things. It values the intelligence of individual team members and lets them reveal their intellectual potential. It gives individual team members a chance to become fully productive and empowered. At the same time, the ability to make decisions leverages everybodys commitment and responsibility to deliver high quality software. The above work environment models a teams world according to one of the key principles for managers to transform business effectiveness given back in the 1980s by W. Edward Deming: it removes barriers that rob people in engineering of their right to pride of workmanship. From a PMs perspective, the teams self-organization takes the PMs thinking a few levels higher to a wider timescale perspective which allows focusing attention to the systematic long-term

resolution of core managerial issues and process improvements. A PMs mind is relieved of the burden of low-level detail and free to focus on core aspects of the work. Still, the PM remains 100% responsible for moderating the process of the development teams self-organization. See Mike Cohns book Succeeding with Agile2 in which the PMs options to influence the teams self-organization are discussed. Scrums built-in approach The agile methodologies rely deeply on the notion of self-organizing teams. In fact, self-organization is a core building block for all of them. There is a clear shift of responsibility down to the individual members of the development team. The world is not PMdriven and not PM-centric anymore the world is team-driven and team-centric. The PM is not a member of the team anymore. This is only possible through the empowerment of individuals and acceptance of responsibility by them. As a result, the PMs position is, by design, in the area of facilitating the above notions more than anywhere else. Yes, Agile defines self-organization as its built-in development team management model, not leaving much space for PMs to choose their favorite development management model. Agile PMs fall into the PM-moderated/encouraged self-organization approach by the mere nature of things, or should I say by the nature of the agile development management model. So far, so good here comes the difficult part: Self-organization is not granted for free to every organization starting from day one; Agile does not work out-of-the-box; one cannot switch from waterfall to Agile with a single managerial decision. Why? Because Agile needs mature teams that are ready to accept responsibility as decisions will no longer be coming from the PM in a readyto-process form. Your development team may not be ready for this. For some reasons a development team may not be mature enough to accept the challenge. The root cause may be either some reason internal to the team, e.g. lack of experience, sticking to good-old habits, or equally well shortcomings of a PM not fully facilitating agile management responsibilities. One of my favorite quotations, originating from eastern culture says: Achieving your goal does not matter; it is getting there which matters. The whole journey of getting there to the stage of mature self-organization of development teams in its full extent starts from the teams initial immaturity and complete reliance on a project manager. Getting there is a process that takes time and needs sponsors, and as such getting there should be treated as a long-term investment in the ability of the organization to deliver quality software. There is no doubt about it the way to a mature teams self-organization is a process that needs to take place at the organization level and be conducted as a change of organizational culture. So before overeagerly claiming that your organization is agile, (as too many organizations do nowadays), just because daily standups are implemented here and there, I recommend you to take
2 http://www.amazon.co.uk/Succeeding-Agile-Development-AddisonWesley-Signature/dp/0321579364/ref=sr_1_2?s=books&ie=UTF8&qid=13 18024887&sr=1-2%29

www.agilerecord.com

69

a conscious and responsible approach to take a step back and see where you are. The first step is to accept the fact that getting there needs practice towards reaching the state where the selforganization has a chance to succeed. Self-organizing teams preparation It would be really optimistic to assume that the process of leading your team to full maturity is your individual decision and that it can happen during project execution at an arbitrary time of your choice. More realistically, however, various factors need to be taken into account. It matters whether you work for a software vendor or in an internal IT department of a non-IT company. It matters what delivery model you are obliged to follow; this can be anything between Fixed Price Fixed Time and Time & Material. Finally, it matters who your sponsor is and what his needs are. What is the sponsors level of awareness with regard to the goals of the transformation? Is your sponsor ready to accept additional time and money being spent to go through a transformation process that will pay off in the long term by increasing the ability of your team to deliver quality software? The key prerequisite factors of the transformation process that need to be agreed up-front are: 1. 2. 3. 4. 5. recognition of the transformation process as a long-term investment at the organizational level, conscious execution of the transformation as part of a particular carefully selected project, project sponsors that are fully aware of the attempted transformation, well defined sponsors of the transformation, and a level of transformation transparency that is agreed with project sponsors.

The classic Herseys and Blanchards team leadership model Situational Leadership theory3 may be of help. The SL model defines four phases of a teams evolution and the PMs involvement in leadership: Telling Teams full reliance on PM and his instructions, Selling PM gradually buys individuals into the decision process, Participating shared decision making between PM and team, and Delegation Team fully responsible for decisions

As one can see, the Telling level corresponds to the micromanagement approach while the Delegation level corresponds to Agiles PM encouraged self-organization approach. Selling and Participating intermediate phases let you drive the transformation more smoothly. In parallel, Tuckmans stages of group development, also known as Forming-Storming-Norming-Performing model4 of group development, may be of help. Again, the model is based on four phases in which the corresponding PMs role is defined, as described at Wikipedia: Forming the forming of the team takes place; Supervisors of the team tend to need to be directive during this phase. Storming different ideas compete for consideration; Supervisors of the team during this phase may be more accessible, but tend to remain directive in their guidance of decision-making and professional behavior. Norming The team manages to have one goal and come to a mutual plan for the team at this stage. Performing It is possible for some teams to reach the performing stage. These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. By this time, they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decisionmaking process without supervision. Supervisors of the team during this phase are almost always participative. The team will make most of the necessary decisions.

In my opinion, it takes a very conscious and mature client to understand long-term benefits of the transformation. It is even harder to find a sponsor who, understanding the need, decides to go for it; very rarely are the sponsors themselves rewarded with long-term results. Speaking from my own experience, after 10+ years of Scrum on the scene, it is still difficult to come across such mature clients and organizations. Agile became attractive and well perceived as a sales item in Requests for Proposals (RFPs), but this is rarely reflected at project management level. One other thing is worth noting as a side note when considering the transformation. In the aforementioned book, Cohn is able to plot a diagram showing the level of a Scrum Masters involvement throughout a process of the teams way to full maturity. As one can expect, the initial involvement starts at the highest level and falls down to the lowest levels when the transformation is done. Self-organizing teams Getting there If you are given a chance from project sponsors to grow your team, take it; it may not occur a second time. You may wish to make the change in steps.

The backbone idea driving the above models is that Team has a lifespan: it needs time to grow mature and it needs help on its way to maturity. Please note that the kind of help they need has nothing to do with micromanagement. The process of growing mature is not driven by any sort of a PM it is a natural process. All they need from a PM and an Organization is encouragement, motivation, freedom, moderation and support.
3 http://en.wikipedia.org/wiki/Situational_leadership_theory

4 http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development

70

www.agilerecord.com

During the transformation you need to constantly take into account that getting there needs changes to the organizations culture as well as mental changes of individuals. You may need organizational help in this aspect. Summary Scrum as well as other agile development methodologies, like Kanban, are based on the most mature team development phase. The underlying scientific models of the team evolution were created back in the 1970s by behavioral scientists. I would not be surprised if this is an eye-opener for many of you. I must say, it was for me! One may ask: But wait, werent we told that Agile is a simplified version of managing development? That it is all lightweight and straightforward to use?! Well, yes, I am sure you were told all this... I am just not sure you were ever told about the work and time necessary to build a teams maturity level high enough to fulfill Scrums pre-requisites, and most importantly how to get there. I personally believe that this work is only necessary because of bad-old habits the way organizations got used to working. For years people were told exactly the opposite to follow the instructions of the boss and not to think too much about the wider perspective the exact copy from Fords production model. Luckily, some of you work in organizations which understand the need for continuous improvement and are willing to invest time and money in researching ways to improve business effectiveness. If you are not that lucky, find some time to re-think your current professional situation. Side note 1: Planning management of development team in an organization Having said that there is a whole spectrum of approaches to managing a development team, one needs to bear in mind that every PM has his/her own preferred approach to managing teams. This is something s/he has worked out throughout his/her career. It is a very individual thing originating from a mixture of factors characterizing an individual PM: domain knowledge, personality and experience in terms of work environments, teams, methodologies, contractual models, etc. On the other hand each organization has worked out its level of maturity throughout the years of its existence. Again, it is quite an individual thing originating from a mixture of factors: how projects were executed in the past, how mature teams are, and also the companys culture. A teams maturity always reflects the companys maturity. The same is also true for a teams culture. There are differences between individual teams, but the correlation with the companys maturity and culture is always there. So how should an organization plan the management of development teams in order to execute projects successfully or at least in a controllable manner? First, one needs to select a development team management approach corresponding to the assessed development teams ma-

turity level. Having identified the match, one then needs to find a PM capable of managing the development team according to the above parameters. Side note 2: Attempts of unification As usual, one needs to be careful and resist the temptation of assuming that projects are executed uniformly across the organization. I think it is much safer and feasible to assume the opposite. A degree of formalization of project management and software delivery methodologies does not influence the uniformity of project execution much. Except from the factors that can be made uniform like delivery methodologies, there are other factors that cannot be made uniform. I can see at least three different groups: 1. The above-mentioned human nature specific factors characterizing individual PMs, 2. Human nature specific factors characterizing individual team members, and 3. A variety of business domains and characteristics of clients for which projects are executed. Unification of project execution should focus on pointing PMs in the right place on the whole spectrum of choices rather than on nailing down a list of uniform rules and / or processes. The approach to development management selected on the scale of options should be the one most closely corresponding to the companys reality at the current level of growth and maturity. Note that the approach of producing lists of uniform rules / processes that is not recommended is also based on an assessment of the best matching project execution model from the same spectrum of choices. However, the assessment is not done by a PM and is made implicit to a PM. Instead, the PM is given a hardcoded list of processes produced based on the implicit assessment. As a result, the PM does not have a chance to grasp the full picture and underlying layers of logic, but is limited to following the already processed information. This can be and usually is quite misleading and, even worse, leads to nowhere in the long term.

> About the author

Piotr Trojanowski has been leading agile software projects for 4 years. As Scrum practitioner (since 2006) and CSM (since 2009), he specializes in agile software development management and agile project management. He authors a popular blog on agile software project management: http://agile-software-management. blogspot.com. You may contact him at piotrtrojanowski@gmail.com.

www.agilerecord.com

71

Masthead
EDITOR Daz & Hilterscheid Unternehmensberatung GmbH Kurfrstendamm 179 10707 Berlin, Germany Phone: +49 (0)30 74 76 28-0 Fax: +49 (0)30 74 76 28-99 E-Mail: info@diazhilterscheid.de Daz & Hilterscheid is a member of Verband der Zeitschriftenverleger Berlin-Brandenburg e.V. EDITORIAL Jos Daz

ISSN 2191-1320
LAYOUT & DESIGN Daz & Hilterscheid WEBSITE www.agilerecord.com ARTICLES & AUTHORS editorial@agilerecord.com ADVERTISEMENTS sales@agilerecord.com PRICE online version:

free of charge

In all publications Daz & Hilterscheid Unternehmensberatung GmbH makes every effort to respect the copyright of graphics and texts used, to make use of its own graphics and texts and to utilise public domain graphics and texts. All brands and trademarks mentioned, where applicable, registered by third-parties are subject without restriction to the provisions of ruling labelling legislation and the rights of ownership of the registered owners. The mere mention of a trademark in no way allows the conclusion to be drawn that it is not protected by the rights of third parties. The copyright for published material created by Daz & Hilterscheid Unternehmensberatung GmbH remains the authors property. The duplication or use of such graphics or texts in other electronic or printed media is not permitted without the express consent of Daz & Hilterscheid Unternehmensberatung GmbH. The opinions expressed within the articles and contents herein do not necessarily express those of the publisher. Only the authors are responsible for the content of their articles. No material in this publication may be reproduced in any form without permission. Reprints of individual articles available.

Picture Credits
Katrin Schlke 1 iStockphoto.com/Tammy616 10 delater / pixelio.de 18 Stephanie Hofschlaeger / pixelio.de 22 Peter Smola / pixelio.de 26 Matthias Preisinger / pixelio.de 30 iStockphoto.com/Inok 32 flowfix Fotolia.com 38 iStockphoto.com/N_design 42 Anguane / pixelio.de 46 iStockphoto.com/AlexStar 50 tlorna fotolia.com 56 Michelle Albers fotolia.com 60 segovax / pixelio.de 64 Stephanie Hofschlaeger / pixelio.de 68

Index Of Advertisers
Agile Testing Days 2012 29 Belgium Testing Days 2012 8 CaseMaker 31 CAT Certified Agile Tester 2 CAT Certified Agile Tester in Orlando 5 Daz & Hilterscheid 73 IREB 49 iSQI 40 iSQI 45 Online Training 35 Testen fr Entwickler 37 Testing Experience Knowledge Transfer 33 Testing & Finance 2012 15

72

www.agilerecord.com

Training with a View

Dates * 05.04.1205.04.12 23.04.1227.04.12 05.03.1209.03.12 19.03.1223.03.12 10.04.1211.04.12 14.05.1215.05.12 28.03.1230.03.12 16.04.1218.04.12 05.03.1208.03.12 02.04.1204.04.12 16.04.1218.04.12 02.05.1204.05.12 29.05.1231.05.12 12.03.1216.03.12 07.05.1211.05.12 26.03.1230.03.12 26.03.1230.03.12 26.03.1230.03.12 07.05.1211.05.12 05.03.1209.03.12 16.04.1220.04.12 21.05.1225.05.12 12.04.1213.04.12 26.03.1227.03.12

Course Anforderungsmanagement CAT Certied Agile Tester (DE) CAT Certied Agile Tester (EN) CAT Certied Agile Tester (EN) HP Quality Center HP QuickTest Professional

Language Place German German English English German German Berlin Berlin Helsinki Amsterdam Berlin Berlin Berlin Helsinki Berlin Stuttgart Frankfurt Berlin Nrnberg Berlin Mdling/Austria Frankfurt Mdling/Austria Stuttgart Kln Mdling/Austria Stuttgart Berlin Berlin Berlin

Price 499,2100,2100,2100,998,998,1400,1600,1800,1495,1495,1495,1495,2100,2100,2100,2100,2100,2100,2100,2100,2100,800,998,* subject to modications all prices plus VAT

IREB Certied Professional for Requirements Engineering Foundation Level (DE) German IREB Certied Professional for Requirements Engineering Foundation Level (EN) English ISTQB Certied Tester Foundation Level ISTQB Certied Tester Foundation Level Kompaktkurs ISTQB Certied Tester Foundation Level Kompaktkurs ISTQB Certied Tester Foundation Level Kompaktkurs ISTQB Certied Tester Foundation Level Kompaktkurs ISTQB Certied Tester Advanced Level Technical Test Analyst ISTQB Certied Tester Advanced Level Technical Test Analyst ISTQB Certied Tester Advanced Level Test Analyst ISTQB Certied Tester Advanced Level Test Analyst ISTQB Certied Tester Advanced Level Test Analyst ISTQB Certied Tester Advanced Level Test Analyst ISTQB Certied Tester Advanced Level Test Manager ISTQB Certied Tester Advanced Level Test Manager ISTQB Certied Tester Advanced Level Test Manager Testen fr Entwickler Testmetriken im Testmanagement German German German German German German German German German German German German German German German German

more dates and onsite training worldwide in German, English, Spanish, French on our website: http://training.diazhilterscheid.com

Kurfrstendamm, Berlin Katrin Schlke