agilerecord magzine

The Magazine for Agile Developers and Agile Testers

May 2012

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

Management and Leadership in Software Organisations

2013 January 15 - 17, Vienna

call for papers

Software Quality DaySThe annual conference on software quality and testing

Date January 15 - 17, 2013

Venue Vienna

Options •Workshop/tutorial •Practicalpresentation •Extendedpractical

presentation •Experts-talk •Scientificpresentation

Languages •English •German

Submission until May 31, 2012

The software Quality Days is one of the largest events on softwarequalityworldwide.Thismakesitamustforanyoneinterested in software quality, testing and quality oriented system&softwaredevelopment.

Quality-investmentforthefuture

topics for presentations and tutorials:

•Requirements,modellingandarchitecture•Testmethodsandtestautomation•Agilemethods,processesandquality•Embeddedsystemsandmechatronics•Integrationanddeployment•UsabilityandsecurityAndmanymore!

Submityourcontributionfor2013now!

www.software-quality-days.com/en/lecturers

www.software-quality-days.com

1www.agilerecord.com

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.

We’ve 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 don’t 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, I’m 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é Díaz

Editorial

2 www.agilerecord.com

ContentsEditorial 1

Editorial Board 4

Agile Testing in the Real World “It Takes a Village” 11by Lisa Crispin

Lead yourself! 14by Huib Schoots

Increasing test awareness in a scrum team 16by Milvio Díaz

The Agile Project Manager – There Can Be Only One! 19by Robert Galen

Management And Leadership In Software Organisations 24by Plamen Balkanski

Virtual Teams and Conflicting Leadership Styles – Case Study 28by Raja Bavani

Beyond Servant Leadership in Agile Projects 33by Rathinakumar Balasubramanian

Leading Software Teams, The Agile Context 36by Nishant Pandey

How to navigate through Scrum – a guide for Scrum Masters 39by Katja Roth & Jane Trümner

Radical ManagementSM – A Paradigm Shift for the 21st Century 44by Simon Roberts & Birgit Panzram

Leadership and not management in an Agile team 48by Leanne Howard

Risk Poker: Risk based testing in agile projects 51by Jurian van de Laar

Masthead 54

Picture Credits 54

Index Of Advertisers 54


©

Ser

gejy

Gal

ushk

o –

Foto

lia.c

om

Pragmatic, Soft Skills Focused, Industry Supported

Díaz & Hilterscheid GmbH / Kurfürstendamm 179 / 10707 Berlin / Germany

Tel: +49 30 747628-0 / Fax: +49 30 747628-99

www.diazhilterscheid.de [email protected]

Book your training with Díaz & Hilterscheid!

Open seminars:

CAT is no ordinary certification, but a professional jour-

ney 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 tes-

ter 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 tes-

ter, 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 encour-

ages 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, dem-

onstrated abilities in Agile expertise through such fo-

rums as presentations at conferences or Special Interest

groups and interviews.

Did this CATch your eye? If so, please contact us for

more details!

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)

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

http://www.diazhilterscheid.de/en/training_courses.php?m=ar_10&a=3


Editorial Board

David Alfaro

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

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

ZuzannaSochova

Declan Whelan

November 19–22, 2012 in Potsdam, GermanyDorint Hotel Sanssouci Berlin/Potsdam

www.agiletestingdays.com

http://www.agiletestingdays.com/?m=ar_10&a=5



Become Agile Testing Days Sponsor 2012

The Agile Testing Days 2012, from November 19–22 is an annual European conference for and by international professionals in-volved 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

Time Tutorial

08:00–09:00 Registration

09:00–17:30“Management 3.0 Workshop”Jurgen Appelo

09:00–17:30 “Making Test Automation Work in Agile Projects”Lisa Crispin

09:00–17:30“Transitioning to Agile Testing”Janet Gregory:

09:00–17:30 “Introduction to Disciplined Agile Delivery”Scott W. Ambler

09:00–17:30“Beheading the legacy beast”Ola Ellnestam

09:00–17:30“Fully integrating performance testing into agile development”Scott Barber

09:00–17:30“Mindful Team Member: Working Like You Knew You Should”Lasse Koskela

09:00–17:30“Mind Maps: an agile way of working”Huib Schoots & Jean-Paul Varwijk

09:00–17:30“Winning big with Speci� cation by Example: Lessons learned from 50 successful projects”Gojko Adzic

09:00–17:30

“Software Testing Reloaded – So you wanna actually DO something? We’ve got just the workshop for you. Now with even less powerpoint!”Matt Heusser & Pete Walen

All tutorials include two co� ee breaks (11:00 and 15:30) and lunch (13:00–14:00).

Tutorials

November 19–22, 2012 in Potsdam, GermanyDorint Hotel Sanssouci Berlin/Potsdamwww.agiletestingdays.com

Time Track 1 Track 2 Track 3 Track 4 Vendor Track


09:20–09:25 Opening

09:25–10:25 Keynote: “Disciplined Agile Delivery: The Foundation for Scaling Agile” – Scott W. Ambler

10:25–10:30 Break

10:30–11:15 “5A – assess and adapt agile

activities”Werner Lieblang &

Arjan Brands

“Moneyball and the Science of Building Great

Agile Team”Peter Varhol

“Get them in(volved)”

Arie van Bennekum

“Testing distributed

projects”Hartwig Schwier

11:15–11:40 Break

11:40–12:25 “The Agile Manifesto

Dungeons: Let’s go really deep this

time!”Cecile Davis

“Balancing and growing agile testing with

high productive distributed teams”Mads Troels Hansen & Oleksiy Shepetko

“We Line Managers Are Crappy Testers

– Can We Do Something About

It”Ilari Henrik Aegerter

“The many � avors and toppings of exploratory

testing”Gitte Ottosen

12:25–13:45 Lunch

13:45–14:45 Keynote: “Myths About Agile Testing, De-Bunked” – Janet Gregory & Lisa Crispin

Time Track 1 Track 2 TBD TBD TBD Vendor Track

14:45–16:15 Consensus Talks10 min. each

Open SpaceCirilo Wortel

TestLabBart Knaack &

James Lyndsay

Testing Dojos Coding DojosMeike Mertsch

& Michael Minigshofer

Product Demo


16:15–16:40 Break

16:40–17:25 “The Beating Heart of Agile”

Andrea Provaglio

“Why World of Warcraft is like

being on an agile team, when it

isn’t and what we can learn from

online role playing games”

Alexandra Schladebeck

“Agile communication: Back and forth

between managers and teams”

Zuzana Sochova & Eduard Kunce

“Developers Exploratory

Testing – Raising the bar”

Sigge Birgisson

17:25–17:30 Break

17:30–18:30 Keynote: “Self Coaching“ – Lasse Koskela

