Agilerecord Magzine

The Magazine for Agile Developers and Agile Testers
Management and Leadership in Software Organisations

www.agilerecord.com free digital version made in Germany ISSN 2191-1320
issue 10
May 2012
2013
January 15 - 17 Vienna ,
Software Quality DayS

The annual conference on software quality and testing
call for papers
Submit your contribution for 2013 now!
www.software-quality-days.com/en/lecturers
The software Quality Days is one of the largest events on software quality worldwide. This makes it a must for anyone interested in software quality, testing and quality oriented system & software development.
Date Venue Options Languages Submission
January 15 - 17, 2013 Vienna Workshop/tutorial Practical presentation Extended practical presentation Experts-talk Scientific presentation English German until May 31, 2012
Quality - investment for the future

topics for presentations and tutorials: Requirements, modelling and architecture Test methods and test automation Agile methods, processes and quality Embedded systems and mechatronics Integration and deployment Usability and security And many more!
www.software-quality-days.com
Editorial
Dear reader, This is the first issue where the editorial board started to work! Thanks to all of them for their reviews and marks. And also thanks to all the authors. Weve been thinking how to improve the magazine and reach more readers worldwide. We need you for this success so that we can also bring you the trends, knowledge and experiences from the whole community. Please spread the word! In the last weeks we decided to run a new conference that fits the gap in our conference list. We will run the AgileDev; a new conference for Agile Development Practices. I think that this will close the existing gap. The conference will probably take place in Berlin or in London; we dont know yet for sure. Have a look in a few days at www.agiledevpractices.com.We will soon run the call for papers. The program for the Agile Testing Days has been published. I hope you like it. We are having a good response, and I think that we will have a great conference. We will keep you posted. Have a look from time to time at www.agiletestingdays.com We are facing the summer time after a nice Easter time. I enjoyed the time well and de-stressed my life a little bit. I enjoyed some long walks in the forest and having nice long talks with the people I love. Now back at my desk, Im preparing for the Testing & Finance in London. A hard job. It looks like we will have a full house. I will present to some people our new baby SWE Guild. Please pass by to know more. I wish you a pleasant time, enjoy your work, life and of course the magazine. It has been made for you. Best regards
Jos Daz
www.agilerecord.com
Contents
Editorial 1 Editorial Board 4 Agile Testing in the Real World It Takes a Village 11 by Lisa Crispin Lead yourself! 14 by Huib Schoots Increasing test awareness in a scrum team 16 by Milvio Daz The Agile Project Manager There Can Be Only One! 19 by Robert Galen Management And Leadership In Software Organisations 24 by Plamen Balkanski Virtual Teams and Conflicting Leadership Styles Case Study 28 by Raja Bavani Beyond Servant Leadership in Agile Projects 33 by Rathinakumar Balasubramanian Leading Software Teams, The Agile Context 36 by Nishant Pandey How to navigate through Scrum a guide for Scrum Masters 39 by Katja Roth & Jane Trmner Radical ManagementSM A Paradigm Shift for the 21st Century 44 by Simon Roberts & Birgit Panzram Leadership and not management in an Agile team 48 by Leanne Howard Risk Poker: Risk based testing in agile projects 51 by Jurian van de Laar Masthead 54 Picture Credits 54 Index Of Advertisers 54
www.agilerecord.com
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.27.07.12 in Munich, Germany 23.27.07.12 in Karlsruhe, Germany 27.31.08.12 in Frankfurt, Germany 24.28.09.12 in Stuttgart, Germany
(German tutor and German exam) Sergejy Galushko Fotolia.com
11.15.06.12 in Stockholm, Sweden 02.06.07.12 in Orlando, USA 03.07.09.12 in Helsinki, Finland 15.19.10.12 in Oslo, Norway
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 3
Editorial Board
David Alfaro
Josh Anderson
Plamen Balkanski
Matt Block
Jose Manuel Beas
Jennifer Bleen
Andreas Ebbert-Karroum
Pat Guariglia
Ciaran Kennedy
Roy Maines
Steve Rogalsky
Dave Rooney
Steve Smith
Zuzanna Sochova
Declan Whelan
Go to www.agilerecord.com/editorial_board.php to read their biographies
www.agilerecord.com
November 1922, 2012 in Potsdam, Germany

Dorint Hotel Sanssouci Berlin/Potsdam www.agiletestingdays.com

Become Agile Testing Days Sponsor 2012

The Agile Testing Days 2012, from November 1922 is an annual European conference for and by international professionals involved in the agile world. Since 2009 we got a lot of addition to our agile family and we are happy to present the 4th edition of the Europeans greatest agile event of the year. What you will expect: 4 inspiring conference days 9 stunning keynotes 10 instructive tutorials 12 informative sponsor sessions 40 amazing talks More than 70 speakers Over 400 testers from all over the world And an exhibition area of 500sqm
Tutorials
Time 08:0009:00 09:0017:30 09:0017:30 09:0017:30 09:0017:30 09:0017:30 09:0017:30 09:0017:30 09:0017:30 Registration Management 3.0 Workshop Jurgen Appelo Making Test Automation Work in Agile Projects Lisa Crispin Transitioning to Agile Testing Janet Gregory: Introduction to Disciplined Agile Delivery Scott W. Ambler Beheading the legacy beast Ola Ellnestam Fully integrating performance testing into agile development Scott Barber Mindful Team Member: Working Like You Knew You Should Lasse Koskela Mind Maps: an agile way of working Huib Schoots & Jean-Paul Varwijk Winning big with Speci cation by Example: Lessons learned from 50 successful projects Gojko Adzic Software Testing Reloaded So you wanna actually DO something? Weve got just the workshop for you. Now with even less powerpoint! Matt Heusser & Pete Walen Tutorial
09:0017:30
09:0017:30
All tutorials include two co ee breaks (11:00 and 15:30) and lunch (13:0014:00).

Conference Day 1
Time 08:0009:20 09:2009:25 09:2510:25 10:2510:30 10:3011:15 5A assess and adapt agile activities Werner Lieblang & Arjan Brands The Agile Manifesto Dungeons: Lets go really deep this time! Cecile Davis Moneyball and the Science of Building Great Agile Team Peter Varhol Balancing and growing agile testing with high productive distributed teams Mads Troels Hansen & Oleksiy Shepetko Track 1 Track 2 Track 3 Registration Opening Keynote: Disciplined Agile Delivery: The Foundation for Scaling Agile Scott W. Ambler Break Get them in(volved) Arie van Bennekum Testing distributed projects Hartwig Schwier Track 4 Vendor Track
11:1511:40 11:4012:25
Break We Line Managers Are Crappy Testers Can We Do Something About It Ilari Henrik Aegerter Lunch Keynote: Myths About Agile Testing, De-Bunked Janet Gregory & Lisa Crispin The many avors and toppings of exploratory testing Gitte Ottosen
12:2513:45 13:4514:45
Time 14:4516:15
Track 1 Consensus Talks 10 min. each
Track 2 Open Space Cirilo Wortel
TBD TestLab Bart Knaack & James Lyndsay
TBD Testing Dojos
TBD Coding Dojos Meike Mertsch & Michael Minigshofer
Vendor Track Product Demo
Time 16:1516:40 16:4017:25
Track 1 The Beating Heart of Agile Andrea Provaglio
Track 2 Why World of Warcraft is like being on an agile team, when it isnt and what we can learn from online role playing games Alexandra Schladebeck
Track 3 Break Agile communication: Back and forth between managers and teams Zuzana Sochova & Eduard Kunce
Track 4 Developers Exploratory Testing Raising the bar Sigge Birgisson
Vendor Track
17:2517:30 17:3018:30 19:00
Break Keynote: Self Coaching Lasse Koskela Social Event

Conference Day 2
Time 07:3009:20 08:1008:55 09:2009:25 09:2510:25 10:2510:30 10:3011:15 Continuous Delivery of Long-Term Requirements Paul Gerrard Experiences with introducing a Continuous Integration Strategy in a Large Scale Development Organization Simon Morley Testing seen through a puzzle Eusebiu Blindu Track 1 Track 2 Track 3 Registration Early Keynote: TBD Opening Keynote: How to change the world Jurgen Appelo Break How releasing faster changes testing Alexander Schwartz Break Skills & techniques in the modern testing age Rik Teuben Continuous Delivery: from dream to reality Clement Esco er Ten qualities of an agile test-oriented developer Alexander Tarnowski Testers are bearers of good news Niels Malotaux Track 4 Vendor Track
11:1511:40 11:4012:25
12:2513:45 13:4514:45
Lunch Keynote: Adaptation and Improvisation but your weakness is not your technique Markus Grtner
Time 14:4516:15
Track 1 Consensus Talks 10 min. each
Track 2 Open Space Cirilo Wortel
TBD TestLab Bart Knaack & James Lyndsay
TBD Testing Dojos
TBD Coding Dojos Meike Mertsch & Michael Minigshofer
Vendor Track Product Demo
Time 16:1516:40 16:4017:25
Track 1 From CI 2.0+ to Agile ALM Michael Httermann
Track 2 Testers Agile Pocketbook Stevan Zivanovic
Track 3 Break Extending Continuous Integration and TDD with Continuous Testing Jason Ayers Break
Track 4 Excelling as an Agile Tester Henrik Andersson
Vendor Track
17:2517:30 17:3018:30
Keynote: Reinventing software quality Gojko Adzic

Conference Day 3
Time 07:3009:10 08:1008:55 09:1009:15 09:1510:15 10:1510:20 10:2011:05 Exceptions, Assumptions and Ambiguity: Finding the truth behind the Story David Evans Combining requirements engineering and testing in agile Jan Jaap Cannegieter BDD with Javascript for Rich Internet Applications Carlos Bl & Ivan Stepniuk TDD-ing Javascript Front Ends Patrick Kua Track 1 Track 2 Track 3 Registration Early Keynote: TBD Opening Keynote: Fast Feedback Teams Ola Ellnestam Break Automation of Test Oracle unachievable dream or tomorrows reality Dani Almog Break Archetypes and Templates: Building a lean, mean BDD automation machine for multiple investment platforms Mike Scott & Tom Roden Technical Debt Thomas Sundberg Taking over a bank with open source test tooling Cirilo Wortel You Cant Sprint All the time the importance of slack Lloyd Roden Track 4 Vendor Track
11:0511:30 11:3012:15
12:1513:00
Agile Solutions Leading with Test Data Management Ray Scott
Changing Change Tony Bruce
Changing the context: How a bank changes their software development methodology Huib Schoots
13:0014:10 14:1015:10 15:1015:15 15:1516:00 Thinking and Working Agile in an Unbending World Peter Walen Sprint Backlog in ATDD Ralph Jocham
Lunch Keynote: The ongoing evolution of testing in agile development Scott Barber Break Mobile test automation at mobile scale Dominik Dary & Michael Palotas Break Keynote: The Great Game of Testing Matt Heusser Closing Quality On Submit, Continuous Integration in Practice Asaf Saar
16:0016:05 16:0517:05 17:05

Become Agile Testing Days Sponsor 2012

For this phenomenal event, we are looking for supporters. Please have a look at our portfolio and create your own sponsorship package:
Exhibitor
Diamond Exhibitor: Platinum Exhibitor: Gold Exhibitor: Silver Exhibitor: 16,200.00 * 10,800.00 * 5,400.00 * 3,600.00 *
Conference Sponsor
MIATPP Award Trophy Sponsor: 2,970.00 * Conference Bag Insert: Co ee Break Cup Sponsor: Social Event Sponsor: 495.00 * 1,530.00 * 8,990.00 *
Media Sponsor
Program First Page Advert: Program Full Page Advert: Program Half page Advert:
* Early Bird price valid until July 31, 2012. Please nd details on packages online at www.agiletestingdays.com
Session Sponsor
990.00 * 495.00 * 249.00 * 90 Minutes Product Demo: 45 Minutes Early Keynote: 2,250.00 * 2,250.00 *
Exhibitors & Supporters 2011:
The Austrian Software Test Experts!
A Daz & Hilterscheid Conference Daz & Hilterscheid Unternehmensberatung GmbH Kurfrstendamm 179 10707 Berlin Germany Phone: Fax: +49 (0)30 74 76 28-0 +49 (0)30 74 76 28-99 info@agiletestingdays.com www.agiletestingdays.com www.xing.com/net/agiletesting www.twitter.com/AgileTD
Column
Agile Testing in the Real World It Takes a Village

by Lisa Crispin
The first phrase of the African proverb, It takes a village to raise a child, can be applied to many aspects of software development as well. It takes a village of software practitioners and business experts to deliver a high-quality product that is valuable to its customers. To succeed individually in todays fast-paced world of technology and business, we need our own village. Other people can help us by mentoring, coaching, teaching, or simply inspiring. Each of us can enjoy the rewards of paying forward the help that we receive. How can you find your own village? Back when I started in the software business, my circle of professionals was confined mainly to the data processing department where I worked. As I look at my career so far, I see that my own professional horizons expanded along with my ability to network with a wider and wider circle. As I discovered magazines, conferences and local user groups, I was able to learn new skills faster. That helped me land more interesting jobs with increasingly better teams. Today, thanks to mailing lists, social networks, online communities, instant messaging and Skype, I continually improve my own skills, and share my experiences with others. Dunbars Number says that a person can only maintain stable social relationships with an average of 150 other people (http:// en.wikipedia.org/wiki/Dunbars_number). But maybe we dont have to have a stable relationship with each person to benefit from knowing them. This morning, I tweeted a request for anyone who had used a particular testing framework with a particular CI tool, to find out how well the test result reporting works. Someone I dont know or follow on Twitter responded with a useful link that I probably would not have found googling on my own. I pay it forward too, helping others as Ive been helped. I do build stable social relationships with many people whom I meet via Twitter, mailing lists such as agile-testing@yahoogroups. com, and testing communities such as Weekend Testing (weekendtesting.com) and Software Testing Club (softwaretestingclub. com). I can go to a conference in any part of the world, and meet old friends in person for the first time. For example, I first heard of Gojko Adzic because of his work with DbFit and his early books. We kept in touch online for a few years. I finally got to meet him at Agile Testing Days 2009. Ive learned so much from Gojko, whether were working together in person or communicating in Cyberspace. And that is just one of dozens maybe hundreds! of examples I could give you. Members of a community help build it in different ways. Im not much good at building, say, a local user group up from scratch, but I enjoy connecting individuals with each other for their mutual benefit. Some people I know seem to be natural community-builders. Yves Hanoulle is a perfect example. He coordinates a public Google calendar of agile conferences (http://www.hanoulle.be/2010/11/ agile-conferences-calendar/) and events (http://www.hanoulle. be/2011/05/google-agile-events-calendar/). He helps organize coach retreats and agile games days. Ive been inspired by the practitioners profiled in his WhoIs interview series (now a book, http://leanpub.com/WhoIsAgile). Through these interviews, Ive learned interesting new facts about people I already knew, and have met some that otherwise I might never have run across. Thanks to people like Yves, whenever I need help or want to try new experiments, I have a diverse community of helpful software professionals to whom I can turn. Theres a planet of fascinating people in our software community, and the internet helps draw us together. Given that youre read-
www.agilerecord.com
11
ing Agile Record, youre obviously a person who likes to learn and grow. Surround yourself with a village to fuel your passion. Take advantage of online communities, mailing lists, blogs and social networks to further your own career growth. Get to know new colleagues online, and you may have the opportunity to meet them face-to-face someday. Enjoy contributing your own experiences and ideas to help others in your professional community expand their horizons. I guarantee your village will make your work more fun and rewarding.
> 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
Readers Opinion Youd like to comment on an article? Please feel free to contact us: editorial@agilerecord.com
12
www.agilerecord.com
Advertise at
www.agilerecord.com
2nd edition, June 21st 2012, World Trade Center - Rotterdam, The Netherlands
CONFERENCE ORGANIZATION
annual conference and exhibition

Meet the world's leading Test Automation experts, get the latest insights on emerging technologies, proven practices, and trends!
After the rst successful edition of Test Automation Day (2011), we would like to welcome you to the 2012 edition in Rotterdam, the Netherlands! The independent conference committee will organize an exciting collection of keynote sessions, business cases and workshops presented by national & international thought leaders and experts.
With contribution of (amongst others - from left to right):
FOUNDING PARTNER
PARTNERS
SPONSORS
Arie van Deursen, Chairman, Professor in Software Engineering, Delft University of Technology Elfriede Dustin, Sr. Systems Engineer, IDT Scott Barber, CTO, PerfTestPlus Machiel van der Bijl, Specialist Model Based Testing, Axini Pepijn van de Vorst, Test Consultant, Ordina Derk-Jan de Grood, Test Expert & Trainer, Valori disco
100,
unt for readers of
EXHIBITORS
Register with the special member code! As a reader of Agile Record Magazine, youll get a 100,- discount. Register with the code: TAD2012-AGI on www.testautomationday.com and pay only 195,- (excl. VAT) for Test Automation Day!
KZA BV RANOREX SQS NEDERLAND B.V. VX COMPANY
www.agilerecord.com MORE INFORMATION AND REGISTRATION AT WWW.TESTAUTOMATIONDAY.COM
PARTICIPANTS KNOWN MARCH 23TH 2012
13
Column: An agile testing future

Lead yourself!
by Huib Schoots
There is a lot to be said about management and leadership in IT. This column is about a very specific kind of leadership: selfleadership. It is about you and about being a true leader of yourself. There is no one who needs more management than you. We constantly manage ourselves; we need self-management to do everything we do. You can try to manage yourself, but I would advise to start being a true leader for yourself. Management is doing things right: about being efficient, leadership is doing the right things: about being effective1. The difference between management and leadership is described in the article I recently read on changingminds.org about leadership vs. management2. The main difference is that managers have subordinates and leaders have followers. The list in this article gives a good insight in the difference. In the TED talk How great leaders inspire action3, Simon Sinek illustrates that a cause helps people to get inspired. In his talk he says: Those who lead inspire us. We follow them not because we have to, but because we want to. We follow those who lead not for them, but for ourselves. And it is those who start with why, that have the ability to inspire those around them and find others who inspire them. In the video Sinek also tells a story about the run for the first flight. The Wright Brothers work with almost no budget and tooling but are driven by a cause, a purpose and a belief. In comparison, their competitor Langley is driven by results: he wanted to become rich and famous. We all know who were the first to fly. This story gives us an interesting message: inspiration and dedication drive success. And that is the key to leadership! You can manage yourself by having objectives and making shortterm plans. Reacting to things happening, focusing on what you can get out of situations. Not taking too much risk by taking the beaten path. Or you can make things happen by critically trying new things, following your heart by doing those things that you believe in, and by giving yourself energy by being proactive. Some weeks ago I had an interesting conversation with a tester friend. He was complaining about his work, the chances he doesnt get, and he was obviously demotivated and blaming people around him. It was a nice sunny day and we took a walk to buy a sandwich. After the walk we sat and had coffee. I listened to his story and asked some questions to keep his story going. When I asked him about his future plans and ambitions, he gave me an interesting answer: I dont have a plan, I always take things as they come. Then I asked him about what he finds important in his job and why. It became silent. He didnt have a clear answer. Self-management is hard. Being a leader of yourself is even harder. It takes a lot of courage, vision and self-knowledge. Taking chances will make you fail once or twice. But by making mistakes you will become stronger and you will learn from them. One of my teachers often said: when you do something you like, you need to practice to get better. The better you get, the more you are going to enjoy it. The more you enjoy it, the more you will do it. A beneficial circle that empowers itself. In self-managing your career4 Gwen McCauley describes seven steps to effectively self-manage your career. She states that there is incredible freedom that comes from taking charge of your life and career, and I can only agree. Know yourself, invest in yourself and know what you want and why you want it. Another inspiring and useful model I find in Stephen Coveys seven habits of highly effective people. Widely known and often used when talking about leadership. For those who are not familiar with this awesome book, here they are: 1. 2. 3. 4. 5. 6. 7.
1 Drucker, Peter F. The Practice of Management. Oxford: Elsevier Ltd., 1955. 2 http://changingminds.org/disciplines/leadership/articles/manager_leader.htm 3 http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
Be proactive Begin with the end in mind Put first things first Think win/win Seek first to understand, then to be understood Synergize Sharpen the saw
Stephen Covey: Seven habits of highly effective people5
4 5
http://www.ouicoach.com/docs/car_self-managing.pdf https://www.stephencovey.com/7habits/7habits.php
14
www.agilerecord.com
When you study books and articles about leadership, you will discover that almost all mention doing things because you believe in them and doing things proactively. Try Google and find some interesting articles written about self-leadership. I found SelfLeadership: Leading Yourself to Personal Excellence6 and 12 Rules for Self-Leadership7; two articles which I like. The following personal story illustrates the importance of trying to be a true leader of yourself: Many years ago I did one of my first projects in a lead role. I wasnt happy and was complaining a lot. Things didnt go as I wanted and I was blaming everybody and everything around me. The project I did wasnt going the way it should be at all. On a Friday afternoon my manager called me into his office and 30 minutes later I stood outside with the minutes of our short conversation, signed by two managers and myself. This was a noted conversation as it was called and it was one step away from an official warning, two steps away from getting fired. That night I had a beer with a friend in a bar and I was furious. How could they do this to me? He asked me a simple question: Is the feedback they gave you honest and true? Yes, but I started and then it became clear to me, it was me who had to do something. On Monday I called my manager and asked if he could explain what he expected me to change. And, even more important, I asked for help. So how does self-management or self-leadership relate to agile or since I am a tester to testing? Agile is a mindset and relies heavily on people collaborating, continuous improvement and learning to excel. In an agile environment the team is focused on people and relations. A winning team for a project is built around motivated individuals. The team is responsible for their work and they are often less managed. Because the team is more self-responsible, it is more likely that people will look beyond their disciplines and help each other to get the job done. And everything is happening in short iterations. Here we need self-management: doing things right, but even more we need self-leadership doing the right things. In (agile) testing I see a parallel: of course all the stuff mentioned above applies. But lets have a closer look. Good testing in general, but exploratory testing in particular, requires a lot of self-management. Excellent testing requires self-leadership. Michael Bolton wrote a nice post on his blog called heuristics and leadership8 where he says: We believe that excellent testing starts with the skill set and the mindset of the individual tester. Other things might help, but excellence in testing must centre on the tester. He also did a great presentation titled Exploratory testing (and) leadership9 in 2009 that is very worthwhile checking (or should I say testing?).
So, in short, stop managing yourself and start leading yourself into a bright future! References and links 1. Drucker, Peter F. The Practice of Management. Oxford: Elsevier Ltd., 1955. 2. 3. 4. 5. 6. 7. 8. 9. http://changingminds.org/disciplines/leadership/articles/ manager_leader.htm http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html http://www.ouicoach.com/docs/car_self-managing.pdf https://www.stephencovey.com/7habits/7habits.php http://www.emergingleader.com/article4.shtml http://www.lifehack.org/articles/lifestyle/12-rules-for-selfleadership.html http://www.developsense.com/blog/2010/05/heuristicsand-leadership http://www.developsense.com/presentations/200911-STC9000-ExploratoryTestingLeadership.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
http://www.emergingleader.com/article4.shtml
7 http://www.lifehack.org/articles/lifestyle/12-rules-for-self-leadership. html 8 http://www.developsense.com/blog/2010/05/heuristics-and-leadership
9 http://www.developsense.com/presentations/2009-11-STC9000ExploratoryTestingLeadership.pdf
www.agilerecord.com
15
Increasing test awareness in a scrum team

by Milvio Daz
Different companies have their own ecosystems which results in different ways to run projects, even within the same companies. The Scrum team develops a personality of its own a blend of the individual personalities. After a few sprints, the team gets a reputation for being on time, effective, boring or fun. Which team would you rather work for an effective and boring team, an effective and fun team, an ineffective and boring team, or an ineffective and fun team? Id rather work in a fun team that is (hopefully) effective too. In this article, I will share how I tried to bring more focus to testing and the effort required to be a test leader in a Scrum team, plus having a little fun along the way. In Scrum, the team takes responsibility for delivering a product that has quality and inspires pride. Working at a small company, the test team faces some particular challenges. Sometimes a tester is responsible for leading the test effort for teams whose usual size is up to 8 members. Although everyone is meant to do testing, from Product Owner to tester, members have their responsibilities, knowledge domains and time constraints. Sometimes the testing effort is not represented well or it is not understood how much time, planning and energy is required to meet the sprint deadline. Planning certainly helps, but it is usually not 100% correct. There is always a 20%, or maybe more probably a 50% chance that estimating during sprint planning is off the mark. The Scrum team has to consider that the tester needs domain knowledge of the product (I will refer to tester as the person doing the test, test leader as the person responsible for planning the test effort). Working on a complex product means moving in different areas in a short time and knowing when a behavior is expected. Communication is important, and using different tools to convey the message is important. To paraphrase the United States President Abraham Lincoln, You can get some of your message to some of
the people all of the time, and all of the people some of the time, but you cannot get all of your message to all of the people all of the time. Use all the communication tools at your disposal: the daily Scrum stand-up meeting, email, SharePoint, smoke signals, snail mail, etc. I started printing test plan objectives, schedules and placed them behind my desk, just in case I was not available when someone came by for a chat. Part of the testing task during a sprint is to validate defects and confirm functionality. For our projects, due to the way our software works, we added another task: performing a production simulation test (PST). This task, though simple, is very time consuming; defining the scenario and test cases, creating environments for the team, sometimes creating data that need to match the test cases, serving as technical lead during the test (answering questions like How do I log in?). At some point we rotated the responsibility of executing the PST; perhaps I was sick one day and another team member took the responsibility. I am happy to say that after that occasion, the PST was highlighted as a positive action during the sprint at each retrospective. The team realized the energy required to configure, plan, execute and review the PST. That was a big win for the test team in general since all the projects ran a PST during their sprints. On the down side, the rotation of PST responsibility was short-lived; no one volunteered to perform the PST and it became a task designated to the test leader (a sacrifice for the greater good). The sprint demo is a very important occasion where the team presents the results of the latest iteration. We usually made slidebased demos plus a product demo. Test became a part of the slidebased demo. This was an opportunity to share some thoughts about the work done or the quality of the product. During one sprint, we had some technical difficulties configuring the environment for a PST. For the demo, the obvious thing for me was to show a slide with a frustrated television cartoon character getting progressively angry and finally changing into an exploding green monster. Everyone had a good laugh at the demo and there was a release of frustration.
16
www.agilerecord.com
Negatively, there was expectation for all subsequent demos that there would be the same display of comic genius. During another sprint, the theme was integration between three different project teams using the Hamburger method for testing and developing. For the demo, I assigned each team a specific hamburger meal, printed the slide and posted it by my desk. Another advantage of a test section during the demo is to display progress of the entire project. As a project can consist of one or more sprints, the demo provides an opportunity to share the progress of the entire projects test effort and to obtain feedback (will you do volume testing for this project?). Finally, a positive attitude and social competence are important factors when working with teams; a smile goes a long way. This sets the tone for the conversation, even if the subject to be discussed is negative in nature. It also helped that I became world famous in Stockholm for my salsas, guacamole and mojito. I recommend these at least once a sprint, preferably after the demo.
> About the author

Milvio Daz Has over 5 years experience working as a test leader in a Scrum software development team. He has experience in various roles as tester, test coordinator and test manager. He has passion for test improvements and a great deal of team spirit. He is currently working as a test leader for Logica Sverige and holds the ISQTB Foundation Level certification.
Book your CAT training in USA!

pic: Sergejy Galushko Fotolia.com grahpic: Wikimedia Commons
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. Open Seminar in USA: July 26, 2012 in Orlando, Florida
CAT goes USA
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
17
Online Training & Exam Preparation
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) Sample Questions & Answers, Exam Simulation, Quiz & Exercises, Videos
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
The Agile Project Manager There Can Be Only One!