19:00 Social Event

Conference Day 1

Tutorials




09:20–09:25 Opening

09:25–10:25 Keynote: “Disciplined Agile Delivery: The Foundation for Scaling Agile” – Scott W. Ambler

10:25–10:30 Break

10:30–11:15 “5A – assess and adapt agile

activities”Werner Lieblang &

Arjan Brands

“Moneyball and the Science of Building Great

Agile Team”Peter Varhol

“Get them in(volved)”

Arie van Bennekum

“Testing distributed

projects”Hartwig Schwier

11:15–11:40 Break

11:40–12:25 “The Agile Manifesto

Dungeons: Let’s go really deep this

time!”Cecile Davis

“Balancing and growing agile testing with

high productive distributed teams”Mads Troels Hansen & Oleksiy Shepetko

“We Line Managers Are Crappy Testers

– Can We Do Something About

It”Ilari Henrik Aegerter

“The many � avors and toppings of exploratory

testing”Gitte Ottosen

12:25–13:45 Lunch

13:45–14:45 Keynote: “Myths About Agile Testing, De-Bunked” – Janet Gregory & Lisa Crispin





James Lyndsay



Product Demo


16:15–16:40 Break

16:40–17:25 “The Beating Heart of Agile”

Andrea Provaglio

“Why World of Warcraft is like

being on an agile team, when it

isn’t and what we can learn from

online role playing games”

Alexandra Schladebeck

“Agile communication: Back and forth

between managers and teams”

Zuzana Sochova & Eduard Kunce

“Developers Exploratory

Testing – Raising the bar”

Sigge Birgisson

17:25–17:30 Break

17:30–18:30 Keynote: “Self Coaching“ – Lasse Koskela

19:00 Social Event

Conference Day 1

Tutorials





08:10–08:55 Early Keynote: TBD

09:20–09:25 Opening

09:25–10:25 Keynote: “How to change the world” – Jurgen Appelo

10:25–10:30 Break

10:30–11:15 “Continuous Delivery of Long-Term

Requirements”Paul Gerrard

“Testing seen through a puzzle”

Eusebiu Blindu

“How releasing faster changes

testing”Alexander Schwartz

“Testers are bearers of good

news”Niels Malotaux

11:15–11:40 Break

11:40–12:25 “Experiences with introducing

a Continuous Integration

Strategy in a Large Scale Development

Organization”Simon Morley

“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

12:25–13:45 Lunch

13:45–14:45 Keynote: “Adaptation and Improvisation – but your weakness is not your technique” – Markus Gärtner





James Lyndsay



Product Demo


16:15–16:40 Break

16:40–17:25 “From CI 2.0+ to Agile ALM”

Michael Hüttermann

“Testers Agile Pocketbook”

Stevan Zivanovic

“Extending Continuous Integration

and TDD with Continuous

Testing”Jason Ayers

“Excelling as an Agile Tester”

Henrik Andersson

17:25–17:30 Break

17:30–18:30 Keynote: “Reinventing software quality“ – Gojko Adzic

Conference Day 2




08:10–08:55 Early Keynote: TBD

09:10–09:15 Opening

09:15–10:15 Keynote: “Fast Feedback Teams” – Ola Ellnestam

10:15–10:20 Break

10:20–11:05 “Exceptions, Assumptions and

Ambiguity: Finding the truth behind

the Story”David Evans

“BDD with Javascript for Rich Internet Applications”

Carlos Blé & Ivan Stepániuk

“Automation of Test Oracle

– unachievable dream or

tomorrow’s reality”Dani Almog

“You Can’t Sprint All the time – the

importance of slack”

Lloyd Roden

11:05–11:30 Break

11:30–12:15 “Combining requirements

engineering and testing in agile”

Jan Jaap Cannegieter

“TDD-ing Javascript Front

Ends”Patrick Kua

“Archetypes and Templates: Building a lean,

mean BDD automation

machine for multiple investment platforms”

Mike Scott & Tom Roden

“Taking over a bank with open

source test tooling”

Cirilo Wortel

12:15–13:00 “Agile Solutions – Leading

with Test Data Management”

Ray Scott

“Changing Change”

Tony Bruce

“Technical Debt”Thomas Sundberg

“Changing the context: How a bank changes their software development

methodology”Huib Schoots

13:00–14:10 Lunch

14:10–15:10 Keynote: “The ongoing evolution of testing in agile development” – Scott Barber

15:10–15:15 Break

15:15–16:00 “Thinking and Working Agile in

an Unbending World”

Peter Walen

“Sprint Backlog in ATDD”

Ralph Jocham

“Mobile test automation at mobile scale”

Dominik Dary & Michael Palotas

“Quality On Submit, Continuous

Integration in Practice”Asaf Saar

16:00–16:05 Break

16:05–17:05 Keynote: “The Great Game of Testing” – Matt Heusser

17:05 Closing

Conference Day 3Conference Day 2




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: 16,200.00 €*

Platinum Exhibitor: 10,800.00 €*

Gold Exhibitor: 5,400.00 €*

Silver Exhibitor: 3,600.00 €*

Media Sponsor

Program First Page Advert: 990.00 €*

Program Full Page Advert: 495.00 €*

Program Half page Advert: 249.00 €*

Conference Sponsor

MIATPP Award Trophy Sponsor: 2,970.00 €*

Conference Bag Insert: 495.00 €*

Co� ee Break Cup Sponsor: 1,530.00 €*

Social Event Sponsor: 8,990.00 €*

Session Sponsor

90 Minutes Product Demo: 2,250.00 €*

45 Minutes Early Keynote: 2,250.00 €*

Exhibitors & Supporters 2011:

The Austrian Software Test Experts!

* Early Bird price – valid until July 31, 2012.

Please � nd details on packages online at www.agiletestingdays.com

A Díaz & Hilterscheid Conference

Díaz & Hilterscheid Unternehmensberatung GmbHKurfürstendamm 17910707 BerlinGermany

Phone: +49 (0)30 74 76 28-0Fax: +49 (0)30 74 76 28-99

[email protected]/net/agiletestingwww.twitter.com/AgileTD

http://www.agiletestingdays.com/?m=ar_10&a=5





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: 16,200.00 €*

Platinum Exhibitor: 10,800.00 €*

Gold Exhibitor: 5,400.00 €*

Silver Exhibitor: 3,600.00 €*

Media Sponsor

Program First Page Advert: 990.00 €*

Program Full Page Advert: 495.00 €*

Program Half page Advert: 249.00 €*

Conference Sponsor

MIATPP Award Trophy Sponsor: 2,970.00 €*

Conference Bag Insert: 495.00 €*

Co� ee Break Cup Sponsor: 1,530.00 €*