by Robert Galen
I hope Im not the only reader who remembers the Highlander movie & television series. Duncan McLeod was an immortal amongst others who was fighting to be the last remaining immortal. In each episode, there was inevitably a decapitation or two as the immortal population was reduced to the final one. I use the symbolism of the Highlander to remind myself of several aspects of agile project management. The first relates to focused teams and our earnest effort to reduce all levels of multi-tasking. The second reminder is the subject of what I want to explore in this article the notion of investing in a single team to create a working model for your agile adoption efforts. The team isnt just any team. Its your example team; a high performance agile machine that illustrates sound principles and delivers on the promises of agility. Its a role model to other teams and proof that you can be agile in your specific organization and culture. I have a bit of mad scientist in me, and this is the team you experiment with in trying out new and novel approaches for your domain. Its the first team that moves from Scrum to Kanban. Or its the first team that tries out Cucumber as a BDD mechanism, while including the whole team in crafting acceptance test driven automation. Lets explore some of the characteristics of a singular example agile team. Lets first explore what the team isnt The team isnt composed of special developers, the best of the best, or egos full of themselves. Yes, you might have some more seasoned folks on the team, but in ratios that are representative of your other teams and the overall population. The team isnt paid a premium wage or compensated in some special way. In many ways they represent a cross-section of your teams in experience levels and compensation structures.
The team isnt isolated from challenges such as interruptions, multi-tasking or dealing with unclean code. They have an equal dose of the challenges facing every other team. And finally, the team isnt placed on a pedestal for everyone to see. Yes, its your example team and the one that illustrates the best properties and practices of your agile adoption and progress. However, theyre also just another team and equal to everyone else. What the team is If you buy into creating a model team, its sort of hard to figure out what that might look like in the wild. While I dont want to give you a prescriptive list like, do these five things and a magical event will occur creating a perfect model team, there are some hints I want to provide for behaviors and practices that you might want to model for. Ive categorized them into four areas: locale, smells, swarming, quality, and plan adjustments that well explore in detail next. Locale The team is co-located and cross-functional. If at all possible, they sit together at one large table and work around and across from each other. Their room has white boards and plenty of wall space for information radiators that are meaningful to the team The team has some privacy, being located in a conference room or other walled-in area. Theyre insulated from random noise and interruptions that might result from too open a space. Ive often used the term War Room to describe the room dynamics. The quarters are relatively tight in that everyone in the room is working closely together. Everyone can hear every conversation that is going on in the room. If someone is working remotely or on the phone, the room can hear the interactions.
www.agilerecord.com
19
I often get the question of whether you can leverage distributed or remote team members as part of your model team. I think the answer is normally yes. What you want to do, however, is allow budget for travel, training, and tooling that supports bringing your distributed team together as much as possible. For example, when youre initially forming your team, its a really good idea to bring everyone together for some initial introductions, training, and team-building. How else would you form a high-performing team? Smells An often used term with respect to agile teams is smells. These are patterns or trends that one observes when collaborating with the team. Here are a few examples. Theres a buzz in the room, its rarely the case where everyone is quietly working. Instead, team members may have headsets or earphones that allow for a sense of quiet if they need to get away for some private work. Work is done primarily in pairs, but there are no restrictive rules which say you MUST pair at all times. Instead, its a more natural and organic level of pairing based on common sense, small groups, and the dynamics of the work. And everyone on the team pairs in one way or another! Theres quite a lot of dynamic discussion going on in clusters. A lot of white board conversations. And every conversation ends up moving over to working code as the final arbiter of discussion and progress. So its about hovering around screens and talking about software design, behavior, adjustments, tests failing/passing, bugs, etc. A final smell might be chaos. I like to describe agile methods as being an uncomfortable methodology. They are quite strict in practices and theres an overwhelming feeling of controlled chaos, especially if youre part of a well-performing agile team. The point is that its not totally scripted. Discoveries happen. Plans change. Adjustments need to be made. And everyone quickly adjusts and moves on. The goal that the team has committed to for the iteration or sprint is the thing that keeps the train on the tracks, with everyone focused towards meeting that goal. Throughput and swarming I frequently get asked whether the developers move ahead of the testers on the team during a sprint. This question implies a distinct separation between development and testing work and aligns the amount of work done along skill and functional boundaries. My answer is always the same: No. The team shouldnt get partial credit for development work done. In fact, they should only get credit for fully done features, stories that are complete, with acceptance criteria met and completely demonstrable. Given that definition, teams would be better served to swarm around their work, limiting their stories in-progress (WIP) and getting their work done as soon as possible. 20 www.agilerecord.com
In fact, this isnt to be considered an option, but the way in which well-performing and mature agile team should naturally behave. They understand that throughput (the time it takes to move a story from start to finish) matters. And that team collaboration around getting small sets of stories done as soon as possible (swarming) is the best way to do this. In my experience, its a whole lot easier to talk about this than it is to deeply instill these behaviors in agile teams. This is why youd want to get it right in your example team and see the best ways to influence this wonderful behavior. Quality Its hard for me to explain the myriad of ways that quality activity needs to change in order for the team to truly be high performing. I guess the first attribute is that everyone on the team understands that quality is something you build-in and not something thats tested-in. Just the other day a colleague asked me what I thought were the highest value quality practices that influenced agile high performance. Perhaps sharing my reply would help. Here is the list of high-impact practices that I sent him and that I think are representative of an outstanding agile team: 1. Fostering a whole-team view towards quality. Moving testers to the front of the line in that they collaborate on the requirements to get the solutions right. Pairing in general: pair-programming, pair-testing, triadpairing, paired code reviews, etc. Having the ability, willingness, and aggressiveness to stop work and apply corrective action(s) immediately. Test planning on an iteration and release basis while initiating whole team collaboration around what and how to test. Applying exploratory testing in a paired fashion, leveraging session-based (charter-driven) exploratory testing across teams. Performing active agile release planning so that teams gain a broad view towards dependencies and integration including a DevOps or continuous deployment (CD) mindset. Naturally applying Unit Testing / TDD (Test-Driven Development) techniques within teams. Naturally applying ATDD / BDD (Acceptance Test Driven Development / Behavior Driven Development) and driving triad collaboration and conversations. The focus here should be collaboration first and automation second. Properly preparing for and conducting powerful sprint reviews or demos that engage stakeholders and customers to provide engaged, real-time feedback.
2. 3. 4. 5.
6.
7. 8.
9.
10. The Mike Cohn strategy of the Agile Test Pyramid works, so leverage it including the notion of multiple tools and layered approaches.
Daniel Kvarfordt - Fotolia.com
Enjoy Test Case Design in the Cloud

CaseMaker SaaS supports systematically the test cases design by covering the techniques taught in the ISTQB Certied Tester program and standardized within the British Standard BS 7925. The implemented techniques are: Equivalence Partitioning, Boundary Check, Error Guessing, Decision Tables and Pairwise Testing. Furthermore Risk Based Testing is supported. CaseMaker SaaS ts between Requirement Management and Test Management/Test Automation.
Subscribe and try for free! Decide afterwards. One license starts at
75
/month (+ VAT)
http://saas.casemaker.eu
The first three quality differentiators listed are in order of priority. Beyond those, theyre not in any particular order. You might not need to apply all of these approaches to achieve high performance, but the list does imply some of the breadth and depth to effective quality practices. And I hope that I didnt imply that testing was equivalent to quality. Micro-adjustments and the stand-up One of the most misunderstood aspects of agile teams is the nature of the teams commitment to a body of work in their sprint and then gathering to discuss their progress in the daily scrum. You often see teams look at their sprint plan as being a fixed set of user stories and their associated tasks. They commit to these cards and work diligently to execute to their plan. Many teams allow their traditional planning instincts to rule too much within their sprints. The tasks and stories should only be a means to an end. The sprint goal is what the team commits to and in the daily stand-up they should be discussing progress towards achieving that goal and anything that comes up which: 1. 2. 3. impedes or blocks achieving the goal, provides new information that adds, changes or removes work to support the goal, or Leads to discovery that influences interpretation of the goal refactoring, under/over estimation, interruptions, skill gaps, etc.
so far as to name his website www.exampler.com. Brian is a firm believer in examples being a wonderful communications device to focus dialog towards solutions. I agree. So is the point of this article to create an example team and then be done with it? NO! Its to create a model team as part of your agile transformation and then leverage the knowledge gained from them to improve your overall adoption approaches, techniques, and tools so that youre consistently raising the bar and improving. A team that you can adapt with and learn from; one that is strongly embedded in your organizational culture and problem domain, and a team that can simply help guide your evolutionby example. Thanks for reading, Bob.
These should be the real focus of the team. In the daily stand-up, the discussions should surround what Ill call the micro-adjustments that an agile team makes each and every day. These adjustments are goal-based discussions between the team and the Product Owner concerning goal achievement. Often, they require thinking about changing or jettisoning agreed scope within either the sprint or ultimately the release. These are healthy discussions that get to the root of the agile methods just enough and simplest possible solution lean principles. Moving from a follow-the-plan focus towards a collaborative, micro-adjustment focus is one of the hallmarks of a high-performance team; an agile team that focuses on solving customer problems via their goals. Wrapping up One of my reflective improvements in many coaching gigs is not establishing a model or example team quickly enough. Its usually driven by my need for an example that illustrates good agile practices from the same context that were initiating agile adoption; one that I can direct teams towards so that they can view an approach or technique beyond my just talking about it. Brian Marick is a well-respected agile testing consultant and coach. Brian often speaks about the power of using an example and will often ask for one; an example for a user story, an example of an acceptance test, an example reflecting the customers problem, an example of a design youre discussing, etc. He has even gone
> About the author

Bob Galen is a VP and Agile Coach at Deutsche Bank Global Technologies in Cary North Carolina. Hes also President 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. He can be reached at bob@rgalen.com
22
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* 06.08.06.12 19.21.06.12 25.27.09.12 16.18.10.12 16.18.10.12 27.29.11.12 27.29.11.12 27.29.11.12 18.20.12.12 Berlin (de) Oslo/Norway (en) Mdling/Austria (de) Berlin (de) Stockholm/Sweden Berlin (de) Oslo/Norway (en) Helsinki/Finland (en) Berlin (de)
*subject to modications
3 days
iStockphoto.com/numbeos
Website: http://training.diazhilterscheid.com
www.agilerecord.com
23
Management And Leadership In Software Organisations

by Plamen Balkanski
If you are reading the first few lines of this article, the chances are you already know quite a bit about management and leadership. Before you continue reading, take a few moments to establish your thoughts on the subject. Some questions that might help: What do you think management is? What do you think leadership is? How different do you think they are in a software organization? Do We Need Management, Leadership Or Both? A quick internet search on the topics of management and leadership brings hundreds of articles that tell us how management and leadership are very different. Some of the sources then go on to specify that despite being different management and leadership go hand in hand. For instance Stephen R Covey in his book 7 Habits of highly effective people tells us that leadership is about what to do and management is about how to do it. In his book On Becoming a Leader, Warren Bennis suggests that managers administer while leaders innovate; managers control while leaders inspire; the manager is a copy, the leader is an original, etc. Other authors suggest that there is a linear progression between managers and leaders (Jim Collins Good to great). A more modern view is that we are asking the wrong question. Jrgen Appello in his book Management 3.0 explains that separating management from leadership is like comparing women to humans and proposes a different question; leadership vs. governance. Appello points out that to become a leader is not the highest purpose of managers, but their job is to decide how much and in what areas to lead and how much and in what areas to rule. I think that this is a much better explanation. I also think that leadership is about being able to acquire followers in a given context, and therefore anyone can be a leader in an area, technical or not. For instance, in a software development team you may find someone who usually takes the lead when it comes to databases and someone else who usually takes the lead in continuous integration tools. At the same time the manager of the team must take the lead in areas like motivational practices, removing blockers and authorization while letting the team lead
in the technical practices field. As Seth Godin writes People can follow different leaders for different causes. Is There Something Specific About Management And Leadership In The Software Organization? I have seen managers from a non-software development background do no worse in software organizations than their predecessors. And I am sure most of you have seen that too. If anything they are likely to bring a practice or two from their background which is not well known in the software organization and might turn out to be very useful. All organizations are networks and all the work is done in a social network of peers; leaders and followers (Appello 2010). The idea that a software project team is (and operates in) a complex adaptive system became popular through many books and articles on agile software development which have borrowed it from complexity theory. If theres anything specific, then thats what it is. We operate in a complex adaptive system and all agents in the system are knowledge workers. But that is also true for most teams and projects that involve knowledge work. Some people might agree, but also think there are more specifics in software organizations. Of course there are. There are also specifics in finance organizations, law organizations, etc., but they do not change much of what management and leadership in its core should be. It is no secret that most business organizations are well behind science in terms of implementing the latest findings about how organizations work. As Daniel Pink says it in his book Drive there is a mismatch between what science knows and what business does. So I think the question really should be: How big is the mismatch in the area we are discussing (e.g., software organizations)? The bigger it is, the more managers should do to reduce the gap. And I think as far as software organizations are concerned we are quite fortunate. The rise of agile software
24
www.agilerecord.com
Knowledge Transfer The Trainer Excellence Guild
Integrating Agile with a Structured Project Culture by Paul Gerrard & Susan Windsor
Is Agile proving hard to implement in your organisation? Have you been successful with agile development but still having difculty scaling to larger projects? Is your organisation unable to release product owners to your agile teams when you need them? Do your suppliers or customers have a different interpretation of agile to you? Do you need to resource a mixed portfolio of development approaches from a single resource pool? Are you lean enough? This course will show you how to meet these challenges. Using business stories and examples to build better software is an approach that is currently being adopted by forward thinking organisations and individuals. You can use business stories to bridge the communication gaps between a structured organisation and an agile development approach.
Date June 2122, 2012
Place Berlin
Price 1,250 + VAT
Testing Mobile Applications by Jonathan Kohl

Smartphones and tablets are here to stay. Test teams are facing pressure to deliver testing quickly and successfully on mobile devices. When faced with a mobile testing project, many testers nd it tempting to apply the same methods and techniques used for desktop applications. Although some of these concepts transfer directly, testing mobile applications presents its own special challenges, which unaddressed means you miss critical bugs. Learn how to get quick wins by exploiting known weak spots in mobile applications, and how to add more structure and organization to generate effective tests and projects. Hear rst-hand experiences with testing mobile applications and discuss how to address various challenges. Explore successful approaches to managing and organizing mobile application testing projects. From testing on small screens, different input devices and limited testing tools, to handling lower processing power, multitasking and communication issues, this course prepares you to start your mobile testing project with condence. This three-day course covers four main areas risk management, techniques for performing effective and efcient functional testing, approaches to testing the technical non-functional characteristics and attributes of software systems and examination of tools and basic automation concepts. Discover the key differences between mobile and other software applications Learn the basics of how mobile application technology works Practice techniques for nding bugs quickly on real mobile devices Explore adding structure to mobile testing so you can create a repeatable process Uncover approaches specic to managing mobile testing projects This is a 2 day, hands-on, interactive workshop. Participants will need to bring a smartphone or tablet to use for the exercises.
Date August 3031, 2012
Place Dsseldorf
Price 1,250 + VAT
TDD .NET by Lior Friedman

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. Objectives: Writing basic unit tests using MsTest/NUnit Learning principles of Test Driven Development Experience Best Practices of unit testing Understanding the difference between unit tests and acceptance tests. Learn how to test complex object hierarchies Understand the difference between Interaction Testing and state based testing. Understand the principles of Isolation using modern isolation frameworks. Learn advanced Mocking techniques Learn how to leverage frameworks to ease authoring of tests Real Life examples.
Date Sept 1012, 2012
Place Berlin
Price 1,450 + VAT
Website: http://www.diazhilterscheid.de/en/knowledge_transfer.php
development and open source brings many useful and scientifically proven practices and behaviors. This is the good news about organizations striving to implement agile practices it is already a move in the right direction because agile practices aim to close the gap between what science knows and what business does, and the open-source movement contributes by creating knowledge at a speed unimaginable for the pre-Internet era. While agile software development is good news, it isnt enough because it does not cover all aspects of a complex adaptive system. And why should it? It didnt start with the idea to address all of it. It started as a collection of key behaviors in software development identified by practitioners and promoted through many methods and approaches. And for ten years it has done a great job with changing the world of software development. Now we need to address the rest, and to do that I think we need agile management. Quick check-up: Has your view on management and leadership in the software organization changed after reading the first half of this article? Addressing Complexity When it comes to bringing agility and complexity together, there is a great book that I would recommend to anyone interested in both. I have already mentioned it earlier Management 3.0 by Jrgen Appello. I think it is great because it provides a model for management that takes into account the most important scientific discoveries in the field of software development, organizations, social networks, and complex adaptive systems. The book also helps us to address the deficiencies we see due to business organizations choosing to ignore science. Based on what we know today, I would choose the Management 3.0 model to describe what management and leadership is in a software organization. There are six views defined in the Management 3.0 model, and each of them represents different aspects of agile management. We will now briefly look at each of the views. Energize people This view is similar to the first principle of the Agile Manifesto and suggests a focus on people. However, energize people also discusses creativity because software development happens to be a creative, more right-brain activity rather than a logical and algorithmic, left-brain activity. It is also about how motivation works best for creative workers and the aspects of diversity and personality. Empower teams The empower teams view is about self-organization which is the default behavior of many kinds of systems including software development teams. Therefore empowerment is essential and not a bonus. This view also looks at the different levels of empowerment based on teams or the individuals maturity level, and at the levels of authority at which empowerment can be given. Finally motivation, trust, respect and feedback are also closely related to the second view of the model.
Align constraints Self-organizing teams can create their own rules and all they need is a set of constraints. As Nobel Prize winner (1977) Prigogine discovered a complex system can self-organize only when theres a boundary around it. Therefore the managers job is to align constraints and not create the rules, to manage the system and not the people in it. The align constraints view also discusses topics like shared goals, vision vs. mission and autonomous goals, protecting people and shared resources. Develop Competence The Agile Manifesto and many books on Agile talk about how good Agile teams are made of talented individuals. So what should a manager do if her team isnt that great? This view is about what the Agile manifesto did not explicitly mention skill and discipline. The view provides us with the tools and approaches for helping individuals to develop competence in how to influence learning in the organisation. Grow Structure Perhaps the biggest obstacle to growing an organisation in size is the issue of increasingly insufficient communication and feedback. Therefore the Grow Structure view is used in the Management 3.0 model to provide some insight into how best to addresses the problem. The main idea is that because of all the changes in the environment, the organisation, the people, the technology and the ideas it is important for the organisation to maintain ability to change and perhaps to even change regularly and so the structures should support this idea. Achieving the ability to change involves using concepts like generalising specialists, non-specific job title, informal leadership all of which contribute to improved organisational adaptability. Improve Everything This final view of the model looks at three approaches to continuous improvement adaptation, anticipation and exploration and concludes that we need all of them in never ending cycles. Using traditional models for continuous improvement is of little help as most of them are linear and software project teams are nonlinear complex systems. Therefore understanding that such systems go through a combination of gradual and radical changes in no specific order is important in order to be able to navigate the system to success. Improve everything is also about strategies like experimenting with individual practices, mixing collection of best practices and learning from others but no matter what strategy or mix of strategies you go for, the key is understanding that improvement is continuous and never ending. Quick check-up: How many of the views of the Management 3.0 model can you remember? SUMMARY Leadership is about acquiring followers, management is about aligning constraints, supporting individuals and teams, maintaining communication and feedback and ensuring continuous improvement never ends. Both activities can be performed by one or more individuals. Managers have to decide in what areas and how
26
www.agilerecord.com
much to lead and in what areas and how much to rule. In Software Organisation where most of the workforce are knowledge workers a different approach to traditional management is required, one that is more suitable to creative work. There is a mismatch between what science knows and what business does. One of the responsibilities of managers in the organisation is to help close the gap. In software organisation adopting Agile development practices is one way to speed up this process. But most of the popular management approaches today arent taking into account complexity theory and software project teams are and live in complex adaptive systems. This is why the Management 3.0 model is very useful to managers in an Agile environment. The model consists of six views and each of them addresses different aspect of Agile management. Together these views represent an invaluable guide not only to new managers in the software organisation but also to experienced managers transitioning to Agile.
> About the author

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.
CAT TSG Ad final:Layout 1
20/4/12
16:19
Page 1
The Cered Agile Tester course introduces experienced testers and managers to the pracces they will need and use to be eecve on an agile project. A very interacve and praccal course, you will learn about: Agile methods and processes Agile requirements and specicaons Agile tesng and iteraons Agile teams, funcons and pracces Gain the skills and recognion of your professionals as a Cered Agile Tester.
For more informa on visit TSG and BCS at Tes ng & Finance Europe Conference 2012. 16-17 May in London, UK www.bcs.org www.tes ng-solu ons.com
www.agilerecord.com 27
Virtual Teams and Conflicting Leadership Styles Case Study

by Raja Bavani
Virtual teams are nurtured in an ecosystem where leaders from all locations share a common vision and minimize conflicts rising because of differences in leadership styles. The adoption of agile practices in global software engineering teams is often challenged by conflicting leadership styles. Let me share with you in this article a case study adapted from my experience and discuss my findings and recommendations. Case study: It is my style of leadership! This is about a software development project that started couple of months ago with a team of 8 in Europe and a team of five in North America. Andy is the Product Owner in San Francisco, California. John, the offshore manager went onsite and worked with Andy and his team for about four weeks. As you observe, both Andy and John are managers by designation. They have gone through agile software development training programs and worked with agile teams over the past twelve months. The team in San Francisco is responsible for developing interfaces to external systems, whereas Johns team is responsible for developing the GUI based modules and corresponding features of the system. These two teams interact on need basis to resolve all common areas of concerns. John and his team in Europe are from a vendor organization that provides software services to several companies in the United States and Europe. At the offshore location, John has started playing the role of Scrum Master on this development project. After Sprint-1 and Sprint-2, he is busy focusing on Sprint-3. On the 3rd day of Sprint-3, John receives a mail from Andy. It reads Good. I went through your email. I am a little surprised. We have Hi John, This is about Sprint-2 delivery. We had an internal meeting today with Nick and Jim. They had several questions on why the team delivered less. I dont understand why we have failed to complete all user stories. Our inability to complete all of them has got a negative impression from the VP here. Let us discuss this today. Please call me in 30 minutes from now. This is urgent. Thanks, Andy .. John becomes restless. Thinks over it alone in a meeting room and eventually breaks his pencil. He is under pressure. He goes through the daily reports and dashboards of the previous Sprint. In fact, he participated in daily stand-up calls and provided timely updates. He has not hidden any information from Andy! Puzzled, John calls Andy over phone. Hi Andy, Good morning! How are you? Hi John, I am ok. How about you?
28
www.agilerecord.com
been sharing daily status with you along with our metrics. For example, we were aware of the velocity and burn down. John, let us discuss this. We know the status. I appreciate you and the team for sharing these with me on regular basis. The point here is that my boss Nick is the Director here and his boss is Jim. Jim is the VP. Nick and Jim are upset over the progress. Oh. Why is that? John, let me tell you something. I looked at the dip in our charts. Two of our team members in your team have consumed a lot more than the estimated efforts in completing their tasks. I am talking about a 50 to 100 % effort variance. This hurts. The result is we delivered only 12 out of 16 stories. That is we pay 100% and get only 75%. Thats where the management is concerned. I think we should replace these two engineers with those who can perform better. Andy, these two guys are my star performers. They consumed more time because of technical reasons. They had to solve some technical issues related to their tasks for the team to progress. Also, the team is new. They are just getting their feet wet. We are moving into Sprint-3. Over the next iteration we will be geared up to deliver. Our velocity will stabilize and improve by that time. Well. Let us be practical. My team members here strongly feel that we must get rid of those who need more effort to deliver. In our organization we believe in performance. Everything else comes next. Once we commit, no reason can stop us from not delivering. Above all, I need to provide an answer to Jim. I am listening to you. I need to think this through. Let me come back to you with a couple of options. Ok then, I will wait for an update from you tomorrow. Let us talk again. Take care. Bye. Thanks Andy! Take care. Bye. John hangs up the phone and thinks. I know, I have handpicked my team. I dont think I need to replace anyone. How can I make Andy understand this? I think more than Andy his boss needs to understand how agile teams work during the initial sprints. How can I solve this problem? How can I get some help here? Analysis: I am sure many of you have come across similar situations before. This is a case of two leaders with conflicting leadership styles. This situation can happen in collocated teams too. However, when it happens in geographically distributed teams it becomes very challenging because of inherent reasons such as participation of two or more teams from different organizations and countries, and location specific views and expectations on agile.
In this case study, Andy wants to pursue his agenda whereas John is diffident and does not want to push back and demonstrate that he is confident of his team. Andy wants to fulfill the decision of Nick and Jim whereas John does not know whom should he approach in his organization for help in this situation. What do you think John should do? How can we avoid such incidents in projects? During my interaction on this case with a group of software engineers, I came across very interesting views. However, a common theme among all of them was to consider a two-pronged approach by handling the current situation first and then preventing this from happening in future. Some of us may feel that there is a lack of common understanding between Andy and John. John did all he can to keep Andy informed about the progress in each Sprint. So, it is not about the lack of common understanding. It is about the lack of common vision and empathy coupled with conflicting leadership styles. When there is lack of common vision in geographically distributed teams, expectation management becomes extremely difficult. Has John been left alone? Yes. It appears that he has no one to go to for any support or help. He does not have someone up in his hierarchy or a mentor in his organization to help him. Above all, it appears that these two entities involved in this software development project have not thought about the importance of governance in distributed agile projects. I wrote an article titled Governance of Distributed Agile Projects: 5 Steps to Ensure Early Success for the 7th issue of Agile Record. From a governance perspective, there has to be a common understanding among governance team members that iterations do progress and that it is very idealistic to expect perfect results during the first two or three iterations. This will help them welcome or embrace iteration progression and avoid negative perceptions that lead to red alerts or escalations. This is because aiming for instantaneous results is nothing but an unrealistic expectation in distributed agile projects. Periodic steering committee reviews are essential to understand and improve the performance of distributed agile projects. During initial stages it is required to have these reviews every month, and as soon as the first few early successes happen, the frequency of these reviews can be once in two months or once in a quarter. Having said that, let us explore an option to deal with the situation in this case study. Andy is constrained to follow two leaders Nick and Jim. In addition to playing the role of Product Owner, he plays the role of Customer and instructs John to replace those two engineers. John appears to be a docile Scrum Master. If John replaces two engineers from his team, there will be a consequent dip in velocity. This move can impact team morale. So, a better option for John and Andy is to team up and present their confidence to Nick and Jim so that they do not resort to the replacement of two performing engineers. For this, John has to rise up to this situation
www.agilerecord.com
29
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
rs w
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
and voice his opinion with adequate data which he already has. If Nick and Jim do not agree to this, it is tough luck! Above all, they need to set up a governance team with the help of Nick and Jim so that such issues do not surface again. Conclusion Conflicting leadership styles can create insurmountable challenges in distributed projects. However, with adequate rapport and empathy, differences in leadership styles can yield positive results too. Organizations participating in distributed Agile need to understand this and invest time and money in setting up functional governance teams in order to avoid such situations and to provide adequate support for early success in projects.
> About the author

Raja Bavani is Chief Architect of MindTrees Product Engineering Services (PES) and IT Services (ITS) groups and plays the role of agile evangelist. 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. 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. He writes for magazines such as Agile Record, Cutter IT Journal and SD Times. His distributed agile blog posts, articles and white papers are available at http://www.mindtree.com/blogs/category/softwareproduct-engineering and http://mindtree.com/category/tags/agile. He can be reached at raja_bavani@mindtree.com.
Beyond Servant Leadership in Agile Projects