Social Event Sponsor: 8,990.00 €*

Session Sponsor

90 Minutes Product Demo: 2,250.00 €*

45 Minutes Early Keynote: 2,250.00 €*

Exhibitors & Supporters 2011:

The Austrian Software Test Experts!

* Early Bird price – valid until July 31, 2012.

Please � nd details on packages online at www.agiletestingdays.com

A Díaz & Hilterscheid Conference

Díaz & Hilterscheid Unternehmensberatung GmbHKurfürstendamm 17910707 BerlinGermany

Phone: +49 (0)30 74 76 28-0Fax: +49 (0)30 74 76 28-99

[email protected]/net/agiletestingwww.twitter.com/AgileTD

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 today’s 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 profes-sionals 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, confer-ences 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 com-munities, instant messaging and Skype, I continually improve my own skills, and share my experiences with others.

Dunbar’s Number says that a person can only maintain stable social relationships with an average of 150 other people (http://en.wikipedia.org/wiki/Dunbar’s_number). But maybe we don’t 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 don’t 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 I’ve been helped.

I do build stable social relationships with many people whom I meet via Twitter, mailing lists such as [email protected], and testing communities such as Weekend Testing (week-endtesting.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. I’ve learned so much from Gojko, whether we’re 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. I’m not much good at building, say, a local user group up from scratch, but I enjoy connecting individuals with each other for their mutual ben-efit. 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. I’ve been inspired by the practitioners profiled in his WhoIs interview series (now a book, http://leanpub.com/WhoIsAgile). Through these interviews, I’ve 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.

There’s a planet of fascinating people in our software community, and the internet helps draw us together. Given that you’re read-

Agile Testing in the Real World “It Takes a Village”

Column

by Lisa Crispin


ing Agile Record, you’re 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 col-leagues 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.

Lisa Crispinis the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002), and a contributor to Experiences of Test Auto-mation by Dorothy Graham

and Mark Fewster (Addison-Wesley, 2011) and Beautiful Testing (O’Reilly, 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 Lisa’s work, visit www.lisacrispin.com. @lisacrispin on Twitter, entaggle.com/lisacrispin

> About the author

You’d like to comment on an article?Please feel free to contact us:[email protected]

Reader’s Opinion


Advertise at

www.agilerecord.com

After the first successful edition of Test Automation Day (2011), we would like towelcome 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.

annual conference and exhibition

Meet the world's leading Test Automation experts, get the latest insights on emerging technologies, proven practices, and trends!

FOUNDING PARTNER

PARTNERS

SPONSORS

PARTICIPANTS KNOWN MARCH 23TH 2012

EXHIBITORS

KZA BV

RANOREX

SQS NEDERLAND B.V.

VX COMPANY

Register with the special member code!As a reader of Agile Record Magazine, you’ll get a € 100,- discount.

Register with the code: TAD2012-AGI on www.testautomationday.comand pay only € 195,- (excl. VAT) for Test Automation Day!

MORE INFORMATION AND REGISTRATION AT WWW.TESTAUTOMATIONDAY.COM

With contribution of (amongst others - from left to right):

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

€100,‐discount for readers of

CONFERENCE ORGANIZATION2nd edition, June 21st 2012, World Trade Center - Rotterdam, The Netherlands


There is a lot to be said about management and leadership in IT. This column is about a very specific kind of leadership: self-leadership. It is about you and about being a true leader of your-self. 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, leader-ship is doing the right things: about being effective”1. The difference between management and leadership is described in the article I recently read on changingminds.org about leadership vs. manage-ment2. 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 action”3, 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 suc-cess. And that is the key to leadership!

You can manage yourself by having objectives and making short-term 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.

1 Drucker, Peter F. The Practice of Management. Oxford: Elsevier Ltd., 1955.

2 http://changingminds.org/disciplines/leadership/articles/manager_lead-er.htm

3 http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_ac-tion.html

Some weeks ago I had an interesting conversation with a tester friend. He was complaining about his work, the chances he doesn’t 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 don’t 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 didn’t 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 career”4 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 Covey’s 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. Be proactive

2. Begin with the end in mind

3. Put first things first

4. Think win/win

5. Seek first to understand, then to be understood

6. Synergize

7. Sharpen the saw

Stephen Covey: Seven habits of highly effective people5

4 http://www.ouicoach.com/docs/car_self-managing.pdf

5 https://www.stephencovey.com/7habits/7habits.php

Lead yourself!

Column: An agile testing future

by Huib Schoots


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 “Self-Leadership: Leading Yourself to Personal Excellence”6 and “12 Rules for Self-Leadership”7; 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 wasn’t happy and was complaining a lot. Things didn’t go as I wanted and I was blaming everybody and everything around me. The project I did wasn’t 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 let’s have a closer look. Good testing in general, but exploratory testing in particular, requires a lot of self-manage-ment. Excellent testing requires self-leadership. Michael Bolton wrote a nice post on his blog called “heuristics and leadership”8 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) leadership”9 in 2009 that is very worthwhile checking (or should I say testing?).

6 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-STC9000-ExploratoryTestingLeadership.pdf

So, in short, stop managing yourself and start leading yourself into a bright future!

References and links1. 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_lead-ers_inspire_action.html

4. http://www.ouicoach.com/docs/car_self-managing.pdf

5. https://www.stephencovey.com/7habits/7habits.php

6. 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-STC9000-ExploratoryTestingLeadership.pdf

Huib Schootshas 15 years experience in IT and software testing. After studying Business Informatics he became a developer. Soon he discov-ered that development was not his cup of tea and soft-ware testing is fun. Huib has experience in various roles such as tester, test coordi-

nator, 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 curi-ous, passionate and has (unsuccessfully) attempted to read everything published on software testing ever writ-ten. 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

> About the author


pic:

© S

erge

jy G

alus

hko

– Fo

tolia

.com

gra

hpic

: © W

ikim

edia

Com

mon

s

Díaz & Hilterscheid GmbH / Kurfürstendamm 179 / 10707 Berlin, Germany

Tel: +49 30 747628-0 / Fax: +49 30 747628-99


Book your CAT training in USA!CAT is no ordinary certification, but a professional journey into the world of Agile. As with any voyage you have to

take the first step. You may have some experience with Agile from your current or previous employment or you may

be venturing out into the unknown. Either way CAT has been specifically designed to partner and guide you through

all aspects of your tour.

Open Seminar in USA:

July 2–6, 2012 in Orlando, Florida CAT goes USA

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 reputa-tion 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? I’d 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 simula-tion 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 dur-ing 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 slide-based demos plus a product demo. Test became a part of the slide-based 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.

Increasing test awareness in a scrum teamby Milvio Díaz


Milvio DíazHas over 5 years experience working as a test leader in a Scrum software develop-ment team.He has experience in vari-ous roles as tester, test co-ordinator 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.

> About the authorNegatively, 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 project’s 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.

pic:

© S

erge

jy G

alus

hko

– Fo

tolia

.com

gra

hpic

: © W

ikim

edia

Com

mon

s

Díaz & Hilterscheid GmbH / Kurfürstendamm 179 / 10707 Berlin, Germany

Tel: +49 30 747628-0 / Fax: +49 30 747628-99


Book your CAT training in USA!CAT is no ordinary certification, but a professional journey into the world of Agile. As with any voyage you have to

take the first step. You may have some experience with Agile from your current or previous employment or you may

be venturing out into the unknown. Either way CAT has been specifically designed to partner and guide you through

all aspects of your tour.

Open Seminar in USA:

July 2–6, 2012 in Orlando, Florida CAT goes USA

http://www.diazhilterscheid.de/en/courses.php?id=313&date=1836&m=ar_10&a=17

ISTQB® Certifi ed Tester Foundation Level (English & German)ISTQB® Certifi ed Tester Advanced Level – Test Manager (English)ISTQB® Certifi ed Tester Advanced Level – Test Analyst (English)ISTQB® Certifi ed Tester Advanced Level – Technical Test Analyst (English)ISEB Intermediate Certifi cate in Software Testing (English)

Sample Questions & Answers, Exam Simulation, Quiz & Exercises, Videos

© iS

tock

phot

o/Yu

ri_Ar

curs

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

Online Training & Exam Preparation


I hope I’m 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 isn’t just any team. It’s your example team; a high perfor-mance agile machine that illustrates sound principles and delivers on the promises of agility. It’s 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. It’s the first team that moves from Scrum to Kanban. Or it’s the first team that tries out Cucumber as a BDD mechanism, while including the whole team in crafting acceptance test driven automation.

Let’s explore some of the characteristics of a singular example agile team.

Let’s first explore what the team isn’tThe team isn’t 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 isn’t 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 isn’t 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 isn’t placed on a pedestal for everyone to see. Yes, it’s your example team and the one that illustrates the best properties and practices of your agile adoption and progress. However, they’re also just another team and equal to everyone else.

What the team is…If you buy into creating a model team, it’s sort of hard to figure out what that might “look like” in the wild. While I don’t 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.

I’ve categorized them into four areas: locale, smells, swarming, quality, and plan adjustments that we’ll explore in detail next.

LocaleThe 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. They’re insulated from random noise and interruptions that might result from too open a space. I’ve 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.

The Agile Project Manager – There Can Be Only One!by Robert Galen


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 you’re initially forming your team, it’s a really good idea to bring everyone together for some initial introduc-tions, training, and team-building. How else would you form a high-performing team?

SmellsAn 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.

There’s a buzz in the room, it’s 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, it’s 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!

There’s 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 it’s about hovering around screens and talking about software design, behavior, adjustments, tests failing/pass-ing, 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 there’s an overwhelming feeling of “controlled chaos”, especially if you’re part of a well-performing agile team. The point is that it’s 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 swarmingI 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 shouldn’t 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.

In fact, this isn’t 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, it’s a whole lot easier to talk about this than it is to deeply instill these behaviors in agile teams. This is why you’d want to get it right in your example team and see the best ways to influence this wonderful behavior.

QualityIt’s 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 that’s tested-in.

Just the other day a colleague asked me what I thought were the highest value quality practices that influenced agile high perfor-mance. Perhaps sharing my reply would help. Here is the list of high-impact practices that I sent him and that I think are repre-sentative of an outstanding agile team:

1. Fostering a whole-team view towards quality. Moving test-ers to “the front of the line” in that they collaborate on the requirements to get the solutions right.

2. Pairing in general: pair-programming, pair-testing, triad-pairing, paired code reviews, etc.

3. Having the ability, willingness, and aggressiveness to stop work and apply corrective action(s) immediately.

4. Test planning on an iteration and release basis while initiat-ing whole team collaboration around what and how to test.

5. Applying exploratory testing in a paired fashion, leveraging session-based (charter-driven) exploratory testing across teams.

6. Performing active agile release planning so that teams gain a broad view towards dependencies and integration – in-cluding a DevOps or continuous deployment (CD) mindset.

7. Naturally applying Unit Testing / TDD (Test-Driven Develop-ment) techniques within teams.

8. 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.

9. Properly preparing for and conducting powerful sprint reviews or demos that engage stakeholders and customers to provide engaged, real-time feedback.

10. The Mike Cohn strategy of the Agile Test Pyramid works, so leverage it – including the notion of multiple tools and layered approaches.

CaseMaker SaaS supports systematically the test cases design by covering the techniques taught in the “ISTQB® Certifi ed Tester program” and standardized within the British Standard BS 7925. The implemented techniques are: Equivalence Partitioning, Bound-ary Check, Error Guessing, Decision Tables and Pairwise Testing. Furthermore Risk Based Testing is supported.

CaseMaker SaaS fi 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

Enjoy Test Case Design in the Cloud

© Daniel Kvarfordt - Fotolia.com


The first three quality differentiators listed are in order of priority. Beyond those, they’re 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 didn’t imply that “testing” was equivalent to “quality”.

Micro-adjustments and the stand-upOne 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. impedes or blocks achieving the goal,

2. provides new information that adds, changes or removes work to support the goal, or

3. Leads to discovery that influences interpretation of the goal – refactoring, under/over estimation, interruptions, skill gaps, etc.

These should be the real focus of the team. In the daily stand-up, the discussions should surround what I’ll call the micro-adjust-ments 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 col-laborative, 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 upOne of my reflective improvements in many coaching gigs is not establishing a ‘model’ or ‘example’ team quickly enough. It’s usu-ally driven by my need for an example that illustrates good agile practices from the same context that we’re initiating agile adop-tion; 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 customer’s problem, an example of a design you’re discussing, etc. He has even gone

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!

It’s 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 you’re 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 evolution…by example.

Thanks for reading,

Bob.

Bob Galenis a VP and Agile Coach at Deutsche Bank Global Tech-nologies in Cary North Caro-lina. He’s also President of RGCG, LLC a technical con-sulting company focused to-wards 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 – Bal-ancing Value from the Inside Out. He can be reached at [email protected]

> About the author


© iS

tock

phot

o.co

m/n

umbe

os

Prof van Testing recommends

Description

The training is aimed at personnel mainly invol-ved in the tasks of software requirements engi-neering. The tutorial is designed to transfer the knowledge needed to pass the examination to become an IREB CPRE-FL.

After earning a CPRE-FL certifi cate, a certifi ca-te holder can assess whether a given situation calls for requirements engineering. He under-stands the fundamental characteristics of the discipline and the interplay of methodological approaches, e.g. interview techniques, de-scription 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.certifi ed-re.com

*subject to modifi cations

Dates* 3 days

06.–08.06.12 Berlin (de)

19.–21.06.12 Oslo/Norway (en)

25.–27.09.12 Mödling/Austria (de)

16.–18.10.12 Berlin (de)

16.–18.10.12 Stockholm/Sweden

27.–29.11.12 Berlin (de)

27.–29.11.12 Oslo/Norway (en)

27.–29.11.12 Helsinki/Finland (en)

18.–20.12.12 Berlin (de)

IREB –Certifi ed Professional for Requirements Engineering – Foundation Level

© iS

tock

phot

o.co

m /

dav

idna

y

Website:http://training.diazhilterscheid.com

Follow me @vanTesting

http://www.diazhilterscheid.de/en/training_courses.php?m=ar_10&a=23


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 leader-ship 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 lead-ers 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. Jürgen Appello in his book “Management 3.0” explains that “sepa-rating 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 ar-eas 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 Leader-ship In The Software Organization?I have seen managers from a non-software development back-ground do no worse in software organizations than their predeces-sors. 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 adap-tive system became popular through many books and articles on agile software development which have borrowed it from complex-ity theory. If there’s anything specific, then that’s 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 specif-ics 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

Management And Leadership In Software Organisationsby Plamen Balkanski

Knowledge Transfer –The Trainer Excellence Guild

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

This three-day program provides a highly interacti-ve 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 ef-

fort involved in product development and result in more satisfi ed customers. Learn how to use frameworks for test writing and how to isolate your code in an effi cient 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.

TDD .NETby Lior Friedman

Date Place Price

Sept 10–12, 2012 Berlin € 1,450 + VAT

Is Agile proving hard to implement in your organisation?• Have you been successful with agile development but still ha-

ving diffi culty 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 or-ganisations and individuals. You can use business stories to bridge the communication gaps between a structured organisation and an agile development ap-proach.

Integrating Agile with a Structured Project Cultureby Paul Gerrard & Susan Windsor

Date Place Price

June 21–22, 2012 Berlin € 1,250 + VAT

Smartphones and tablets are here to stay. Test teams are facing pressure to deliver testing quickly and successful-ly on mobile devices. When faced with a mobile testing project, many testers fi nd it tempting to apply the same methods and techniques used for desktop applications. Although some of these concepts transfer directly, tes-

ting mobile applications presents its own special challenges, which un-addressed 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 fi 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 pre-pares you to start your mobile testing project with confi dence. This three-day course covers four main areas – risk management, techniques for perfor-ming effective and effi cient 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 applica-tions

• Learn the basics of how mobile application technology works• Practice techniques for fi nding bugs quickly on real mobile devices• Explore adding structure to mobile testing so you can create a repeatable

process• Uncover approaches specifi c 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.

Testing Mobile Applicationsby Jonathan Kohl

Date Place Price

August 30–31, 2012 Düsseldorf € 1,250 + VAT

http://www.diazhilterscheid.de/en/knowledge_transfer.php?m=ar_10&a=25


For more informa�on visit TSGand BCS at Tes�ng & FinanceEurope Conference 2012.16-17 May in London, UK

The Cer�fied Agile Tester course introduces experienced testers andmanagers to the prac�ces they will need and use to be effec�ve on an agileproject. A very interac�ve and prac�cal course, you will learn about:

• Agile methods and processes

• Agile requirements and specifica�ons

• Agile tes�ng and itera�ons

• Agile teams, func�ons and prac�ces

Gain the skills and recogni�on of your professionals as a Cer�fied Agile Tester.

www.tes�ng-solu�ons.comwww.bcs.org

CAT TSG Ad final:Layout 1 20/4/12 16:19 Page 1

development and open source brings many useful and scientifi-cally 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 isn’t enough because it does not cover all aspects of a complex adaptive system. And why should it? It didn’t 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 ad-dress 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 ComplexityWhen 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 Jürgen 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 or-ganizations 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 peopleThis 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 teamsThe “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 empower-ment based on teams or the individual’s 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 constraintsSelf-organizing teams can create their own rules and all they need is a set of constraints. As Nobel Prize winner (1977) Prigogine dis-covered – a complex system can self-organize only when there’s 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 CompetenceThe 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 isn’t 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 StructurePerhaps 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 abil-ity 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 EverythingThis final view of the model looks at three approaches to continu-ous 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 sys-tem 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 improve-ment is continuous and never ending.

Quick check-up: How many of the views of the Management 3.0 model can you remember?

SUMMARYLeadership is about acquiring followers, management is about aligning constraints, supporting individuals and teams, maintaining communication and feedback and ensuring continuous improve-ment never ends. Both activities can be performed by one or more individuals. Managers have to decide in what areas and how


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 aren’t 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.

Plamen BalkanskiWith over 14 years of ex-perience in IT, I come from software develop-ment background and I’ve worked in Agile, Scrum/XP and Kanban/Lean environ-ments. 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 & com-panies discover how to work better together and how to continue learning while delivering high quality solutions to business problems.

> About the author

For more informa�on visit TSGand BCS at Tes�ng & FinanceEurope Conference 2012.16-17 May in London, UK

The Cer�fied Agile Tester course introduces experienced testers andmanagers to the prac�ces they will need and use to be effec�ve on an agileproject. A very interac�ve and prac�cal course, you will learn about:

• Agile methods and processes

• Agile requirements and specifica�ons

• Agile tes�ng and itera�ons

• Agile teams, func�ons and prac�ces

Gain the skills and recogni�on of your professionals as a Cer�fied Agile Tester.

www.tes�ng-solu�ons.comwww.bcs.org

CAT TSG Ad final:Layout 1 20/4/12 16:19 Page 1


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 John’s team is responsible for developing the GUI based modules and corresponding features of the system. These two teams in-teract 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…

“…… 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 don’t 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 previ-ous 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?”

“Good. I went through your email. I am a little surprised. We have

Virtual Teams and Conflicting Leadership Styles – Case Studyby Raja Bavani


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%. That’s 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 hand-picked my team. I don’t 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 chal-lenging 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 engi-neers, 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 Re-cord. 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 engi-neers. 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

Can agile be certified?

© S

erge

jy G

alus

hko

– Fo

tolia

.com

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

Day 4: Test Driven Development, Test Automation and Non-Functional

Day 5: Practical Assessment and Written Exam

Find out what Aitor, Erik or Nitin think about the

certification at www.agile-tester.org

Supported by

BarclaysDORMA

Hewlett PackardIBMIVV

Logic StudioMicrofocus

MicrosoftMobile.de

Nokia NTSOcéSAP

Sogeti SWIFT

T-Systems Multimedia SolutionsXING

Zurich

We are well aware that agile team members shy

away from standardized trainings and exams as

they seem to be opposing the agile philosophy. Ho-

wever, agile projects are no free agents; they need

structure and discipline as well as a common lan-

guage 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 frame-

work 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.

27 training providers worldwide!

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.

ConclusionConflicting leadership styles can create insurmountable challenges in distributed projects. However, with adequate rapport and empa-thy, 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.

Raja Bavaniis Chief Architect of Mind-Tree’s Product Engineering Services (PES) and IT Ser-vices (ITS) groups and plays the role of agile evangelist. He has more than 20 years of experience in the IT in-dustry and has published papers at international con-ferences on topics related to

code quality, distributed Agile, customer value manage-ment 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 athttp://www.mindtree.com/blogs/category/software-product-engineering andhttp://mindtree.com/category/tags/agile. He can be reached at [email protected].

> About the author


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 self-organizing. 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 leader-shipliterature 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 LeadershipLevel 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 self-driven. Positional leadership will be disastrous in an agile team.

Illustrative Scenario:Shan was managing a software product development in a tra-ditional 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-to-market. 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.

Beyond Servant Leadership in Agile Projectsby Rathinakumar Balasubramanian

Fig. 1 – Four-level leadership model

1.Positional Leadership

3. Servant Leadership

2. Collaborative Leadership

4. Transformative Leadership

AGILE COACH PRODUCT OWNER

THE TEAM

Fig. 1 – Four-level leadership model


© iS

tock

phot

o.co

m/a

rlind

o71

Testen für Entwickler

Beschreibung

Während die Ausbildung der Tester in den letzten Jahren große Fortschritte machte – es gibt mehr als 13.000 zertifi zierte Tester alleine in Deutschland – wird die Rolle des Entwicklers beim Softwaretest meist unterschätzt. Dabei ist er beim Komponententest oftmals die trei-bende 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

*Änderungen vorbehalten

Termine* 2 Tage

11.–12.10.12 Berlin

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 reser-vation 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 Sanjay’s 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 re-lationship with all the members of the team.

Level 3: Servant LeadershipLevel 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 upgrad-ing a telecom application. For Amy, her team’s 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 on-time delivery.

The lesson here is that Amy’s 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 LeadershipLevel 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 organiza-tional 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 cou-ple of his customer’s 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 ac-cept 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 edu-cation, 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. http://www.greenleaf.org/whatissl/

3. http://en.wikipedia.org/wiki/Servant_leadership#cite_note-0

4. http://www.johnmaxwell.com/development-training/development-programs/organizational-development/the-5-levels-of-leadership/


Rathinakumar Balasubramanianis a project management ex-pert and works for Infosys Ltd. He has over 15 years of experience in successfully leading software projects both in traditional and ag-ile ways. He has published several papers at interna-tional project management

conferences. His areas of interest are agile project man-agement, leadership, learning and development. He is a Project Management Professional (PMP) and a Certified Scrum Master (CSM). He can be reached at [email protected]

> About the author

© iS

tock

phot

o.co

m/a

rlind

o71

Testen für Entwickler

Beschreibung

Während die Ausbildung der Tester in den letzten Jahren große Fortschritte machte – es gibt mehr als 13.000 zertifi zierte Tester alleine in Deutschland – wird die Rolle des Entwicklers beim Softwaretest meist unterschätzt. Dabei ist er beim Komponententest oftmals die trei-bende 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

*Änderungen vorbehalten

Termine* 2 Tage

11.–12.10.12 Berlin

http://www.diazhilterscheid.de/de/kurse.php?id=326&m=ar_10&a=35


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 today’s 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 today’s software teams With increased focus on agility, offshore development and glo-balization of work, the composition of today’s 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 team’s ability to respond to changes.

Leading Software Teams, The Agile Contextby Nishant Pandey

Figure 1: Changing composition of today’s software team


Leveraging strengths of software teamsA good leader can use the new team’s structure to gain competi-tive 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 cross-functional 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 team’s effectiveness and efficiency. Maintaining specificity of com-mon 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 today’s leaders to ensure an open and collabora-tive 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 catalystsMotivation, trust and communication are three very important ingredients that act as catalysts for effective leadership of soft-ware organizations.

Effective leaders are able to motivate their teams to build excel-lent 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 posi-tive 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 today’s multicultural and geographically dispersed teams. This factor might be of very high importance, specifically in case of offshore teams.

Motivating software professionalsThe concept of participative management can be beneficial for managing software professionals. Sharing decision-making re-sponsibility with software professionals on your team can impact the team’s motivation. The following diagram illustrates possibly useful techniques to motivate software teams and could be im-plemented in methods depending upon the organization’s 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 environmentIn 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 & Com-

munication


Key parameters that underlie the concept of trust include compe-tence, consistency, loyalty, and integrity. These underlying param-eters often limit or boost a leader’s ability to gain useful knowl-edge, support and commitment from the team to be able to solve real-world problems. The effectiveness of a leader’s 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 keyGood interpersonal and organizational communication is very important from the perspectives of control, direction and motiva-tion of teams. It is important that leaders inculcate good practices relating to this very important attribute in their team’s 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 effec-tive communication that might exist in their teams. Cross-cultural factors are also important in today’s globalized work setting and diverse workforce. If due attention is not paid to the cultural as-pect, 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 edgeSoftware development is a process that benefits from utilizing an employee’s 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

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 team’s 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

Nishant Pandeyworks with Capgemini and is based in Toronto, Canada. He manages Busi-ness Analysis and Testing engagements for clients in the Financial Services domain. Nishant is a certi-fied PMP® and holds the Advanced Level Certificate in Test Management from

ISTQB®. Nishant’s 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.

> About the author

Figu

re 4

: Dim

ensio

ns in

fluen

cing

the c

once

pt o

f tru

st


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 build-ing 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 Coffee’Cake.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 min-utes 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 Alex’s 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 thor-oughly 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 ex-periences with Chris, an experienced Scrum Coach at Coffee’Cake.com. She told her that she did a real good job as she did every-thing 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 team’s mind and asked Chris for advice. The coach recommended discuss-ing Scrum meetings and their purpose in the next retrospective.

How to navigate through Scrum – a guide for Scrum Mastersby Katja Roth & Jane Trümner


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., draw-ing 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 dur-ing 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 qual-ity, working better together as a team, and being hap-pier at work. Once conduct-ing a retrospective without

preparation, Alex learned the hard way that preparing a retrospec-tive 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 team’s 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 that’s 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 didn’t know what he had done and how to finish the story. So the story wasn’t 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 didn’t agree. For him being an expert means being really fast and oth-ers 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. That’s 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


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 pair-working. That was a good topic for her Scrum Master meeting.

Solution finding with managementAs discussed in the retrospective Alex had to talk to the qual-ity 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 Coffee’Cake.com that spe-cialists 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 Coffee’Cake.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 availa-ble when needed. This would be a risk to the team commitment. Alex was thinking about an offer to Sue in order to keep Rob-ert 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 col-leagues 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 Alex’s 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 develop-ers 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 prob-lem. 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 people’s atti-tude, 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 asyn-chronous 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 sup-port 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 miss-ing 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 Mike’s 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 Mike’s develop-ment 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 Alex’s support.

Scrum Master – the lonesome cowboy?The Scrum framework is easy and the routines are defined – some-how. For a Scrum Master, however, every day is different depend-ing of the problems the team is dealing with. Impediments range


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 team’s 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 ex-change 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 feed-back 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.

Katja Rothis agile coach with many years of experience in ag-ile practices like Scrum and Kanban. As Certified Scrum Master and Certified Scrum Product Owner she helps companies to imple-ment agile ways of working. Katja started her career 15 years ago as a software de-

veloper and has deep knowledge in agile development practices like XP and feature driven development. After a short period as a traditional project manager, she to-day 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 knowl-edge with other people.

Jane Trümnerhas over 10 years experi-ence in product develop-ment in telecommunications and Internet companies. She worked nationally and internationally as business analyst, product manager, product owner and scrum master. In her current posi-tion 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 Trümner has a degree in Business Administration and is Certified Scrum Master and Certified Scrum Product Owner.

> About the author

A unique opportunity to share your experience with Test Experts from all around the world.

40 International Speakers,4 Tutorials, 4 Keynotes, 4 TracksWebinars, 1000m2 Exhibition, Debates, Networking, Gala Dinner

MadridJUNE 4th-7th

Register with a special 20% discount AGREC20 at www.expoqa.com/enParticipate in the raffle of a free ticket to expo:QA’12Or get your special 30% Professional Tester discount at www.expoqa.com/PT

The best International Conferenceon Software Testing...under the sun!

Endorsed bySponsors

PROGRAMME ON THE BACK

C

M

Y

CM

MY

CY

CMY

K

expoQA-pagina1-Professional TestPage 1 16/4/12 12:06:08


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 organi-zation, 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 impedi-ments requires support from management.

Furthermore, much 21st century work is fundamentally dif-ferent 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 solu-tions 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, mecha-nistic 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, in-cluding 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. We’d love to hear your voice and your ex-perience. Help move the conversation forward by joining our LinkedIn Group2 and on twitter with hashtag #stoos.

Let’s start the transformation before it’s too late.”

Radical ManagementSM (described by Stephen Denning in his book The Leader’s 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 produc-

1 http://www.scrum-breakfast.com/2012/01/invitation-to-cool-event-later-known-as.html

2 http://linkd.in/stoosnetwork

Radical ManagementSM – A Paradigm Shift for the 21st Centuryby Simon Roberts & Birgit Panzram


tive, more innovative and more satisfying, both for the people inside the organization as well as for the organization’s customers.

Shift 1. One company goal: delighting customersCustomers are gaining more and more power. Organizations com-peting 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 don’t 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 organization’s mission statement or defining it as a goal for CEOs isn’t enough. This shift needs to be implemented at all operational levels.

Shift 2. Managers: from controller to enablerTraditional management approaches aiming at consistently per-forming with high efficiency are no longer sufficient. It is not the bosses anymore who know best how work needs to be performed. In today’s 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,

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 bureau-cracy to dynamic linkingHierarchical bureaucracy is needed when scalabil-ity – 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 today’s 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.

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 implement-ing agile methods such as Scrum or Kanban.

This resonates with Dee Hock’s chaordic systems which he de-scribed as early as 1993 (Hock, 1995) for systems which are both chaotic and ordered: “By Chaord, I mean any self–organizing, 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 valuesThere 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 cul-ture of customer delight, incorporating transparency, continuous improvement and trust.

Shift 5. Communication: from command to conversationFinally, communication needs to move from command to coop-eration and conversation for joint problem solving and for the generation of new insights.

From a single economic value to values which enable

One company goal: delighting customers

Role of managers: from controller to enabler

Communications: from commandto cooperation andconversation

Coordination: from hierarchical bureaucracy to dynamic linking


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 transpar-ently 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.

ConclusionRadical 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 prod-ucts that they believe in, and are as a result more produc-tive 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.

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 BibliographyBogsnes, 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 Leader’s Guide to Radical Management: Re-inventing the Workplace for the 21st Century, San Francisco: Jossey-Bass.

Drucker, P. (1973), Management: Tasks, Responsibilities, Prac-tices, 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.

Birgit PanzramMBA is an agile and busi-ness coach, an experienced manager and has a back-ground in software devel-opment. 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 in-

troduced 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 Certi-fied Scrum Professional. She can be contacted at [email protected].

Simon RobertsMBA is founder and CEO of ScrumCenter GmbH, an agile coach and a Certified Scrum Trainer who special-izes in helping organizations introduce and achieve sus-tainable success with agile methods. He is currently focussed on helping execu-tives 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 leader-ship and management. He can be contacted at [email protected].

> About the author

C

M

Y

CM

MY

CY

CMY

K

Sin titulo-1.pdf 23/4/12 10:21:05


Core to Agile is the Agile Manifesto. The first value is “Individuals and interaction over process and tools”. That is not to say that pro-cess 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 manage-ment, 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 to-gether to accomplish desired goals and objectives using available resources efficiently and effectively. Management comprises plan-ning, 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 motiva-tion is much stronger than extrinsic motivation. David McClelland identified three motivators that drive our behavior, regardless of our gender, age or culture:

1. Achievement

2. Affiliation

3. Power

Within an agile team you want the majority of motivational influ-ence to come from achievement and affiliation rather than the behavior driven by power.

Leadership and not management in an Agile teamby Leanne Howard


Achievers have a strong need to accomplish challenging goals and receive regular feedback on their progress and achievements; Af-filiation 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, you’re 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 or-ders 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 sup-port 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 don’t have clear goals, they muddle through their day. They can’t be as productive if they have no idea what they’re working for, or what their work means. They also can’t prioritize their workload effectively, meaning that projects and tasks potentially get com-pleted in the wrong order.

I would much rather work for a leader who inspires me and oth-ers 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 – let’s 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. They’ll openly detest it! However, going to the opposite extreme (with a totally hand-offs management style) isn’t 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 you’re 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 they’ll 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.


Leanne Howardis an Agile Principal Con-sultant with Planit. Over the past 20 years Leanne has worked in the IT soft-ware testing industry across multiple programs and pro-jects including those using Agile. She is a specialist in the implementation of prac-tical testing methods with a

strong focus on client satisfaction. She enjoys sharing her knowledge through mentoring and coaching oth-ers advocating continuous learning, and is active in the promotion of the testing profession through her role at Planit and involvement with relevant association bodies.

> About the author

License ISTQB and IREB Training Materials!

For pricing information, and all other product licensing re-quests, please contact us either by phone or e-mail.

Phone: +49 (0)30 74 76 28-0 E-mail: [email protected]

Díaz & Hilterscheid creates and shares ISTQB and IREB train-ing material that provides the resources you need to quickly and successfully offer a comprehensive training program preparing students for certifi cation.

Save money, and save time by quickly and easily incorpo-rating 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)!


About risk based testingTesting 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 projectsOne 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 ‘exhaus-tive 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 devel-opment and testing activities are by definition limited to a pre-defined timeframe. Risk based testing provides an ex-cellent answer to the problem ‘how much testing’ by ensur-ing 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.

2. Just like Planning Poker, Risk Poker is a team-based activity and decisions are made by achieving consensus.

3. In the Scrum process, Risk Poker can be easily combined with Planning Poker in the Planning meeting. They comple-ment 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-and-answer game about product risks will be input for estimat-ing the testing effort in Planning Poker.

4. User stories are very suitable entities to be used as ‘risk items’ in a product risk analysis. In agile projects, risk iden-tification comes down to identifying user stories.

5. Agile is all about ‘working software’, Risk Poker is a light-weight approach to achieve the most appropriate balance between sufficient quality and acceptable risk – within the available constraints in time and resources.

Risk Poker: Risk based testing in agile projectsby Jurian van de Laar


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 impor-tance (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 repre-sent 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 simultane-ously 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 esti-mators 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 team’s 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 fol-lowing its own rules.

Applying the risk based approachWhen 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 test-ing 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 accept-ance test with only exploratory testing.

■ Likelihood and impact are both red: Code reviews, unit test with multiple condition coverage (e.g. 80%) and accept-ance 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 analysisThere are some differences with Risk Poker compared to a ‘normal’ risk assessment. For instance, the PO will represent all stakehold-ers 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.


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.

AlternativeThe 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.

AcknowledgementsThis article is based on the white paper ‘Risk Poker explained’ (2012), written by my colleague Jurriën Seubers, with contribu-tions 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.

Jurian van de Laaris 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 con-sultant. He consulted vari-ous 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 Profes-sional 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 Nether-lands. 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 Test-ing Qualifications Board (BNTQB).

> About the author

Follow us @ar_mag


Masthead

EDITORDíaz & HilterscheidUnternehmensberatung GmbHKurfürstendamm 17910707 Berlin, Germany

Phone: +49 (0)30 74 76 28-0 Fax: +49 (0)30 74 76 28-99 E-Mail: [email protected]

Díaz & Hilterscheid is a member of “Verband der Zeitschriften-verleger Berlin-Brandenburg e.V.”

EDITORIALJosé Díaz

ISSN 2191-1320

LAYOUT & DESIGNDíaz & Hilterscheid

WEBSITEwww.agilerecord.com

ARTICLES & [email protected]

[email protected]

PRICEonline version: free of charge

In all publications Díaz & 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 Díaz & Hilterscheid Unternehmensberatung GmbH remains the author’s property. The duplica-tion or use of such graphics or texts in other electronic or printed media is not permitted without the express consent of Díaz & 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.

Agile Testing Days 5CaseMaker SaaS 21CAT – Certified Agile Tester 3CAT – Certified Agile Tester in Orlando 17CKC Seminars 13Díaz & Hilterscheid 55expo:QA 43IREB 23iSQI 30

Knowledge Transfer 25nexoQA 47Online Training 18Software Quality Lab 2SWE Guild 32Testen für Entwickler 35Testing Solutions Group 27

Index Of Advertisers

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

Training with a View

Kurfü

rste

ndam

m, B

erlin

© K

atrin

Sch

ülke

* subject to modifi cationsall prices plus VAT

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

Dates * Course Language Place Price22.06.12–22.06.12 Anforderungsmanagement German Berlin 499,-23.07.12–27.07.12 CAT – Certifi ed Agile Tester German München/Karlsruhe 2100,-11.06.12–15.06.12 CAT – Certifi ed Agile Tester English Stockholm/Sweden 2100,-02.07.12–06.07.12 CAT – Certifi ed Agile Tester English Orlando/USA 2100,-04.06.12–05.06.12 HP Quality Center German Berlin 998,-20.08.12–21.08.12 HP Quality Center German Berlin 998,-06.06.12–08.06.12 IREB® Certifi ed Professional for Requirements Engineering – Foundation Level German Berlin 1400,-19.06.12–21.06.12 IREB® Certifi ed Professional for Requirements Engineering – Foundation Level English Oslo/Norway 1600,-29.05.12–31.05.12 ISTQB® Certifi ed Tester Foundation Level – Kompaktkurs German Nürnberg 1495,-16.07.12–18.07.12 ISTQB® Certifi ed Tester Foundation Level – Kompaktkurs German München/Karlsruhe 1495,-23.07.12–25.07.12 ISTQB® Certifi ed Tester Foundation Level – Kompaktkurs German Berlin 1495,-18.06.12–21.06.12 ISTQB® Certifi ed Tester Foundation Level German Frankfurt 1800,-18.06.12–21.06.12 ISTQB® Certifi ed Tester Foundation Level German Berlin 1800,-30.07.12–02.08.12 ISTQB® Certifi ed Tester Foundation Level German Frankfurt 1800,-07.05.12–11.05.12 ISTQB® Certifi ed Tester Advanced Level – Technical Test Analyst German Mödling/Austria 2100,-11.06.12–15.06.12 ISTQB® Certifi ed Tester Advanced Level – Technical Test Analyst German Berlin 2100,-09.07.12–13.07.12 ISTQB® Certifi ed Tester Advanced Level – Technical Test Analyst German Frankfurt/Stuttgart 2100,-07.05.12–11.05.12 ISTQB® Certifi ed Tester Advanced Level – Test Analyst German Köln 2100,-30.07.12–03.08.12 ISTQB® Certifi ed Tester Advanced Level – Test Analyst German Berlin 2100,-07.05.12–11.05.12 ISTQB® Certifi ed Tester Advanced Level – Test Manager German Mödling/Austria 2100,-18.06.12–22.06.12 ISTQB® Certifi ed Tester Advanced Level – Test Manager German München 2100,-25.06.12–29.06.12 ISTQB® Certifi ed Tester Advanced Level – Test Manager German Berlin 2100,-

http://www.diazhilterscheid.de/en/training.php?m=ar_10&a=55

agilerecord magzine

Documents