by Rathinakumar Balasubramanian
Leadership in Software Organizations: Leadership has long been an interesting and intriguingtopic for researchers and practitioners. Leadership is not about power, it is about empowering people. Leadership is Influence. [1] In a software organization the leadership equation is quite complex due to the fact that the raw materialis people and their intellect. Leading and influencing them have never been so difficult. In an agile software development environment, the teams are selforganizing. Agile teams do not work under a command and control regime. This raises a variety of questions. Who is the leader in an agile team? How does leadership work in an agile environment? How do we ensure that self-organizing teams do not lead to chaos? Is servant leadership the solution? We will explore to find answers to these questions in this article. Four Levels of Leadership: Projects get executed in an organization by its people. Hence the environmental factors of the organization influence the success of
the projects in a huge way. Agile project leadership is key parameter in ensuring the project success within constraints and boundaries of the organization. There are many leadership models discussed in popular leadershipliterature from Jim Collins to John C. Maxwell.[4] Most of the models talk about leadership at organizational level. In this article, I describe a simple four-level leadership model that works well for agile project environments. The agile project leadership has narrow canvass which is ensuring successful agile projects, successful agile adoptions. Fig. 1 shows the four levels of leadership. Level 1: Positional Leadership Level 1 is positional leadership. Here the leader gets things done through authority. Command and control is the key characteristic of this level. By default, an agile team is not expected to be led by positional leadership. Agile teams are self-organizing and selfdriven. Positional leadership will be disastrous in an agile team. Illustrative Scenario: Shan was managing a software product development in a traditional plan-driven approach. He was the project manager and the team members reported to him. The customer asked them to adopt Scrum to develop the product in order to shorten the time-tomarket. Shan quickly aligned the project team to the scrum roles. He took over the role of scrum master. The team still reported to him. This did not help the team to self-organize as they expected his approval and direction every time. The velocity of the team did not improve over time leaving the customer dissatisfied. The key lesson here is positional leadership does not go well with agile teams. An agile team that is agile only in structure cannot bring in the benefit of self-organization. Positional leadership can be disastrous in an agile team.
4. Transformative Leadership
3. Servant Leadership PRODUCT OWNER
AGILE COACH
2. Collaborative Leadership
1.Positional Leadership
Fig. 1 Four-level leadership model
THE TEAM
Fig. 1 Four-level leadership model
www.agilerecord.com
33
Level 2: Collaborative Leadership Level 2 is collaborative leadership. Here the leader gets things done through collaboration. Relationship is the key characteristic of this level. A collaborative leader builds a strong relationship with the people. Leaders at this level care for their people. They support their people and motivate them constantly. The true collaborative nature of leadership stitches the bond between the leader and the team. Many agile teams experience collaborative leadership. An agile coach builds a strong relationship among the scrum team through his coaching and facilitation skills. Illustrative Scenario: Sanjay is an agile coach for an agile team building an online reservation system. Sanjay is a strong people leader. He connects with everyone in the team pretty well and has built a good rapport with the product manager who is his customer. He is very effective in solving people conflicts through his relationship built with them. Many in the team like him, though some think he is building a fan club. The team is largely self-organizing; yet they often resort to Sanjays consensus-building skills. Sanjay increasingly found that his bandwidth to improve his skills has reduced a lot. The key lesson here is that building relationships is effort-intensive. It takes time and it may be difficult to build the same level of relationship with all the members of the team. Level 3: Servant Leadership Level 3 is servant leadership. Here the leader serves first to lead consequently. Serving is the key idea in this level. The term Servant Leadership was coined by Robert K. Greenleaf in The Servant as Leader, an essay that he first published in 1970. In his essay, he said The servant-leader is servant first... It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead.[2] The idea of servant leadership can be traced to the 4th century B.C. Chanakya in his book Arthashastra wrote that a king [leader] is a paid servant and enjoys the resources of the state together with the people. [3] A servant leader serves the team unequivocally. Leaders at this level gain the respect through serving the team. They listen to the team; they take cues from observing the team and empower them in decision-making. Serving is a leadership attitude and a mindset. Agile coaches are expected to have this attitude. Illustrative Scenario: Amy was the agile coach for a team that was working on upgrading a telecom application. For Amy, her teams need always came first. She was always there to serve and support the needs of the team. Her attitude clearly reflected in the way she removed the impediments faced by the team. When the team faced a delay in building a component, she negotiated with the third-party vendor and was able to get them to build it. Her team believed that she is a true leader without whom they could not have achieved ontime delivery.
The lesson here is that Amys leadership is the consequence of her mindset to serve the team. It is a reflection of her attitude to serve which made her a leader. Level 4: Transformative Leadership Level 4 leadership is transformative in nature. Here the leader transforms others as leaders. The key characteristic of this level is transformation. Transformative leaders lead by example; work through organizational constraints well; they glide over organizational politics; they stretch the organizational boundaries and lead the team to newer areas. Transformative leaders develop others to reach levels 3 and 4. They have big picture in mind and think global always. Illustrative Scenario: Jim has recently taken up the responsibility of transitioning a couple of his customers projects from a traditional methodology to agile. He knew that he has to quickly build people who adapt to the agile mindset. Most of the senior designers and developers in his company never had any experience with agile. He started training them in agile way of working. He built self-organizing teams. He played the role of scrum master in one of the projects and helped other scrum masters. The senior management expected to receive detailed status reports. He challenged the management on the need for a detailed report and eventually convinced them to accept a much simpler status report that fulfilled their requirements. The lesson to be learnt here is that Jim could build other people and could also go beyond the organizational constraints through this transformative leadership. This shows that software organizations do have responsibility to develop leaders. It is easy for the organization to adopt a leadership model that helps them to identify the level at which the identified leaders operate. The organization can then plan and support them in moving up the leadership ladder through regular leadership education, training and opportunity to apply the leadership lessons. It is imperative that agile organizations make this effort consciously so that agile projects can deliver to their fullest potential. References: 1. http://www.johnmaxwell.com/about/ 2. 3. 4. http://www.greenleaf.org/whatissl/ http://en.wikipedia.org/wiki/Servant_leadership#cite_ note-0 http://www.johnmaxwell.com/development-training/ development-programs/organizational-development/the5-levels-of-leadership/
34
www.agilerecord.com
> About the author

Rathinakumar Balasubramanian is a project management expert and works for Infosys Ltd. He has over 15 years of experience in successfully leading software projects both in traditional and agile ways. He has published several papers at international project management conferences. His areas of interest are agile project management, leadership, learning and development. He is a Project Management Professional (PMP) and a Certified Scrum Master (CSM). He can be reached at brathina@ gmail.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* 11.12.10.12 Berlin
2 Tage
*nderungen vorbehalten
www.agilerecord.com
35
Leading Software Teams, The Agile Context

by Nishant Pandey
Effective leaders and managers of teams are able to extend social influence for aiding teams and individuals attain shared goals and improve performance. Leaders of todays software teams have to embrace the dynamics of a changed work place, which is evolving at a fast pace. This article focuses on sharing insights on important aspects of leadership, with an inclination# towards software teams that are cross-functional, geographically dispersed, multi-cultural and use agile software development methodologies. In the past, the software development process was often compared to manufacturing and observed similarities between software development and manufacturing, which led to the adoption of processes from the manufacturing sector to the IT. With increased focus on eliminating waste and reducing the turnaround time for software development, agile concepts and iterative development methods have gained popularity over the last couple of years. Agile methods use evolutionary, incremental, and iterative delivery to provide an optimal solution to the user.
The composition and organization of teams has also changed, and teams are now increasingly cross-functional. There is increased awareness in the software industry that efficient leadership of software teams, with specific attention to the concept of agility, plays a crucial role in achieving project success. Understanding todays software teams With increased focus on agility, offshore development and globalization of work, the composition of todays software teams is different from what it was in the past. Instead of being a work group aimed at sharing information and taking decisions in silos, the new software team aims at generating positive synergies through coordinating efforts in moving towards a shared goal. There is increased focus on collective performance as business analysts, software developers, testers and project managers work towards complementing the skills of each other, thereby reducing the time to market and increasing the teams ability to respond to changes.
Figure 1: Changing composition of todays software team
36
www.agilerecord.com
Leveraging strengths of software teams A good leader can use the new teams structure to gain competitive advantage. This new structure also provides opportunities to motivate employees by enhancing their opportunities for learning and self- development. Leaders and managers can use the crossfunctional nature of software teams to encourage job rotations, cross-training and reduce person dependency (thereby reducing risk), while motivating the team members at the same time. It is important that managers work towards increasing the software teams effectiveness and efficiency. Maintaining specificity of common and individual goals that are specific, measurable, realistic and time-bound, has been observed to be a key differentiator for successful teams. Diversity also plays an important role and can be used for strategic advantage, if utilized and managed effectively by the leadership. Diversity can prove to be a catalyst to software development teams by providing fresh perspectives and alternative solutions. It is important for todays leaders to ensure an open and collaborative atmosphere in the workplace. Software professionals thrive when they can exchange ideas, discuss and debate on approaches without inhibitions. Leaders of successful software teams often act as coaches, advising, guiding, and training teams to help them pursue the shared goals of continued improvement over the years. Three important catalysts Motivation, trust and communication are three very important ingredients that act as catalysts for effective leadership of software organizations. Effective leaders are able to motivate their teams to build excellent software, within the constraints of time and budget, and they empower the team with the zeal to better itself continuously. Trust is an important aspect of leadership. Trust in team members and leaders enables software professionals to maintain a positive outlook towards working towards the working environment. When the team members trust their managers, they are able to confidently take risks, share opinions and work collaboratively, assured that they will not be taken advantage of.
Good communication is an important factor for a leader. Well directed and effective communication is increasingly important due to the new team composition and need for agility. Leaders need to be aware of cultural differences and take into account this factor while communicating with todays multicultural and geographically dispersed teams. This factor might be of very high importance, specifically in case of offshore teams. Motivating software professionals The concept of participative management can be beneficial for managing software professionals. Sharing decision-making responsibility with software professionals on your team can impact the teams motivation. The following diagram illustrates possibly useful techniques to motivate software teams and could be implemented in methods depending upon the organizations culture and other contextual factors.
Figure 3: Motivation Checklist for Software Leaders
Personal attention, expressing interest, approval and appreciation for a job well done, are known factors that motivate individuals and teams. Leadership & the role of trust in an agile environment In the earlier software development methodologies, there was a lot of emphasis on documenting requirements early in the process, and it was the work of the software teams to tightly couple the development activity with these requirements. With the impetus shifting towards reducing time to market, software development activity often starts without having the full range of requirements available. Teams work through whatever knowledge is available, integrating new information in their work as and when it is available. This shift towards employing just the essential and just-in-time processes and documentation is based on the basic assumption of collaboration and trust between various team members and stakeholders. It is important for leaders of software teams to cultivate this trust in the team. The role of trust in leadership has been amplified with the increased importance of agile methods.
Figure 2: Catalysts for effective leadership Motivation, Trust & Communication
www.agilerecord.com
37
Key parameters that underlie the concept of trust include competence, consistency, loyalty, and integrity. These underlying parameters often limit or boost a leaders ability to gain useful knowledge, support and commitment from the team to be able to solve real-world problems. The effectiveness of a leaders ability relies heavily on the ease with which he is able to acquire the trust of the software team. Additionally, trusted leaders are able to become good conflict managers as the issues, perspectives and options are more openly shared by the team with them. Communication is the key Good interpersonal and organizational communication is very important from the perspectives of control, direction and motivation of teams. It is important that leaders inculcate good practices relating to this very important attribute in their teams DNA. Open and caring communication goes a long way in building trust, an important factor for leaders and motivators. Oral, verbal and non-verbal aspects of communication are equally important in a cross-functional software team setting. Managers should be careful to identify and try to resolve any barriers to effective communication that might exist in their teams. Cross-cultural factors are also important in todays globalized work setting and diverse workforce. If due attention is not paid to the cultural aspect, there is a potential for increased communication problems within the team or between some individuals. Effective leaders communicate well; they establish a culture of communication in their teams that is open and sensitive to the cultural differences and diversity of their teams. Retaining the creative edge Software development is a process that benefits from utilizing an employees creativity to the maximum. One of the most important tests for a leader of software teams is whether he (or she) is able to retain and sharpen the creative edge of the software teams. Software professionals are creative individuals who take pride in the software systems they create and the problems they solve. A good leader of a software team is able to appeal to the intrinsic motivation of the team members, creating an environment and 38 www.agilerecord.com
culture that helps in motivating them by interest, satisfaction and challenge of the work itself. Challenging the team from time to time, providing them with the freedom to innovate and sharing responsibility of decision-making can go a long way in sharpening your teams creative edge and increasing its capability to deliver exceptional results. References Robbins, P. Stephen, Organizational Behavior, Tenth Edition (2003), Pearson Education Inc. Owen, Jo, How to Manage, 3rd Edition (2011), Prentice Hall Amabile, Teresa M., How to kill creativity (2005), Harvard Business Review on Managing Projects
> About the author

Nishant Pandey works with Capgemini and is based in Toronto, Canada. He manages Business Analysis and Testing engagements for clients in the Financial Services domain. Nishant is a certified PMP and holds the Advanced Level Certificate in Test Management from ISTQB. Nishants articles on software testing and test management have been published in Testing Experience and Quality Matters magazines. Recently, Nishant has authored a chapter in the book The IFPUG Guide to IT and Software Measurement on Benchmarking. In his spare time, Nishant likes to make short films and write songs.
Figure 4: Dimensions influencing the concept of trust
How to navigate through Scrum a guide for Scrum Masters

by Katja Roth & Jane Trmner
In theory the Scrum Master role is clearly defined and seems to be easy to handle. It is about keeping the Scrum process running and removing impediments so that the Scrum team can focus on building and delivering business value. In addition, the Scrum Master is a change agent helping the organization to transform successfully from traditional project management to agile product development. This should not be too challenging as the Scrum framework is very simple and easy to understand. In reality, however, Scrum Masters have to overcome lots of obstacles and challenges. With this article, we aim to provide you with a navigation guide through the daily jungle of a Scrum Master. Come with Alex, a former test engineer, and join a typical day as a Scrum Master at a fictitious CoffeeCake.com. This social net company introduced Scrum recently to reduce time to market for new features and to increase flexibility concerning fast-changing requirements. In preparation for the new role Alex attended a two-day Scrum training and was very proud of her Scrum Master certificate. Shortly after she took over her first Scrum team and experienced the agile reality. Let us see how she makes her way through common obstacles and challenges. How to steer the daily work Imagine her first Daily Scrum. Alex remembered what she had learned in her training: the Daily Scrum is time-boxed to 15 minutes and everybody has to answer three questions: what have I done yesterday, what will I do today and what is blocking me from doing my work. Now, let us see, what happened in Alexs meeting. The first two team members answered the questions as expected, but nobody talked about impediments. Alex was getting nervous. There seems to be nothing to do for her. The third developer, a senior, started talking, but instead of focusing on the three questions, he spoke about architectural aspects of his tasks and a technical discussion started. Alex, just having quality assurance background, was not able to follow the discussion thoroughly and she feared that the time-box would not be kept. When
to step in? Did her Scrum trainer mention anything about the correct behavior in such a situation? She could not remember that and decided to stop the discussion immediately, but the developer ignored her. He said that everybody should be interested in what he had to say. Now Alex raised all her authority and stopped the discussion by proposing that all interested in the architecture topic could continue the technical talk after the daily meeting. Surprisingly for Alex that really worked. Now, there were three more developers left, another 5 to 10 minutes to go, Alex thought. Then Steve, the CTO, showed up. He had an urgent task to be done by the senior developer. Alex showed all her courage and suggested discussing it after the daily meeting and the CTO agreed. On one hand such a task does not belong to the sprint and is a risk for the sprint goal, and on the other hand the daily meeting is for the team organization, not for new requests. After the daily scrum, Alex decided to discuss her daily scrum experiences with Chris, an experienced Scrum Coach at CoffeeCake. com. She told her that she did a real good job as she did everything to keep the meeting focused and tried to make it within the 15 minute time-box. She recommended Alex to talk to the senior developer about his monolog and why she interrupted it. Maybe he has not yet understood the purpose of the meeting. But there was something else that Alex was insecure about. Except for the architecture discussion she had the feeling that the team reported the status to her instead of talking to each other. In the training she learned that the daily scrum is like a tactical meeting to plan the current work day. Alex had no idea how to change the teams mind and asked Chris for advice. The coach recommended discussing Scrum meetings and their purpose in the next retrospective.
www.agilerecord.com
39
Do you really need to prepare retrospectives? After lunch Alex blocked some time to prepare the retrospective for the next day. The aim of a retrospective is learning from the past as a team and coming up with improvements for the team work in short inspect and adapt. Preparing such a discussion means thinking about the team challenges and problems, finding the right method enabling the team to devise ideas. Furthermore she has to organize a room and arrange the equipment, e.g., drawing flipcharts. While doing those things Alex sometimes struggles with the messages from her colleagues. From their point of view she seems not to be very productive, just sitting around, thinking and drawing. She complained about this to a fellow Scrum Master at the local Scrum Table, having experienced the same. What could you do to convince others of the usefulness of your work? You have to explain to team, colleagues and management that the focus of a Scrum Master is the team development and the continuous improvement of its performance and thus the set-up for success. This is done at an operational level each day and during a retrospective at the end of each sprint. A retrospective is a dedicated time for learning and process improvement. As moderator the Scrum Master leads the team to findings about their work and ideas, e.g., how to get stories done in good quality, working better together as a team, and being happier at work. Once conducting a retrospective without preparation, Alex learned the hard way that preparing a retrospective is essential for its success. Inspect and adapt applies to the work of a Scrum Master, too. How to hold a retrospective and get results During the last retrospectives Alex had the impression that the team lacked some energy and so she looked up data gathering methods in blogs. In order to fuel the discussion this time, she used four quadrants: keep this, stop this, ideas, and thank you. First the team was surprised by this change, but then the team members were filling sticky notes after sticky notes and Alex was glad. The team members presented their ideas and it was hard to steer the communication as the team came up with good thoughts and everybody wanted to contribute. After clustering and prioritizing the notes, it was obvious that there were two major topics to work on further: 1. The quality engineer was withdrawn by the management and had to work partly on another project, 2. The team was back to working on all stories simultaneously. Starting with the first point, Alex analyzed with the team what had happened and what it meant for team commitment. They found out that recently the quality engineer was withdrawn from the sprints more often and nobody in the team knew about it. There were two issues behind this. First of all the quality engineer in another team had been ill for a while and the teams test engineer easily says yes to management requests. To avoid this in future, the Scrum
Master had to find a solution with the management. Alex would explain to the management (again) why it is vital to keep a team constant, especially during a sprint. After a really long discussion among the team members, the test engineer understood that he is part of the team and commits as well. And thats why he is much needed to achieve the sprint goal. He agreed to not saying yes before talking to the team and the Scrum Master. These seemed to be the best steps to tackle the impediment. Next some team members were bothered by having all stories in progress. Failing the sprint showed that working on all stories simultaneously led to not finishing any story at all. How could that happen although everybody is an expert and was working hard? In a first step, Alex helped the team to describe the situation and explain how it influenced their work. For example, the developer working on the first story is a real expert, but as he fell ill after working for two days on it alone, the team didnt know what he had done and how to finish the story. So the story wasnt done. The second story was more complex than expected in the sprint planning, and after being halfway through the story the two team members developing it had to change their approach completely. This plus the missing test engineer meant it took the team triple the time expected. In a next step, Alex reminded the team of the basics of agile development and asked them what could have helped in those situations. Suddenly it was clear that focus, one of the agile values, is very crucial to finish a sprint successfully. Furthermore the duty of a team is to deliver business value every sprint. That can only be achieved by doing one story after another because the first one should be the one with the highest business value for the customer. Alex, happy about getting to this point straight, was really frustrated when suddenly one of the developers didnt agree. For him being an expert means being really fast and others would slow him down. That was a tough moment for Alex. She had to agree that for a while it seemed to be true, but in the long run close collaboration would result in higher quality, less bottlenecks, better results and fun at work. The team is in charge of achieving the commitment and not the single contributor. As it is always better to let the team come up with the arguments, Alex asked the team why focus was so important. Not all but most arguments where brought up by the team. Thats great, and now? So Alex asked the team what they would do different in the next sprint. The team agreed on working together at one story at a time, working in pairs where possible, and deciding as a team when to start the next story during the daily standup. At the end of the retrospective everybody seemed to be tired but content with the results of the retrospective. Why to follow up retrospectives? Retrospectives are a very good tool for helping teams to improve. It is crucial, however, not to forget the follow-up but to build it into the normal routines. As a first action, Alex ensured that the the results of the retrospective are put up on the wall in the team area as a gentle reminder. That way there is a better chance that some team members remind the others in the team of the issues. For herself she puts on her impediment list to talk to the manager
40
www.agilerecord.com
regarding the test engineer, to watch the team during the daily standup and remind them of focusing on one story. Furthermore she wants to come up with some ideas how to encourage pairworking. That was a good topic for her Scrum Master meeting. Solution finding with management As discussed in the retrospective Alex had to talk to the quality assurance manager about the withdrawn test engineer. Alex was convinced that assigning people to more than one team is problematic, although it is common at CoffeeCake.com that specialists support several teams. However, if Robert, one of just a handful of experts for automatic web testing, had to work in two Scrum teams, he would have to attend all Scrum meetings of both teams. Otherwise the integration into the teams daily work would be difficult. It is a lot of waste to spend so much time in meetings. Another problem of being a member of two teams is that Robert might have to switch his working context several times a day. Last but not least, the other team is located on another floor in the CoffeeCake.com building, so Robert would have to move around, which is again a waste of time. At the meeting with Alex and Robert, Sue, the quality assurance manager, pointed out that Robert should not work on tasks on the taskboard. He would just jump in whenever his expert knowledge is needed. Hence there would be no need to attend all Scrum meetings. She did not agree in the cross-functional team approach, where all experts needed for a project should be full-time team members. She wondered how many web test specialists she should hire to support such a demand. Alex explained that a constant team setup is the basis for sustainable pace. With a part-time team member there is no real planning reliability and no flexibility in arranging the daily work for the team anymore, as nobody knows if this person is available when needed. This would be a risk to the team commitment. Alex was thinking about an offer to Sue in order to keep Robert as full-time team member because she felt that Sue was not convinced. She suggested assigning Robert to her team only. Additionally Robert should spend at least one day per sprint to share his automatic web testing knowledge with other colleagues in the company to build up know-how in other teams. After a while, Sue agreed, but she insisted on a review of their decision in two weeks. Why talking helps After upgrading Linux to a higher version, Mike, a Java developer in Alexs team, could not start his development environment anymore. None of the other team members was able to help, and even an email to the developer community did not lead to a solution. The last resort would be to ask the IT support department to fix the
problem. However, after some negative experiences the developers did not like to ask the IT support guys for help anymore. Too often they felt ignored or even blamed when sending an email with questions to the IT support department. Hence, Mike asked Alex for support. His idea was that Alex could arrange some IT support for him. So he would not be blamed or ignored and maybe get his problem fixed anyway. Alex did not understand why Mike wanted her to solve the problem. She knew the IT support team members as friendly and helpful. Again, Alex asked the coach Chris for some ideas how to handle this impediment from a coaching point of view. Chris agreed that this problem, which is about changing peoples attitude, is not an easy one. So they had a long discussion about how to stop blaming and ways to build up an environment where both departments could work collaboratively on a basis of respect and trust. A first step in this direction is to stop their usual asynchronous communication via emails, as this has repeatedly led to misunderstandings and bad feelings. They decided that Alex should try to check with some of the IT support guys if they are willing to talk with the developers directly instead of having time consuming mail threads. Two hours later Alex showed up in the kitchen, where the IT support department is located. Shortly after Neill and Bo entered the kitchen, Alex inconspicuously started some kind of a small talk with them and also asked them how they feel about the collaboration with the development teams. Neill and Bo complained about missing information in tickets and emails containing questions they do not understand and hence are not able to answer. Alex wanted to know how they would react to a developer showing up in their team area from time to time, so they could talk about problems directly instead of losing time writing emails. Although Neill and Bo liked the idea, they do not want to be disturbed every five minutes. That is why they prefer getting in contact via chat before someone shows up in their area. After returning to her team, she went to Mikes desk to ask him to start a chat with Neill or Bo. Maybe they would have some time for him to give him some support. Although Mike was not convinced, he did what Alex asked him for. After some time Mikes development environment was up and running again. The problem was caused by a simple misconfiguration, Neill had figured out. Alex asked Mike for the lessons learnt from this problem. Mike replied that he could imagine getting in contact with Neill and Bo next time without Alexs support. Scrum Master the lonesome cowboy? The Scrum framework is easy and the routines are defined somehow. For a Scrum Master, however, every day is different depending of the problems the team is dealing with. Impediments range
www.agilerecord.com
41
from technical to human, from team-related to organizational, from short-team to long-term, simple to really difficult Being a Scrum Master is a multi-faceted role and no one will be able to know it all. So, what could Alex do to find solutions to all her teams impediments? There are three main ways: self-learning, community-learning and just trying out and doing. Self-learning is all about reading books, blogs, newsletters about agile and team development and trying out stuff with the team. That is the basis for your Scrum Master work. Community-learning is another cornerstone for your success. Very helpful are the knowledge exchange and problem-solving sessions with other Scrum Masters in a community of agile practice. e.g., just asking if someone has already had a certain problem or tried a certain method. The feedback about success and failure is great for learning and getting better. The third cornerstone is trying out, observing what happens and how the method works, and then adjust. As a Scrum Master you should often try to look at the challenges in your team from a meta-perspective. It helps to get a better overview of problems and yields a higher chance of finding solutions that may not be so obvious at first glance. Let inspect and adapt lead your way through the jungle.
> About the author

Katja Roth is agile coach with many years of experience in agile practices like Scrum and Kanban. As Certified Scrum Master and Certified Scrum Product Owner she helps companies to implement agile ways of working. Katja started her career 15 years ago as a software developer and has deep knowledge in agile development practices like XP and feature driven development. After a short period as a traditional project manager, she today focuses on transforming teams to high-performance teams. Coaching product owners in agile requirements management and especially in writing good user stories is another important aspect of her work. When Katja is not working for her customers, she writes articles and blogs at projekt-log.de to share her knowledge with other people. Jane Trmner has over 10 years experience in product development in telecommunications and Internet companies. She worked nationally and internationally as business analyst, product manager, product owner and scrum master. In her current position as team leader of the Scrum Masters at ImmobilienScout24 she manages the change process towards the agile enterprise with about 25 Scrum and Kanban teams. She focuses on fueling team development and communication flow, in order get the most of agile development. Jane Trmner has a degree in Business Administration and is Certified Scrum Master and Certified Scrum Product Owner.
42
www.agilerecord.com
JUNE 4th-7th
Madrid
The best International Conference
on SoftwareTesting
...under the sun!
40 International Speakers, 4 Tutorials, 4 Keynotes, 4 Tracks Webinars, 1000m2 Exhibition, Debates, Networking, Gala Dinner
Register with a special 20% discount AGREC20 at www.expoqa.com/en
A unique opportunity to share your experience with Test Experts from all around the world.
Sponsors Endorsed by
Radical ManagementSM A Paradigm Shift for the 21st Century

by Simon Roberts & Birgit Panzram
Introduction Why Do We Need a Paradigm Shift? As the number of organizations adopting agile methods increases, it is becoming increasingly apparent that agile is not just about changing the development approach. For sustainable success, management needs to change as well. There are several factors which separate the organizations that have sustainable success with agile from those where agile fizzles out after a year or so: In successful agile organizations, agile has support from all levels of management. By holding up a mirror to your organization, agile methods help you to see where there is room for optimization. For example, incentives are often in conflict or at least not completely aligned with product success (e.g. dependent on on-time, within budget delivery rather than maximum customer satisfaction). Removing such impediments requires support from management. Furthermore, much 21st century work is fundamentally different from the mass production that characterized the 20th century. Taylorism, exemplified by a hierarchical bureaucracy staffed by managers who command and control the work force, was perhaps appropriate in its time. In the 21st century knowledge workers use their creativity to build innovative solutions that are the engine of their organizations competitive advantage. This requires a different management paradigm. The recent Stoos Gathering started to consider these and other related topics and issued the following communiqu: Reflecting on leadership in organizations today, we find ourselves in a bit of a mess. We see reliance on linear, mechanistic thinking, companies focusing more on stock price than delighting customers, and knowledge workers whose voices are ignored by the bosses who direct them. All these factors are reflected in the current economic crisis, increased ineq-
uity, bankruptcies and widespread disillusionment. There has to be a better way. In January 2012, a diverse group of twenty-one people, including senior executives, business strategists, managers, academics, and lean/agile development practitioners from four continents, met in Stoos1, Switzerland. We believe that we uncovered some of the common characteristics of that better way. For example, that organizations can become learning networks of individuals creating value and that the role of leaders should include the stewardship of the living rather than the management of the machine. Most importantly, we committed to continue our work, both in-person and online. A problem this size will require many minds and hearts. Wed love to hear your voice and your experience. Help move the conversation forward by joining our LinkedIn Group2 and on twitter with hashtag #stoos. Lets start the transformation before its too late. Radical ManagementSM (described by Stephen Denning in his book The Leaders Guide to Radical Management (Denning, 2010)) provides one concrete interpretation of this vision (although it predates the Stoos movement). In this article, we describe Radical Management, and show how it provides a compelling approach for many organizations, not just for software development companies. What is Radical ManagementSM? Radical Management covers a set of principles or shifts. None of them is new, but when pursued in combination they enable a sustainable change towards an organization that is more produc1 http://www.scrum-breakfast.com/2012/01/invitation-to-cool-eventlater-known-as.html 2 http://linkd.in/stoosnetwork
44
www.agilerecord.com
tive, more innovative and more satisfying, both for the people inside the organization as well as for the organizations customers.
creativity and resulting innovation can be achieved. This also results in the activation of higher levels of energy and passion of workers and the emergence of flow as described by Mihaly Csikszentmihalyi (Csikszentmihalyi, 1990). Shift 3. Coordination: from hierarchical bureaucracy to dynamic linking Hierarchical bureaucracy is needed when scalability doing more of the same work more efficiently, without variance is the highest priority. Rules, plans and processes are the focus. Progress is measured and failure punished. In todays world knowledge workers morale is undermined by such approaches, which are highly demotivating and inhibit innovation. In addition, this old-fashioned way of working does not enable organizations to react quickly enough in a constantly changing environment with well-informed customers.
One company goal: delighting customers Coordination: from hierarchical bureaucracy to dynamic linking Role of managers: from controller to enabler
From a single economic value to values which enable
Communications: from command to cooperation and conversation
Shift 1. One company goal: delighting customers Customers are gaining more and more power. Organizations competing for their custom no longer define the market and its agenda. Customers have better access to information and communicate with each other all over the globe. In addition, customers dont necessarily know their needs. As a result, what is needed is not just to address customer needs and focus on them. It is much more: the whole organization needs to orient towards one common goal: delivering value to customers sooner. This was emphasized by Peter Drucker when he wrote as early as 1973 (Drucker, 1973): There is only one valid definition of business purpose: to create a customer. The shift involves going from delivering shareholder or stakeholder value to delivering customer value and comprises every individual of the organization. Just stating it in the organizations mission statement or defining it as a goal for CEOs isnt enough. This shift needs to be implemented at all operational levels. Shift 2. Managers: from controller to enabler Traditional management approaches aiming at consistently performing with high efficiency are no longer sufficient. It is not the bosses anymore who know best how work needs to be performed. In todays world it is knowledge workers and experts who need to understand and address customer needs and find new solutions for them. To be able to do this, they need to be empowered. Hence the role of managers needs to shift from controlling to enabling these teams of experts in their daily work. Enabling and empowering means managers need to facilitate collaboration and remove impediments that are hindering the work, so that high levels of productivity,
The work to delight customers should be performed by enabled, autonomous teams; a discipline called dynamic linking must be installed. Work is done in short cycles, goals are set by management based on what is known about customer needs, decisions on how to achieve those goals are made by those performing the work, and results are assessed through customer feedback. In the software industry this is achieved by implementing agile methods such as Scrum or Kanban. This resonates with Dee Hocks chaordic systems which he described as early as 1993 (Hock, 1995) for systems which are both chaotic and ordered: By Chaord, I mean any selforganizing, adaptive, non-linear, complex system, whether physical, biological, or social, the behavior of which exhibits characteristics of both order and chaos or, loosely translated to business terminology, cooperation and competition. Shift 4. From value to values There needs to be a shift from a focus on shareholder value to values that enable innovation, learning and sustainable growth. Focussing on shareholder value alone is no longer an appropriate means to achieving long-term organizational success. Accordingly, a shift away from bonus systems for employees and quarterly or yearly budget planning (for example as described by Bjarte Bogsnes in his book Implementing Beyond Budgeting. Unlocking the Performance Potential (Bogsnes, 2008)) has to take place. The focus should move towards values which enable flexibility in a competitive world through innovation, intrinsic motivation, reliable relationships with customers and installing a radiant culture of customer delight, incorporating transparency, continuous improvement and trust. Shift 5. Communication: from command to conversation Finally, communication needs to move from command to cooperation and conversation for joint problem solving and for the generation of new insights.
www.agilerecord.com
45
Insight, innovation, customer delight and enabled teams cannot be commanded. It has to be a joint effort between management and knowledge workers. Managers are no longer required to tell people what to do in a top-down way. Instead they should work transparently within the organization in an adult way and communicate in an open manner to best enable teams and delight customers. In practice, this means that managers at all levels should spend less time on preparing and consuming status reports and more time on talking to teams (e.g., at Sprint reviews), and simply being where the value generation takes place. Conclusion Radical ManagementSM integrates the ideas of many thinkers and proposes a way of shifting towards sustainably successful organizations that delight their customers. None of the principles and shifts can work when implemented on their own. They are interlocked and each one of them is equally important radical managementSM is more than just a set of new management tools. What can we expect if radical managementSM is introduced? In organizations that successfully make the transition to radical managementSM we can expect: Increased customer delight. By recommending products or services to others, delighted customers can effectively act as an unpaid marketing department. More motivated staff who are empowered to create products that they believe in, and are as a result more productive than a less motivated workforce. Most importantly we can expect more profit. One of the most successful approaches for generating customer delight is to deliver less, faster. So costs can actually come down. Delighted customers are prepared to pay a premium. Combining these two factors means that we can leverage customer delight to generate more profit.
Drucker, P. (1973), Management: Tasks, Responsibilities, Practices, New York: Harper & Row. Drucker, P. (1999), Management Challenges for 21st Century, New York: Harper Business. Hock, D. (1995), The Chaordic Organization: Out of Control and Into Order, World Business Academy Perspectives, 9 (1), pp. 5-18. Hock, D. (2005), One from Many: VISA and the Rise of Chaordic Organization, Berret-Koehler Publishers. The Stoos Network (2012), The Stoos Communiqu, [Online], available at: http://www.stoosnetwork.org, accessed April 1 2012.
> About the author

Birgit Panzram MBA is an agile and business coach, an experienced manager and has a background in software development. She is part of the ScrumCenter GmbH team based in Berlin. Her first contact with agile software development methods was back in 2001, when she introduced XP in the company she was working for at the time as head of development. Ever since then Birgit has been an enthusiastic supporter of agile methods. Birgit holds an MBA from the Open University Business School (UK) specializing in creativity, innovation and change, is a certified Business Coach as well as a Certified Scrum Professional. She can be contacted at birgit. panzram@scrumcenter.com. Simon Roberts MBA is founder and CEO of ScrumCenter GmbH, an agile coach and a Certified Scrum Trainer who specializes in helping organizations introduce and achieve sustainable success with agile methods. He is currently focussed on helping executives in large organizations achieve their goals through the use and support of agility. He was honored to take part as one of 21 participants in the recent Stoos Gathering on 21st century leadership and management. He can be contacted at simon. roberts@scrumcenter.com.
Crucially, we expect these positive results to be sustainable. This is in direct contrast to organizations that continue to focus on short-term goals such as maximizing shareholder value. References and Bibliography Bogsnes, B. (2008), Implementing Beyond Budgeting. Unlocking the Performance Potential, John Wiley & Sons. Csikszentmihalyi, M. (1990), Flow: The Psychology of Optimal Experience, New York: Harper Collins. Csikszentmihalyi, M. (2004), Good Business: Leadership, Flow, and the Making of Meaning, New York: Penguin Group. Denning, S. (2010), The Leaders Guide to Radical Management: Re-inventing the Workplace for the 21st Century, San Francisco: Jossey-Bass.
46
www.agilerecord.com
Leadership and not management in an Agile team

by Leanne Howard
Core to Agile is the Agile Manifesto. The first value is Individuals and interaction over process and tools. That is not to say that process and tools are to be ignored, but that they are less critical than the individuals that make up the team, how they interact within that team and with their stakeholders. For most individuals to interact effectively, they need to feel that they are being listened to, their opinion is valued and that once collectively agreed on, a course of action that all will contribute to achieve completion of the task. When I was thinking about this subject of leadership, not management, I thought that it would be good to get a definition of both, but when I started to do some investigation there are so many out there. Some of which I agree with and others not. So I thought that I would start with one common view and then share with you my view. From Wikipedia: Management is the act of getting people together to accomplish desired goals and objectives using available resources efficiently and effectively. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. From Wikipedia: Leadership has been described as the process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task. Reading these two definitions immediately leads me to believe that the one most aligned with the Agile Manifesto is leadership. To me it has the key words of enlist the aid, support of others and accomplishment of a common task, which in my view strongly voice the agile paradigm. An agile team is self-managed, that is to say that jointly they decide as a group how they are going to work. After the initial agreement with the Product Owner (Business Stakeholder) as to which user stories are going to be delivered for that particular
iteration or work in progress items (which of course is influenced by the team velocity and the team estimates they give for each story), it is up to team to decide who is going to take responsibility and accountability for each of the tasks and action, maybe even deciding to undertake some activities in pairs. After all, the team are the best judge of who has the right skills or competencies to complete the work. If someone wants to put up their hand to volunteer to tackle something that may be outside their comfort zone or current experience in order to learn, they know they have the full support of the team around them. There is leadership within the team certainly, but that leadership can move to anyone within the team, dependant on the activities that are progressing within any given time. It may be the person(s) who are having the most issues that directs the conversation and effort to work out a solution, or someone with the most knowledge in a particular area where the team is focussed at the moment. The important fact is that the team are all pulling together to drive to accomplish a common goal, a goal that the whole team understands and has committed to, which brings us back to the definition of leadership. It is crucial to consider the motivational drive of the team members. There are two types of motivation extrinsic (which arise from outside the individual) and intrinsic (from within). Intrinsic motivation is much stronger than extrinsic motivation. David McClelland identified three motivators that drive our behavior, regardless of our gender, age or culture: 1. 2. 3. Achievement Affiliation Power
Within an agile team you want the majority of motivational influence to come from achievement and affiliation rather than the behavior driven by power.
48
www.agilerecord.com
Achievers have a strong need to accomplish challenging goals and receive regular feedback on their progress and achievements; Affiliation types want to belong to the group and favor collaboration over competition, and Power orientated individuals want to control and influence others and like to win arguments. This goes against one of the other agile values of collaboration. It is important to know that you can fail and learn without finger pointing, that the team provides the safe environment in which new things can be tried. The retrospective allows the group to gain feedback that will still be fresh and relevant and then decide the course of action which will be best in their particular context. There is no controlling force from an external manager who may not know all of the facts. Empowering the team to make the decisions will result in a higher level of commitment to the end result. If you, as a leader, are not providing prompt feedback to your team mates in a constructive manner, youre depriving them of the opportunity to improve their performance and ultimately deliver. Everyone has different skill levels and competencies that they are good at. The best multi-functioning teams are a mixture of personalities. In such teams not only do the skill sets complement and enhance each other, but the personalities and soft skills build relationships. If, for example, you have a Test Analyst within a team that has had little opportunity to formulate a test strategy or test plan, or does not feel confident articulating test estimates to be fed into the overall team estimates, then this needs to be recognized within the team. Maybe a mentor or coach can sit with this Test Analyst the first few times and lead him/her. There needs to be an open forum for communication where team members feel they will be listened to and feel comfortable to put up their hand and enlist the aid of others. Having talked primarily about the definition of leadership, the contrast is management. This article generalizes about managers. I have worked with managers that I have considered good, even though they were not leaders in my view. There are very few good leaders, in the true sense, and this is what I believe we should be aspiring to become. Most of the positive aspects in a manager you find in a leader, but not the negative traits, such as too controlling or micro-management. Leaders, additionally, have other qualities that draw people to want to work with them. Back to the definition and to what I see too often in managers is something that can be destructive to a team and often make them less efficient and effective. The first example being using available resources, the team is not recognized as individuals with different capabilities, but as a resource similar to a test environment to be used to get the job done, rather than nurtured and challenged to give their best; almost like a master-slave relationship. Another example is the manager often has information that he does not pass onto the team, as he sees it as giving away his power, but how can the team understand and reach a common goal if they do not know what it is. Without shared information, collaboratively, an agile environment will not thrive!
Linked to this is the control aspect where the manager gives orders on what the team needs to do, sometimes on a daily basis, and who likes to be micro-managed? This style breaks down the trust within the team; they do not buy into the vision, and there is limited opportunity to put forward suggestions to improve as they are doing their job with incomplete information. Of course, a leader plans and organizes but does so with the support of the team. Often team members volunteer for a task before being asked. People in the team are seen as a positive contributor by a leader, with all that entails, as opposed to being moved around as the manager sees fit. How can an individual produce their best work if they are confined within certain parameters? When people dont have clear goals, they muddle through their day. They cant be as productive if they have no idea what theyre working for, or what their work means. They also cant prioritize their workload effectively, meaning that projects and tasks potentially get completed in the wrong order. I would much rather work for a leader who inspires me and others and wants to get the best out of the team. A collaborator, who shares the vision, providing leadership and an environment so that we are all marching shoulder to shoulder towards a common goal which we have bought into and are committed to achieve. Someone who is willing to ask for suggestions, as lets face it no one has all of the answers all of the time and is able to listen and acknowledge good suggestions, acting on them as appropriate. A genuine leader will want to avoid micro-management. Theyll openly detest it! However, going to the opposite extreme (with a totally hand-offs management style) isnt a good idea either you need to get the balance right. To characterize, a leader is a person that is respected by their team, their peers, the people that they report to and all those that they come into contact with. Truly someone to aspire to become. As a leader, you need to be a role model to those you collaborate and interact with. This means that if the team needs to stay late, you should also stay late to help them. Your attitude matters if youre always positive in the face of huge challenges at times, then the team are likely to reflect this. So remember, your team is watching you all the time. If you want to shape their behavior, start with your own and theyll follow suit. Collaboration, not control and a collective drive to achieving the common goals as understood by the team are the essence of a successful environment, be it agile or any other. The team needs to feel that their views are represented and listened to whilst creating an environment to grow through adaptation; learning through team feedback and being engaged within a safe place to fail, as well as experience success. Teams need to be empowered to manage themselves, using the best people for the tasks specified through joint discussion. In summary, Agile does not need managers in the team, but leaders.
www.agilerecord.com
49
> About the author

Leanne Howard is an Agile Principal Consultant with Planit. Over the past 20 years Leanne has worked in the IT software testing industry across multiple programs and projects including those using Agile. She is a specialist in the implementation of practical testing methods with a strong focus on client satisfaction. She enjoys sharing her knowledge through mentoring and coaching others advocating continuous learning, and is active in the promotion of the testing profession through her role at Planit and involvement with relevant association bodies.
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
50
www.agilerecord.com
Risk Poker: Risk based testing in agile projects

by Jurian van de Laar
About risk based testing Testing is an important supporting activity to achieve working software in agile projects. By finding defects and providing insight in the quality of the software, testing plays a role in providing feedback to software developers, in satisfying acceptance criteria and in adhering to the Definition of Done. Testing activities can be seen as mitigating product risk. A product risk is defined as a risk which is directly related to a potentially failing product. Risk based testing is an approach for developing and prioritizing tests based upon the impact and likelihood of failure of the functionality to be tested. Likelihood is the chance that the software contains defects (caused by for example poor programming, high complexity, etc.). Impact is an indication of the consequences when the software fails. Risk based testing with Risk Poker in agile projects One of the most frequently asked questions about testing, both in traditional and Agile projects, is: How much testing should be done? In some traditional projects managers may want the team to test everything. They want to be absolutely sure that the system is completely tested before it is released into the market, to prevent problems or even claims in production. However, testing the entire system in every possible way is impossible. No organization is willing to spend sufficient resources for exhaustive testing and pressure on budget and release schedule will not allow for the required effort. James Bach, leading proponent of Exploratory Testing, introduced the concept of good enough testing in 1997. This concept is helpful in understanding the risk based testing approach. Agile projects are usually not striving to develop the absolute perfect software. The concept of a potentially useful version of working product in Scrum actually means that the software is working good enough to take it into production. Good enough in this context is defined as: providing sufficient benefits, having no critical problems and the benefits of releasing now outweigh both the consequences of
non-critical problems and delaying the project for further testing. Risk Poker is an approach for product risk based testing in agile projects. The process of Risk Poker is similar to the way that Planning Poker is done, e.g. in Scrum, except that it will result in risk identification and risk analysis rather than estimations and story points. What are the reasons for applying risk based testing with Risk Poker in agile projects and what are the benefits? 1. Most agile methods and frameworks like Scrum are time-boxed. Iterations have a fixed duration, so both development and testing activities are by definition limited to a pre-defined timeframe. Risk based testing provides an excellent answer to the problem how much testing by ensuring that the most important testing has been done within the available time. Therefore risk based testing is a very suitable approach for time-boxed development methods. Just like Planning Poker, Risk Poker is a team-based activity and decisions are made by achieving consensus. In the Scrum process, Risk Poker can be easily combined with Planning Poker in the Planning meeting. They complement each other, because information about business value from the Product Owner (PO) will provide input for the impact component of product risk, and the question-andanswer game about product risks will be input for estimating the testing effort in Planning Poker. User stories are very suitable entities to be used as risk items in a product risk analysis. In agile projects, risk identification comes down to identifying user stories. Agile is all about working software, Risk Poker is a lightweight approach to achieve the most appropriate balance between sufficient quality and acceptable risk within the available constraints in time and resources.
2. 3.
4.
5.
www.agilerecord.com
51
In our practice, working in agile projects, we discovered that the original product risk management approach as we had described it in our white paper in 2006 required some modifications to better fit to an agile way of working. We needed a lightweight variant, one that could be easily integrated with Risk Poker in the planning meeting and sufficiently intuitive for the team to quickly understand it and get fast results. As an example, Risk Poker uses traffic-light-colored poker cards instead of the conventional quantitative approach using risk factors. Risk Poker: How does it work? Traditional risk assessment starts with identifying product risks. In Scrum, the backlog items (e.g. user stories) are considered risk items. So the question for each backlog item will be: What risk is associated with this user story? This question is addressed in the conversation about the user story during the sprint planning session. Prior to the planning meeting, the team should determine which factors influence the quality of the delivered software. Typical factors for likelihood are complexity, new development (level of re-uses), interrelations (number of interfaces), size, technology and (in-)experience of team. The team itself decides which factors for likelihood are to be taken into account during the Risk Poker. Concerning the impact, influencing factors can be business importance (i.e. selling item), financial damage, usage intensity, external visibility and legal sanctions. The PO will decide (together with stakeholders) which of these factors for impact are to be taken into account. Risk Poker is ideally played prior to Planning Poker. This is because the risk determined for each item should determine the test effort involved in every backlog item. It is a consensus-based technique for estimating risk. During the planning meeting, next to their planning poker cards, every estimator is given a set of risk poker cards, which contains 4 colored cards (green, yellow, orange and red). The colors represent the perceived risk level (both for likelihood and impact). The meaning of the colors is similar to story points: red for the highest risk level, green for the lowest risk level. First the moderator or the PO provides an overview of the User Story (US). The team is given the opportunity to ask questions, discuss the US and bring all issues concerning risk into play. While discussing, colors must not be mentioned, since this can influence every individual team member. When all is clear for the Scrum team, every team member will choose the colored card they think represents the risk (for likelihood of failure) best. Everyone shows their card simultaneously by throwing them on the table. When estimated risk colors are not all identical, team members with different colors are asked to clarify their choice of color. When all estimators have explained their color, the risk estimation process is repeated. If all thrown colors are still not equal, the PO (or moderator) can ask the estimators again for clarification and repeat the process, or the PO can decide which color is picked (usually the color representing the highest risk). Concerning the impact, the PO will give a color representing this risk (impact component) best and explains this to the team. Because the PO role in Scrum is typically responsible
for both prioritizing user stories and assigning business value, the impact component of product risk is determined by the PO solely without striving for consensus by playing the risk poker cards with the team. The explanation to the team, however, is important to get the teams support, and the team is also encouraged and challenged to ask questions. After Risk Poker has been played for a US, the Planning Poker can take place for that same US following its own rules. Applying the risk based approach When putting the User Stories to the Scrum board, the colors for risk likelihood and impact should be made visible together with the total number of points.
The colors chosen represent a certain thoroughness of testing. Red means very thorough testing, whereas green means less (or maybe even no) testing. To define this thoroughness, a wide variety of actions can be taken. One can think of code reviews, unit tests (e.g. level of code coverage), acceptance tests, regression tests, the way testers are involved in testing items and the usage of testing techniques. For every combination of colors, a set of actions is defined. The measures become stricter if the colors are indicating more risk. Some examples: Likelihood is green and impact is yellow: Unit test with decision coverage (e.g. 70%) and acceptance test with use case technique (only basic flow). Tests may be created and executed by every team member. Likelihood is orange and impact is green: Unit test with condition determination coverage (e.g. 80%) and acceptance test with only exploratory testing. Likelihood and impact are both red: Code reviews, unit test with multiple condition coverage (e.g. 80%) and acceptance test with use case technique (basic, alternative and exceptional flow). Tests must be created and executed by test team member.
Risk likelihood is more or less coupled with unit testing, whereas the risk impact has a close relation with acceptance testing. Differences with traditional product risk analysis There are some differences with Risk Poker compared to a normal risk assessment. For instance, the PO will represent all stakeholders and should have good knowledge of the US, so the PO can judge the impact of the risk. Risk Poker is only useful for user stories which are to be picked up in the upcoming sprint.
52
www.agilerecord.com
The approach of risk poker is less detailed than in the traditional way, by using 4 colors instead of calculations with numeric scores and weighting factors. Alternative The set of risk cards can either exist of 3 (green, orange, red) or 4 cards (green, yellow, orange, red). When choosing 3 colors, there is the chance that the middle (orange) color will be chosen as a safe standard estimation. When choosing 4 colors, estimators are forced to make a decision. When playing with 4 colors however, the incremental step from one color to the next is smaller compared with the 3 color deck of risk cards. For the estimators it might be more difficult to pick their choice or to reach consensus. Acknowledgements This article is based on the white paper Risk Poker explained (2012), written by my colleague Jurrin Seubers, with contributions from Pascal Maus. The principles of risk based testing as explained in this article are based on the white paper Product Risk Based Testing (2006), written by Erik van Veenendaal, Ruud Cox, Stephanie van Dijck and Jurian van de Laar.
> About the author

Jurian van de Laar is senior consultant, trainer and Agile Testing coach at Improve Quality Services B.V. in The Netherlands. He has practical working experience since 1994 as software developer, team leader, tester and test consultant. He consulted various companies, including TomTom, Philips, Triodos Bank and DHL. Jurian is teacher of courses in Agile testing, requirements engineering and structured testing (ISTQB). Jurian is a Certified Professional Scrum Master (Scrum.org) and certified in Prince2, TMap, CAT, ISTQB and IREB. As accredited trainer of the international Certified Agile Tester program (CAT) Jurian was the teacher of the first CAT training in The Netherlands. He contributed as author to various publications (e.g., Testing Experience) and he is a regular speaker at (inter-) national conferences (EuroSTAR 2009, Swiss Requirements Day 2010, Belgium Testing Days 2011). Jurian is vice chair of the Belgium and Netherlands Testing Qualifications Board (BNTQB).
Follow us @ar_mag
www.agilerecord.com
53
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
Yuri Arcurs Fotolia.com 1 Lida Salatian Fotolia.com 16 Valery Sibrikov Fotolia.com 19 iStockphoto.com/dextrosadextrosa 24 tlorna Fotolia.com 28 iStockphoto.com/EyeJoy 33 L.F.otography Fotolia.com 36 Tobias Machhaus Fotolia.com 39 frank peters Fotolia.com 44 Martin Goldmann / pixelio.de 48 Tschi-Em / pixelio.de 51
Index Of Advertisers
Agile Testing Days 5 CaseMaker SaaS 21 CAT Certified Agile Tester 3 CAT Certified Agile Tester in Orlando 17 CKC Seminars 13 Daz & Hilterscheid 55 expo:QA 43 IREB 23 iSQI 30 Knowledge Transfer 25 nexoQA 47 Online Training 18 Software Quality Lab 2 SWE Guild 32 Testen fr Entwickler 35 Testing Solutions Group 27
54
www.agilerecord.com
Training with a View
Dates * 22.06.1222.06.12 23.07.1227.07.12 11.06.1215.06.12 02.07.1206.07.12 04.06.1205.06.12 20.08.1221.08.12 06.06.1208.06.12 19.06.1221.06.12 29.05.1231.05.12 16.07.1218.07.12 23.07.1225.07.12 18.06.1221.06.12 18.06.1221.06.12 30.07.1202.08.12 07.05.1211.05.12 11.06.1215.06.12 09.07.1213.07.12 07.05.1211.05.12 30.07.1203.08.12 07.05.1211.05.12 18.06.1222.06.12 25.06.1229.06.12
Course Anforderungsmanagement CAT Certied Agile Tester CAT Certied Agile Tester CAT Certied Agile Tester HP Quality Center HP Quality Center IREB Certied Professional for Requirements Engineering Foundation Level IREB Certied Professional for Requirements Engineering 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 ISTQB Certied Tester Foundation Level ISTQB Certied Tester Foundation Level ISTQB Certied Tester Advanced Level Technical Test Analyst 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 Manager ISTQB Certied Tester Advanced Level Test Manager ISTQB Certied Tester Advanced Level Test Manager
Language Place German German English English German German German English German German German German German German German German German German German German German German Berlin Mnchen/Karlsruhe Stockholm/Sweden Orlando/USA Berlin Berlin Berlin Oslo/Norway Nrnberg Mnchen/Karlsruhe Berlin Frankfurt Berlin Frankfurt Mdling/Austria Berlin Frankfurt/Stuttgart Kln Berlin Mdling/Austria Mnchen Berlin
Price 499,2100,2100,2100,998,998,1400,1600,1495,1495,1495,1800,1800,1800,2100,2100,2100,2100,2100,2100,2100,2100,* subject to modications all prices plus VAT
more dates and onsite training worldwide in German, English, Spanish, French on our website: http://training.diazhilterscheid.com
Kurfrstendamm, Berlin Katrin Schlke

Agilerecord Magzine

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agilerecord Magzine

Uploaded by

Copyright:

Available Formats

The Magazine for Agile Developers and Agile Testers

Management and Leadership in Software Organisations

Software Quality DayS

call for papers

Submit your contribution for 2013 now!

Date Venue Options Languages Submission

Quality - investment for the future

Pragmatic, Soft Skills Focused, Industry Supported

Book your training with Daz & Hilterscheid!

Jose Manuel Beas

Go to www.agilerecord.com/editorial_board.php to read their biographies

November 1922, 2012 in Potsdam, Germany

November 1922, 2012 in Potsdam, Germany

Become Agile Testing Days Sponsor 2012

November 1922, 2012 in Potsdam, Germany

Track 1 Consensus Talks 10 min. each

Track 2 Open Space Cirilo Wortel

TBD TestLab Bart Knaack & James Lyndsay

TBD Testing Dojos

TBD Coding Dojos Meike Mertsch & Michael Minigshofer

Vendor Track Product Demo

Time 16:1516:40 16:4017:25

Track 1 The Beating Heart of Agile Andrea Provaglio

Track 4 Developers Exploratory Testing Raising the bar Sigge Birgisson

17:2517:30 17:3018:30 19:00

Break Keynote: Self Coaching Lasse Koskela Social Event

November 1922, 2012 in Potsdam, Germany

Track 1 Consensus Talks 10 min. each

Track 2 Open Space Cirilo Wortel

TBD TestLab Bart Knaack & James Lyndsay

TBD Testing Dojos

TBD Coding Dojos Meike Mertsch & Michael Minigshofer

Vendor Track Product Demo

Time 16:1516:40 16:4017:25

Track 1 From CI 2.0+ to Agile ALM Michael Httermann

Track 2 Testers Agile Pocketbook Stevan Zivanovic

Track 4 Excelling as an Agile Tester Henrik Andersson

Keynote: Reinventing software quality Gojko Adzic

November 1922, 2012 in Potsdam, Germany

Agile Solutions Leading with Test Data Management Ray Scott

Changing Change Tony Bruce

16:0016:05 16:0517:05 17:05

November 1922, 2012 in Potsdam, Germany

Become Agile Testing Days Sponsor 2012

Exhibitors & Supporters 2011:

The Austrian Software Test Experts!

Agile Testing in the Real World It Takes a Village

> About the author

annual conference and exhibition

KZA BV RANOREX SQS NEDERLAND B.V. VX COMPANY

www.agilerecord.com MORE INFORMATION AND REGISTRATION AT WWW.TESTAUTOMATIONDAY.COM

PARTICIPANTS KNOWN MARCH 23TH 2012

Column: An agile testing future

Stephen Covey: Seven habits of highly effective people5

> About the author

7 http://www.lifehack.org/articles/lifestyle/12-rules-for-self-leadership. html 8 http://www.developsense.com/blog/2010/05/heuristics-and-leadership

Increasing test awareness in a scrum team

> About the author

Book your CAT training in USA!

CAT goes USA

Online Training & Exam Preparation

Our company saves up to

The Agile Project Manager There Can Be Only One!