issue 12 - Agile Record

The Magazine for Agile Developers and Agile Testers

Collaboration and Building Teams www.agilerecord.com free digital version

November 2012

made in Germany

ISSN 2191-1320

issue 12

Pragmatic, Soft Skills Focused, Industry Supported

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

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

Book your training with Díaz & Hilterscheid! Open seminars:

© Sergejy Galushko – Fotolia.com

03.12.12–07.12.12, Köln, Germany 28.01.13–01.02.13, München/Stuttgart, Germany 11.02.13–15.02.13, Berlin, Germany 18.03.13–22.03.13, Berlin, Germany 22.04.13–26.04.13, Frankfurt/Karlsruhe

14.01.13–18.01.13, Amsterdam, The Netherlands 11.03.13–15.03.13, Helsinki, Finland 08.04.13–12.04.13, Stockholm, Sweden 15.04.13–19.04.13, Oslo, Norway

(German tutor and German exam)

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] page 2

Agile Record – www.agilerecord.com

Editorial

Dear Readers, We are facing a lot of changes in the industry and many of them have to do with Agile methodologies. Collaboration, team building and also group work are quite big these days. What problems do we face in building teams, working as a group and collaborating? How do I say nicely to my colleague: “Hey, you are a lazy ass!!!” without being rude? Have a look at the articles and you will find some hints on how to build teams, and how collaborative and group work can be achieved. We have seen that a lot of training is based on soft skills, but not really aimed at Agile teams. This is something the market needs to address. The Agile Manifesto starts with individuals and the whole Agile philosophy is based on these individuals. It is time to wake up and help teams to work collaboratively, communicate appropriately and be a cohesive whole, even in a non-Agile environment! At the Agile Testing Days we did present a new training program for group work which has been designed and developed for Agile teams. Feedback was great and we are now preparing to run the first pilot. If you missed the Agile Testing Days, then make sure that you don’t miss the Agile Dev Practices, a new conference for the Agile community. We have a great program – take a look at www.agiledevpractices.com The year is coming slowly to its close and we are faced with a lot of surprises next year. This year was filled with many, many challenges which we really sorted out as a team. Some of them were “easy”, some of them were, or still are, tough. That’s life. We wish you and your family all the best for 2013, especially health, happiness and a lot of love. Enjoy reading

José Díaz

page 1


Contents Editorial 1 Editorial Board 3 Collaboration and Team Building dispersed over the locations and time zones 4 by Mariya Vankovych Software development is all about people 7 by Huib Schoots Collaboration in large-scale and multi-site projects – size does matter 9 by Attila Fekete Agile Chartering – Critical to a Proper Beginning 13 by Robert Galen Investing in team relations 18 by Eric Jimmink Bug Bash – a Collaboration Episode 21 by Trinadh Kumar Bonam and Ramu A. Building a culture of collaboration and teamwork 27 by Nishant Pandey Distributed Agile: The Power of Collaborative Spirit 30 by Raja Bavani Managing Agile Results at Several Levels of Organization 32 by Kai and Tom Gilb Stealth Collaboration: How to Go Agile Without Management Support 36 by Mark Kilby The psychology of work groups 37 by Johannes Staffans Communicate with impact 39 by Vicky De Roeck Secret Recipe for Building High-Performance Agile Teams 41 by Rathinakumar Balasubramanian Characteristics of an Agile Scrum Team 43 by Rashmi Wadhawan Masthead 45 Picture Credits 45 Index Of Advertisers 45

page 2


Editorial Board

David Alfaro

Josh Anderson

Plamen Balkanski

Matt Block

Jennifer Bleen

Andreas Ebbert-Karroum

Pat Guariglia

Ciaran Kennedy

Roy Maines

Steve Rogalsky

Dave Rooney

Steve Smith

Zuzanna Sochova

Declan Whelan

Read their biographies at www.agilerecord.com/editorial_board.php

page 3


Collaboration and Team Building dispersed over the locations and time zones by Mariya Vankovych

In Wikipedia we find the following definition of the Agile development process: Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

As a result, there are a number of problems that commonly arise in teams due to interpersonal conflicts:

This is the definition of highly managed “pure” Agile development process that is carried out by the team with motivated, selforganized, and experienced members. Not every company can set up this type of the Agile, so based on the possibilities and needs, companies adopt modified Agile development processes. Often we see that Agile development process is adopted for teams that are dispersed over the locations and time zones.

■■ Difficulty in closing a discussion or action;

Let us take a look on the Agile process for a dispersed team across locations and time zones that is working on a highly controlled product such as medical, government, or military where processes, tools, and end documentation are strictly controlled and required. The main components of any form of the process are: ■■ People ■■ Communication ■■ Collaboration and coordination ■■ Tools ■■ Management Let us look more in detail at each of the components of the Agile process. People The team consists of individuals and correct combination of expertise and personal characteristics ensures good teamwork. When building a team we should understand the following: ■■ People differ from one another (we are all fundamentally different); ■■ Attempting to change a person will not be successful; page 4

■■ Domination of certain members in the discussions; ■■ Difficulty in making a final decision;

■■ Too detailed analysis or not enough detail; ■■ Lack of respect between team members and others. For example, it is very important to find a team member who is an expert, but if he/she has no respect for other team members and is not willing to share his/her knowledge or cooperate – the team will not benefit having him/her in. It is more important to build a team of individuals who are open minded, have respect for each other, understand the importance of having all different roles in team, can set direction for a discussion and stick to it, and be willing to help each other if the need arises. Knowledge and expertise can be gained over time and through training and everyday work but team spirit cannot. Communication In the case of the centralized team, communication is conducted face-to-face and at the same time. But what should be done in the case of a team that is dispersed across time zones? How to make the team survive and work efficiently? In the case of overlapping working hours, scrum meetings should be moved to those hours, so everyone can speak up at least once per day. However, we still need memos, emails, and documents, although there is no need for e-signatures or formality. Ideas, questions, changes, and design decisions, that have been communicated should be located in single place that everyone can access so they can be referenced at a later date or by someone who was missing from the meeting. It is very important to have generally agreed communication channels that allow information sharing between all members, not oneto-one, e.g. bug tracking system stories with a comments thread regarding design, questions, and answers. Very often email is used


for communication. It is a very valuable tool but in my experience, it has also a number of drawbacks: ■■ If a list of people needs to be included, someone will definitely be left out; ■■ It is hard to find information in some very old emails, even with the help of search functionality available in all mail agents; ■■ It is hard to track the changes throughout the email thread; ■■ In case of using mail groups it is important to nurture the filling of responsibility across the team. People very often ignore indirect question or requests and wait when someone else from the group will take care of the request instead of taking action as soon as possible; Always set up the communication channel and make sure that all team members understand the purpose of using it. If not – be prepared that valued information will be constantly missed by someone. Collaboration and coordination It is one thing to build a good team, another to correctly manage it. Teams are made of representatives from different roles and, to achieve its objectives, all members need to work in a very organized fashion. If particular role only exist in one location, we face the risk that the person in the required role could be out of the office (not yet on site, or on a national holiday). Similar issue can arise when we have only one representative of the role in the team. It ends up in big delays in clarifications, environments set up, tasks completion, builds deployment, verification, and so on. We can avoid these scenarios by a) Having a representative for each role in all locations – unfortunately this is quite costly and there is not always the need to have so many people in the team. b) Having a team of people able to pick up any role at any time – again this is hard to achieve, as such people’s expertise needs to be very high. c) Having a volunteer who can stay late or move their working hours to have a bigger overlap with other locations, or finding a person who can do the basic support tasks in case of emergency. d) Having a highly managed process, collaboration, and a feeling of responsibility – managed handovers. If team A, which includes developers, prepares recent build and deploys it to the test environment (making thorough smoke test) and at the end of the working day has a scrum meeting with team B explaining all the changes made in the build, then team B can spend their working day verifying the build, logging issues, making the notes. At the end of team B working day they prepare report of what was done and what issues or concerns were raised and then send it to the team A. So when team A comes on site next morning they are well aware what was done yesterday and on what they should work today. And so forth. This approach should be well managed and rely on responsibility of each team , as in case team A leave nonfunctional build to team B – one team B working day will be

page 5

lost. On the other hand this approach can be very valuable as in the end we receive continuous development process, almost 16-hour working day. Tools Correct selection of tools to facilitate the team’s work and prevent obstacles or additional tasks for team members is very important. Tools and the process of using those tools should be flexible and if required, it should be possible to change the process, or how the tool is used in the development process, or even to substitute one tool for another. If a team member cannot complete the tasks using the tool on his/her own and constantly ask for assistance or approval of someone else – then the decision to make a change should be taken. Also, nowadays there is a wide range of online tools, planning boards, and other tools that facilitates the work of dispersed teams in the Agile development process. It is very important to find the most suitable tool for your team and promote its use throughout the team. All changes are always treated with skepticism, but it is the responsibility of the leader to be persistent and to convey to the team the value of using the tools. Management Management should be open to complaints, new ideas, and changes and be very careful how and what they reply to their team. Once I received the following reply to my improvement suggestion email from my colleague “It will never change here. Just forget and get used”– a very good example of demotivated team reaction. Complaints and improvements ideas indicate that a team is getting mature and already has grown from the existing process. Having no complaints of any kind doesn’t indicate that there are no issues in a team and the process; it can mean that people do not want to fight for any change and they do not care anymore. The worst situation is when people lost the hope of any improvement. The worst scenario If an Agile team dispersed across time zones is poorly, we can end up with: ■■ Low levels of communication. Memos and emails are not used for communicating decisions, and everything is based on person to person communication. Important decisions, and information are missed by team members, so work is done on the basis of outdated information and has to be redone at a later date. ■■ Bug tracking system is not used fully by all members. Decisions and changes are not tracked there, and statuses are not changed. No one knows what should be done and what the current state is on the issue; ■■ There is no unique place where sprint stories are located. Some of them are stored in the Backlog and some in defect tracking system tickets. It is hard to find information regarding the sprints; requirements are missed during implementation and verification phases; ■■ High level of delays due to the time zone difference. Roles are not equally dispersed over the locations and time zones. If there are build crashes or issues with servers, the issue blocks any further work unless the next team comes on site;


■■ People are demotivated and do not believe in change. They do not complain but just go with the flow, so management does not have a clear view of the team’s health; ■■ Tools that are adopted for the projects do not facilitate team working but are treated by the team as obstacles and just add additional tasks to their workload. Conclusions Nowadays in highly globalized world when we rarely see the team that is located in one place, we should take time to set up processes for the agile and thoroughly build the team. We cannot any more rely that team will be working overtime just to catch with the deadline. It is still possible and for few days acceptable, but Software development industry is no more the industry that employs only young people. Most of the team members have their families and kids that need and require time spent with them. Everyone’s time is valuable, so not to waste it, we should employ correct processes that work for the team. Our mutual success depends on this.

page 6

> about the author Mariya Vankovych Mariya holds a Master degree in Applied Linguistics from Lviv Polytechnic National University, Lvov, Ukraine. Over 6 years ago she decided to start her software testing career at N-ix ltd., Ukraine. Over 5 years ago she relocated to the Prague, Czech Republic where she is currently working at Parexel International and is specializing in web testing. She actively follows other testers’ blogs and tweets and can be followed on her own blog www.quality-and-life.com.


Column Software development is all about people by Huib Schoots

The theme of this agile record is an interesting one. To me collaboration and great teams are the most important aspects of working. Agile or non-agile, collaborating makes things easier and often more fun! Team building is improving the performance of a team. Interesting stuff, but how does this work? How can we make successful teams and make them work collaboratively? I have read a lot about this topic and I have developed my own opinion about it as well. To me technical skills or knowledge do not matter in building great teams. Collaboration does! But how do you make teams collaborate better? Steve Jobs In Jonah Lehrer’s book “Imagine, how creativity works” the author explains how collaboration helped Pixar. When Steve Jobs worked at Pixar he needed people to collaborate more. Pixar wanted the computer guys to work closely together with the animators. So Steve Jobs decided to put everybody in the same building. But he took this even further: he insisted that there would be only one group of bathrooms for the whole studio. He forced people to run into each other, even if it was in the bathrooms. Jobs needed people to mix, he knew that mixing skills makes better movies and the natural tendency is to stay isolated and only talk to people that are just like you. And it worked! The result was instant. The communication improved and with that the collaboration became much better. Daniel Pink Is his book “Drive” management guru Daniel Pink describes three success factors for teams. He mentions: autonomy, purpose and mastery. Autonomy gives the team the freedom and the tools to do what they need to do. Purpose helps the team feel that they are making a difference and they are important. This will feed their motivation and dedication. And last but not least mastery, the will of the team to be really good at what they do. If you have the will to excel, your chances of succeeding increase. Challenge, passion and room to excel People who want to excel need two important things: a challenge and passion. Vineet Nayar says in his article “The Key Ingredients of a Successful Team” (source: http://blogs.hbr.org/hbr/ nayar/2012/06/three-things-that-drive-teams.html) that it is about the journey, not the end result. When teams face huge challenges, finding solutions becomes exciting, sometimes even obsessive. The passion drives the team to go on, infects others and works as a snowball to get the team to the next level. The last essential page 7

characteristic for successful teams is room to experiment: real innovation and improvement comes from trying new things. These factors resemble the ones described by Daniel Pink: autonomy makes room to excel, passion feeds mastery and a challenge gives purpose. My view on collaboration and building teams Teams working together are most important in achieving goals. I remember when Feyenoord, my favorite soccer team in the Netherlands, won the UEFA cup in 2002 with a team that wasn’t the best in the UEFA cup competition. They had just average players compared to other teams in Europe. But they were a real team and the whole team was dedicated and committed to win. Feyenoord won, not because of the individual skills, but because they were a team, the collaboration and dedication made the difference. But I dare to take this even further: give me a team of people that are really willing to make something work and we will do the job, any job! September 10th I visited a talk about specification by example by Gojko Adzic at the Federation of Agile Testers in the Netherlands (FAT-NL) and during the drinks we discussed what is needed to excel in agile. I stated that DEWT (11 fellow software testers who get together regularly in a peer workshop to learn from each other) would be able to build let’s say a salary system within reasonable timelines if we were asked to. Probably just a couple of us can code a bit but still I believe we will make it work. And if needed we will hire a real developer to do the really complicated stuff. Why do I believe that we will pull this off? Because we are dedicated, perseverant, willing to learn, willing to help each other and also able to work together. We know each other quite well and we will give each other room to make mistakes. That will make the perfect team! The dedication and perseverance will help us make up for the lack of coding skills and knowledge. We will learn fast and make it work. Successful teams If you google ‘successful teams’ or ‘building teams’ you will find many lists with team characteristics that make a team successful. The lists differ quite a bit and that is interesting. This might have something to do with the context in which the teams work. Three aspects are in every list: clear team goals, clear communication and defined responsibilities. Some others popup often but not in


every list, like balanced participation, trust, participative leadership, effective decision making and helping each other. What I miss in a lot of these lists is passion and perseverance. During the “all things digital conference” in 2007 Steve Jobs says to be successful you need to have passion for what you do. To be successful is often very hard and to sustain that over a period of time, you really have to work hard and love what you do to persevere. Normal people, he says, give up. Successful people persevere. Building teams It takes time to build successful teams. At CAST Test Coach Camp in San Jose last summer Michael Larsen (link: http://www.mkltesthead.com/2012/07/day-2-of-test-coach-camp-live-blog.html) introduced the Tuckman stages of team development to me which were published in 1965: Forming, Storming, Norming and Performing. Every team has to go through these stages, which takes time and in the end only a few reach the performance stage. In the forming stage (why are we here?) the team forms itself but exists of individual members getting to know each other and finding their places. In the storming stage (can we work together?) the members have to find ways to work together. Conflicts between the members arise about things like the mission and the approach. In the norming stage (how will we work together?) issues get resolved. All members take the responsibility and have the ambition to work for success. In the performing stage (how can we work smarter?) the team becomes a high-performing team. They are accomplishing the work smoothly and effectively without inappropriate conflict or the need for external supervision. In 1977 Tuckman added an extra stage: adjourning, in which the project ends and the group is abandoned.

High-performance teams? So how many high-performance teams are there anyway? According to Steve Demming, high-performance teams constitute only 2% of all teams in the workplace. I think there could be much more if management would understand that the biggest challenge of software development is not about technique but about humans! Building successful teams is all about people! Teams will succeed if the people trust each other, are persistent and have passion and the willingness to help each other. This will lead to great collaboration. Once you have built a great team, their technical skills or knowledge do not matter that much anymore…

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

www.sweguild.com

page 8


Collaboration in largescale and multi-site projects – size does matter by Attila Fekete

Although it is often overlooked, efficient and proper collaboration is a critical factor. Without it, it is impossible, or might become more expensive, to reach the business goals of your company. Because you exchange information while collaborating with others, you cannot have proper collaboration without enabling effective, regular, and timely communication. ‘Timely’ often means an immediate ad-hoc communication with the other party. As human can hardly type as fast as speak, an instant verbal exchange with your colleague is often the most efficient way to collaborate. Taking all this into consideration, it is preferable to have all those people with whom you need to collaborate often within easy reach. Easy reach does not necessarily mean sharing the same office space. As studies show, significant background noise caused by high levels of communication in a big shared office area could easily lead to increased numbers of faults being introduced into different phases of the project. Because you do not always have everyone located near to each other, there is simply not the option to have a face-to-face chat. Thus you need to look for other alternatives. When you design your collaboration network, the timing and channels used are not the only factors you need to consider. You also need to consider who needs to interact during the course of your project. Just to list a few cases, collaboration can be meant in many different ways: ■■ between team members ■■ between teams ■■ between people involved in similar activities (e.g. system test engineers) ■■ between the team and the customer representative Just as with anything else, doing something on a smaller scale is much easier than doing it in a large-scale project. Size does matter and many things differ a great deal compared with smaller projects. Collaboration between team members who share the same office space is not affected significantly by the size of the organization. However, if it is not managed properly, other areas might easily suffer from the difficulties brought on by a growth in size. As project size grows, difficulties around collaboration will page 9

show up from time to time and it might easily become the biggest risk factor in the project. Now let us imagine our most feared nightmare – a real beast, a large-scale, multi-site project with the following attributes: ■■ Large-scale project with 450 project members ■■ Working at four different sites ■■ Located in different countries with different cultural backgrounds ■■ Located in different time zones ■■ Some of the activities are outsourced ■■ Some people have no access to the same data, services, and infrastructure Of course, it never starts like this. However, as a result of project scale-ups and outsourcing activities your project might reach this state. Now let us examine the different factors one by one. The AWARENESS factor From the perspective of collaboration, it is essential that people know who they need to collaborate with. During scale-ups, reorganizations, or outsourcing, communication channels might easily get broken or become ineffective. This is because, in such cases, people might change roles, take on new roles, or new levels might even be introduced in your organizational hierarchy. Certain well-known people might become a proxy and become involved in most of the communications, while others might become invisible. All these elements could easily lead to inefficient collaboration. As a consequence, collaboration and your project will suffer. In a large and continuously changing organization, this is an everyday problem. So you must not forget about it even for a little while. You must keep all these elements in mind while designing your collaboration network. There are few steps to be implemented in order to lower the risks: ■■ Minimize dependencies between sites in order to minimize the inter-site communication required


■■ Minimize the number of people involved in inter-site collaboration. As it is easier to keep a contact network up to date if the group comprises a limited number of people ■■ If even the local organization is large, apply the above concept to the local site ■■ Publish a list of contact persons The WHO factor It is clear that members of an Agile team should collaborate with each other in order to deliver a quality product on time. Also, the advantages of having feedback from either the customer or its representative are well known. But there are other, non-obvious, communication channels and synergies which are worth exploiting. Let us take an example. Certain teams also perform some kind of system test activity. In Agile, the whole team is sitting in a shared office area in order to enable easy collaboration between team members. This is essential for them so they can produce proper quality with lower communication and collaboration costs. However, people who focus on a certain area, such as performing system test activities, will also need to collaborate. Even though they are working on different features, so will face different problems from a features perspective, they are still using the same tools and working in the same environment. This means they may well face similar issues. Thus their experiences will be valuable for the others in the same interest group. So, forming them into a virtual team and arranging stand-ups, or, if it is not possible, video conferences, is essential from the perspective of project success. If the members of a virtual team are located at different sites, you must ensure that other options are also in place for collaboration. This is because face-to-face conversation is not an option in this case and a weekly video conference might not be sufficient. Options for collaboration in such cases could be discussion groups, wikis, and information sharing through mail distribution lists. The HOW factor As we all know, the most efficient way of communication is the personal face-to-face discussion. However, if you need to collaborate with someone at a different location, or at the same site but not located near to you, then you need to have a second best option in place. Otherwise you will soon face issues. When looking for other alternatives, you need to keep in mind certain things. Phone conferences or phone calls might be a second option. However, you need to pay attention to ensure you find a solution with good enough quality. This is because the other party might have a different mother tongue and might not be fluent enough in the language. If you add bad voice quality to these, your collaboration will be really troublesome. It might be inefficient or, in the worst case, could lead to misunderstandings and unforeseen negative effects on your project. In many cases, audio conferencing might be sufficient. However, video conferencing brings your inter-site collaboration to another level. It is not just fancier, but might result in more efficient collaboration because people could benefit from the advantages of non-verbal communication. If neither party is a native speaker, this could improve your collaboration to a great extent. The subject of collaboration may require other tools, such as virtual white-board solution, screen sharing, or granting access to your page 10

desktop, to list but a few. Because the listed options have different operational costs, whenever someone wants to collaborate the optimal way must be chosen, taking into account the requirements and costs. As you can see, in matters of collaboration infrastructure plays a key role as an enabler. When talking about multi-site projects, the available infrastructure is even more critical, as is its availability. Here, of course, the costs need to be considered. For example, if we install conference rooms with video conferencing capabilities it is reasonable to have a lighter-weight backup solution in place. This could be a PC client with pool HD webcams for joining the video conference. Flexibility In a large-scale project it is critical to offer a wide range of collaboration tools for your project team members. This would then give them the necessary flexibility to collaborate as required at a reasonable cost. The list of possible tools is very long, but here are a few: ■■ E-mail software ■■ Phone ■■ Audio conferencing equipment ■■ Video conferencing equipment ■■ Virtual white board solutions ■■ Desktop sharing solutions ■■ VoIP and video call software on desktop PCs ■■ Discussion groups on company website At this point, I need to emphasize that the support of ad-hoc collaboration is a must. Just as your business may change rapidly, people may often need to collaborate immediately in the most efficient way available. The WHERE factor Meeting rooms are also considered to be an enabler for collaboration. If you have a huge project, you can never have enough of them. Therefore it is critical to have the right amount of them and also to use them for the right purpose. People often call for a meeting even if they could have a corridor talk. Or they simply invite many more people than necessary, so they need a bigger room. Or they simply let people arrive unprepared, leading to a longer meeting. Fixing all these issues could easily free up facilities and, thus, fix some of the collaboration problems that are the result of not having enough free facilities. The consequences are clear. If you do not have a proper place where you can collaborate, then either you will not have efficient collaboration or you will have delays in that collaboration. It is good to consider having a wide range of options when you are planning places to collaborate. As an extra option apart from large meeting rooms, one option would be to have non-bookable, drop-in, smaller meeting rooms or even very small, one-person mini rooms. Drop-in rooms will mean you can find a free room in most cases when you need to have an unplanned meeting. Oneperson mini rooms would let you join a phone conference without disturbing others. It is also wise to furnish them with different equipment, such as conference phones, projectors, video confer-


ence equipment, etc. If you find the right balance, then facilities will rarely be an impediment. The SIZE factor When designing the collaboration network, it is important to consider the size of the audience who need to be involved. Collaboration can be ineffective if the group gathering to collaborate is too big. Of course, there is no general rule here because the desired outcome of a meeting and the purpose of the meeting must be aligned with the number of attendees. If the communication is mainly one-way, then even a hundred people could attend. However, if it is going to be a discussion-heavy meeting, then even 15-20 attendees might be too many. As project size grows, it is worth thinking about having some kind of hierarchy in the collaboration network, if necessary. A good example of this approach is the practice of the scrum of scrums meeting. Here we try to optimize communication but still have proper collaboration between a larger group of people. The same approach must be applied when a certain interest group becomes too big. The WHEN factor This is just as important as other factors. The product of your company evolves through continuous collaboration. If this does not take place at the right time, your development could easily move off the intended path for some time. The extent to which people like to collaborate is very much culture-dependent. Certain people just prefer spending a lot of time trying to work things out by themselves. Often they spend too much time before collaborating with others or simply wait for the next regular collaboration opportunity. Regular collaboration events have their purpose. However, it must be emphasized that instant collaboration should take place if required, or a temporary collaboration series could even be set up, depending on requirements. An example could be setting up a task-force team to tackle a problem which seriously affects your business. The larger your organization, the longer the delay until such issues are dealt with. Thus, you must always be proactive and emphasize timely collaboration in your organization. It is better for collaboration to be part of the company’s culture than to see collaboration issues on the findings lists of a retrospective. Top-down vs. bottom-up There is no rule. Collaboration channels could be initiated both from the higher levels of the organization or from the lower. However, the deeper your hierarchy, the more important it is to enable and promote the bottom-up approach. ‘Enable’ here does not simply mean empowering employees, but also providing them with the support they need as required. However, this very much depends on culture. Certain people are self-driven and cooperative. Others are simply less open to such initiatives, such as initiating the formation of a virtual team or setting up collaboration channels. The amount of support that needs to be given will vary, depending on this factor. Drivers should be appointed and made visible across the whole organization. You should also make it part of the company’s culture and create an environment where people dare to step up and initiate the establishment of collaboration channels if they feel the need. Of course, this does not mean that a company should wait for initiatives to come from the staff. There must be a plan but a company still needs to be open to other initiatives.

page 11

Outsourced activities In the case of outsourcing, the site where the outsourcing activities take place does not even need to be located far from your site. You outsource certain activities for purposes such as gaining flexibility in terms of headcount or lowering your costs. In such cases, your peers at the remote site might not even have the same facilities or infrastructure as you have at your own site. In such cases, collaboration, and information and knowledge sharing might be troublesome. When planning to outsource certain activities, it is important to keep in mind the collaboration and its requirements. Of course, the same rule applies here as in the case of multi-site projects – minimize dependencies and the amount of collaboration required. Try to fix as much as possible locally and only involve remote peers if it is unavoidable. Other impediments There are a lot of other impediments which you need to tackle. One example would be collaboration between sites located in different time zones. One or two hours’ difference between the local and remote site will not affect daily collaboration significantly. However, the bigger the difference, the more troublesome the collaboration can be if it is not managed properly. In this case, the best you can do is to minimize dependencies as much as you can, keeping collaboration to the minimum required. Different cultural background could also be an impediment. If you only have one site, then, in most cases, you are getting in touch with people who have a similar cultural background. However, if your project activities are spread between different sites located in different countries, then the whole situation might change. People living in another country may behave and communicate differently. They may express certain things differently or interpret certain actions differently. For example, in certain cultures people generally just try to avoid any direct conflict. As a result, they would express themselves differently if they are trying to criticize something. If you cannot interpret this correctly, then it could easily lead to misunderstandings. This is only one example of many. However, such differences could cause collaboration issues. In the case of multi-site projects, you need to consider removing such barriers and coaching people on how to collaborate with the other party who has a different cultural background. Another example is that language skills could also be an impediment if not managed properly. Even if you pay attention to training your project members, not all of them will be able to communicate fluently in a foreign language. Therefore picking the right people to involve in inter-site collaboration is essential if you are to avoid issues caused by misunderstandings. As mentioned before, providing certain collaboration tools such as video conferencing equipment and virtual white board solutions could improve the situation. Conclusion As you can see, collaboration is really hard work and requires certain skills and abilities. To achieve all this in a large, multi-site project is even more difficult. You will face new challenges compared with small-scale projects. You must be careful and should never under-estimate the relevance of proper collaboration. In order to operate an efficient collaboration network, you will need to make the benefits visible because forcing people to collaborate is not the preferred approach. You need to motivate and coach


them on how to collaborate. You need to show them how much more successful they would be through better collaboration. If you do so, then your company will soon see the benefits, too.

> about the author Attila Fekete After graduating in Information Sciences in 1998, Attila started work in the telecommunications industry. Since then he has worked as troubleshooter, test automation engineer, test coordinator, test lead and test analyst. In recent years he has focused on test process improvements and testing in Agile, large-scale (+250), multi-site projects.

page 12


Agile Chartering – Critical to a Proper Beginning by Robert Galen

I was a new coach joining an agile team who had just started a new project. I joined after a few sprints, somewhat mid-stream, as they were sprinting to deliver their first release. It was a financial firm which was upgrading a very important application in their IT portfolio. It was an eight year old application that had simply been outgrown by the firm’s fundamental and M&A driven growth. It also did not support some of their new clients in Europe and the Far East; therefore, a cosmetic and fundamental upgrade that would handle transactions for about ten new countries was also needed. The team had committed to a 12-sprint release plan and, when I arrived, they were completing sprint 4-approximately one third of the way through the project. When I joined the team, I felt rather good about the project. They were a dedicated and lively bunch of professionals who seemed on top of the project. From my perspective, they might have been a bit over-staffed for the effort, but I’d rather have too many people engaged than too few. Expectations? But quite soon I began hearing from their leadership team about their expectations for what would be delivered at the end of the release. As I started to attend daily stand-ups, review the team backlogs (there were actually four teams involved in the effort), and examined work burndown history and progress, I got a sinking feeling in the pit of my stomach. The team was nowhere near being able to deliver on the expectations of the leadership team. Let me give you a sense of where things stood:

were working hard, but apparently on the wrong things - and delivering too slowly. ■■ I realized that the team did not have a release plan of any sort. Even their current backlog did not contain all of the work which they had committed to for this project. They were sprinting along, one sprint at a time, figuring things out as they went. ■■ There was a design element (UX) to the project. The interesting thing was that the design team was looking for a complete overhaul of the application, yet the level of effort and time allotted for the project clearly did not support this. ■■ Critical team members had been included in the budget and plans, but had not yet been hired. Indeed, there was some dragging of feet around fully staffing the teams. Consequently, the current commitment was based upon quite a few nonexistent team members. What Had Happened? The root of the teams problems truly centered on their leadership team. Leaders in this organization were accustomed to pulling together estimates and making project commitments for their teams. Typically, a set of managers and directors would get together and size up a project. They would then determine the feature set, complexity, and basic level of effort. They would also determine what team sizes and skills were required for that particular project. After that, they would look at ongoing work, assume end points, and fit new work in as they envisioned old work being completed.

■■ The team was 33% of the way through the release plan, but only about 5–10% of the way through the work they had committed to from the stakeholders’ perspective. They truly did not know exactly where they stood, because there was no clear understanding of the work. And as they continued to sprint this gap seemed to be widening, not closing.

In this case, since the team and approach were ‘Agile’, the leadership team had made the estimates in sprints. So, they had done the arithmetic and determined that it would take 4 teams 12 sprints to complete the work. They pulled together a PowerPoint deck that illustrated the plan and what the business would receive as a result of the release. Then they got approval for the project budget and assigned teams to begin the work.

■■ The team was still struggling with teamwork and collaboration. There was an important architectural team in China that was not very well integrated with the rest of the teams. They

Life was good! But, from an Agile perspective, they had forgotten a few things. First, they forgot that this approach historically had not worked very well for them. They had an atrocious track record of

page 13


project success, perhaps less than 10% approaching a successful conclusion. This was one of the very reasons that they chose to “go Agile”. They hoped to improve upon this. They also forgot that Agile was indeed, at its core, a team sport. That leadership needed to include the entire team in work planning as well as the work itself. That a team needed to commit to a body of work by getting familiar with the details and not some superficial estimate by people who would not ultimately be a part of the team nor contributing to the work. Finally, they lost sight of the very essence of Agile leadership, which is to serve the team. They needed to set them up for success, while fostering an environment of self-direction and accountability, not set their teams up for failure, which they had clearly and firmly done. Don’t get me wrong. The leaders were not “bad” in this organization. Indeed, they were highly experienced, technically astute, and well intentioned. Their critical mistake was that they had moved their teams towards an Agile approach for software development, but forgot to shift their own project instantiation practices, behaviors, and patterns. It was a fundamental mistake that many organizations shifting towards agility make. It Was a Train Wreck Waiting to Happen With that entire context in place, the project was inevitably a train wreck in progress: ■■ The stakeholders were expecting something they would never receive in the allotted time and budget. ■■ The team was still forming and figuring out roles, responsibilities, work breakdowns, and who was best focused on what work. ■■ The UX team was trying to make this project their hallmark for usability and modern look and feel – over-designing everything. ■■ The development team had not even thought through the work, nor the estimated level of effort. They were just “winging it”. ■■ And the cherry on top was…the clock was ticking! This was a situation where business expectations were clearly misaligned with the team’s capabilities. So, how do you realign something like this? I’m glad you asked. Agile Project Chartering I realize it took me quite a long time to set the stage for this article. However, I think the context is useful. In a word, the organization failed to effectively charter their project. It’s that simple. They did not connect the stakeholder needs, wants, desires, and expectations with the team’s ability to deliver on those expectations. To me, that is the key driver of the chartering process - to set the stage for both “sides” of a project so that each understands the other and that there is alignment of effort towards a common and feasible goal. Agile project chartering can contain many activities and can create specific artifacts. ALL are directed towards clarity in purpose in delivery. So, what are some of the activities surrounding Agile charters and the act of chartering itself? page 14

The following come to mind: ■■ Establishing a vision and mission, while defining an overarching project goal. ■■ Clearly establishing what ultimate success “looks like”. ■■ Establishing the team: structure, budget, equipment, tooling, recruiting and hiring, workspace, skill-sets, training, etc. ■■ Establishing the scope, including product backlog(s), minimal marketable features, and minimal marketable product definitions. ■■ Performing release planning: end-to-end, from concept to deployment; including customer usage planning. ■■ Establishing how success will be measured (usage, costs, revenue, what?) ■■ Performing risk planning to include clear communication, risks and mitigations, and actions. ■■ Establishing critical constraints – Doneness Criteria, Entry Criteria, and Release Success Criteria. ■■ Developing technical architecture and design; prototyping (planned research spikes) and establishing lab infrastructure. ■■ Communicating clearly what the team can (and cannot) deliver. ■■ Then, finally, achieving business and team commitment to the project and starting… As you can see, these are all start-up related activities. I liken them to establishing a trip map or game plan for where you are going. They provide sufficient “directional clarity” so that everyone is on the same page and feels good about the feasibility and clarity of the project. Sprinting to Hell…and Hopefully Back Again I often see an anti-pattern in many Agile teams where they begin sprinting too soon. Why, perhaps because they can. Or perhaps because there is such a strong emphasis in most of the Agile methods on little to no upfront planning - towards simply diving in and sprinting. The need to begin coding and iterating is often great in many Agile teams and cultures. That is perfectly fine IF you know where you are going and IF you are aligned with your project stakeholders. But, what if you are not? As in my example, the team was sprinting towards hell. They had no chance of meeting expectations, which is certainly NOT Agile. If you are starting a new project, or find yourself misaligned with stakeholder and business expectations, I recommend pausing your sprints or iterations. Then nail down your critical unknowns and confusion factors. Next go through appropriate chartering steps to fill in the details. As a case study, let’s see how the above team recovered from their challenging situation. How Did The Team “Recover”? It is often the case that I tell a story as a means of entering a discussion, but then I do not go back to revisit the example. I want to alter that pattern here. Let’s go back and go through the steps


that this team made to realign their project and themselves with a feasible and clear goal. Admitting They Needed Help The first thing that had to happen was the team (and their leadership team) admitting that something was wrong. From my perspective, it was clear. Whenever I compared the team’s state with expectations, there was a clear gap. However, not everyone saw that gap. In fact, very few did. There was an overriding sense that the team and their leadership wanted to keep sprinting, while telling their stakeholders that everything was fine. Both sides were virtually keeping their heads in the sand. Breaking out of that cycle was the first step. The good news was that the gap was so large and so compelling that no one could really continue to ignore it. In general, it’s usually quite difficult for teams to admit that they are in trouble and need help…even in Agile teams. Eventually everyone admitted that they were in trouble and needed help. Then Pause At this point, they chose to pause and reflect. It is impossible to describe to you how hard this was for everyone. Remember, the clock was still ticking for the team and it seemed counterintuitive to stop and reassess the project (re-planning, if you will). Nonetheless, that was exactly what they needed to do. The term Sprint #0 was used to label the event and it was mostly focused on a re-plan of the release by the team. The greatest focus for the team was on establishing three things: 1. A clear view of a Minimal Marketable Product definition that could be used to align with stakeholders. 2. A clear backlog that included all work for the project and connected back to the MMP. 3. A committed release plan that crossed all four teams and included dependencies, integration, and testing. Obviously, there was resistance on the part of leadership to use any terminology that implied a ‘pause’, as it indicated that they had started the project prematurely and were now ‘wasting’ even more time. However, they ultimately agreed that it was the right language and the right move. There was resistance within the team as well. The UX folks were happily designing ‘ahead’ for the project and did not want to stop. The developers were happily coding and did not want to stop either; working on what they perceived as ‘documentation’. There was an overwhelming sense that activity and movement were better than alignment with a shared goal. This surprised me quite a bit. Focus on Release Planning The central activity surrounded what is normally called release planning. That involved writing and refining the set of stories related to the release. It also involved estimating them and ‘fitting’ sets of stories into sprints. This was an incredibly iterative process. In many cases, about 20% of the time, the team would not have a clue about a story—even though it had been “in play” for their previous commitment. In page 15

those cases, we encouraged the team to do a bit of research or prototyping, so they could estimate the story and its relationships to help others work more effectively. Call it a “mini research spike” if you will. Each day the team would spend about four hours as a group doing backlog grooming and release planning. The remaining time was spent with individuals and pairs working on their own. All work was aimed at obtaining a solid release plan and at the team understanding and being able to make a commitment to the release. Ultimately, that was their exit criteria for the Sprint #0. The stakeholders supported the content which the team could commit to for a release that met the organizational and project goals. Minimal Marketable Features/Product During grooming it became clear that the team needed a quick, concise view as to what they were expected to release. It turned out that the product backlog was too detailed and contained too much information for everyone to understand the overall intent. To help their understanding, we then asked the product owners to come up with a single sheet (PowerPoint slide) that represented the key requirements, or features, that were considered “must haves” for the release. This was called this a Minimal Marketable Product definition which contained a set of Minimal Marketable Features. Once they did this, it actually helped the team “stay on point” in terms of what was in, or out, of play for the release. The MMP was then continuously referenced and modified as required. Another interesting thing happened. As I mentioned earlier, the UX team was very rambunctious in their design creativity and innovation. This was driving the overall time/cost of the project beyond realistic bounds. It was also frustrating the other teams, particularly the developers, because they were continuously defending the level of effort to actually implement the design ideas. We finally asked the product owners and the UX team to pull together a MMF for the UX aspects of the project. In addition, we asked them to rationalize and vet this with the entire team as to whether it fitted into the project goals, vision and overall schedule targets. This worked extremely well in constraining the UX work to what truly could fit into the project’s charter and allotted time. Moving the Line…Towards Commitment Because the release plan cut across four teams, we could not commit to it unless all the teams had their work (and dependencies) identified and reconciled in the release plan. We took an approach of working left to right on a swim lane-based board for each of the sprints. We moved an indicator as we achieved commitments across all four teams for each sprint’s work - leading towards our ultimate number of sprints to deliver on the MMP goal. This visual method of indicating each sprint as we gained x-team buy-in to the work proved to be a wonderful device for all of the teams. Also, it was not unheard of for the indicator to move backwards as we uncovered an unplanned dependency that needed to move back and then reconcile forward. Negotiation and More Release Scenario Planning The first time we approached the business stakeholders with our initial release plan, they were shocked. They had assumed that the team could do so much more than what the planning now


illustrated was possible. Given this difference, there was quite a lot of emotionally charged discussion. First, they threatened to cancel the project because it did not deliver sufficient value given the time and budget. That attitude passed quickly. Then the “AHA” moment occurred when they realized that, although they might not be getting everything they wanted, the team had a thoughtful, well integrated release plan and a solid understanding of the work.

> about the author Robert Galen

Next, they sent back for a variety of scenario changes. They wanted the teams to look into options for variations to the project scope. The good news was that, by now, the team was quite adept at cross-team scenario planning and, in another week, presented back the scope versus time trade-offs for each variation. More importantly, the team and the product owners made some firm recommendations as to which direction they felt was best - not only from a business perspective, but also from a product technology perspective. Finally a Commitment This section is short. The business stakeholders finally selected a scenario and the team committed to that release plan. Then the sprinting began again. However, this time they were ALIGNED with the business AND they had a baseline release plan against which to map any changes as they made further discoveries. Arguably, they should never have started the work without this in the first place. But they did get there eventually. An Important Key to Success There is one final point to this scenario that I want to make. The product owners were central to the team’s success during this realignment. Not only did they have to work with the team on story writing and developing MMP views, but they had to defend the team from external misperceptions. In a word, they were the bridge between the realities emerging from the team’s planning activities and the needs of the stakeholders. We were lucky that we had two well respected, hardworking and very agile product owners representing the teams. Wrapping Up This post reflects why I think traditional project managers have a place within agile teams. Those project managers know how important chartering is, how important alignment is, how important it is to clearly communicate and manage expectations, and how important it is to get off to a good start. Nowadays, agile teams do not need traditional chartering activities. The terminology and focus needs to be quite different. However, the essence of the activity is the same and many more Agile teams need to charter than think they do. The example I presented, at least in my mind, is all about Agile chartering. I hope you can see that and hope you take away some lessons on what not to do and what to do when you are beginning agile projects. Agile project managers should be very good at guiding and leading just-in-time chartering activities within their teams. Do not ever lose sight of what Stephen Covey calls “Beginning with the End in Mind”! Thanks for listening, Bob. page 16


© iStockphoto.com / davidnay

Prof van Testing recommends

Follow me @vanTesting

IREB – Certified Professional for Requirements Engineering – Foundation Level Description The training is aimed at personnel mainly involved in the tasks of software requirements engineering. The tutorial is designed to transfer the knowledge needed to pass the examination to become an IREB CPRE-FL.

More information regarding the required knowledge can be found in the IREB Syllabus, which can be downloaded from the IREB web site: www.certified-re.com

© iStockphoto.com/numbeos

After earning a CPRE-FL certificate, a certificate holder can assess whether a given situation calls for requirements engineering. He understands the fundamental characteristics of the discipline and the interplay of methodological approaches, e.g. interview techniques, description tools or forms of documentation.

3 days

18.–20.12.12

Berlin (de)

19.–21.03.13

Berlin (de)

19.–21.03.13

Oslo/Norway (en)

09.–11.04.13

Mödling/Österreich (de)

14.–16.05.13

Helsinki/Finland (en)

14.–16.05.13

Berlin (en)

18.–20.06.13

Berlin (de) *subject to modifications

Website: http://training.diazhilterscheid.com

page 17

Dates*


Investing in team relations by Eric Jimmink

Many teams and organizations have moved towards Agile development. In some teams, this has led to enormous improvements in terms of productivity and product quality. Based on my practical experience, the following are the three most important success factors for an Agile team: 1. The people involved (in the team) 2. The product owner’s passion and ability to convey the intended use of the product 3. Buy-in and encouragement from the project sponsor Item 2 is largely an innate ability, therefore I want to focus on the first and the last. Those two items revolve around building the team, and fostering the relationship between the team and the customer. Building a team In most organizations, the established practice of forming and building a team is vastly different from established theory on this subject. In theory, you might analyze what (Belbin) roles are present in your team, and, thus, what type of individual you need to flesh out your team. In practice, you have to make do with the people that are available. Selection is primarily based on the technical skills needed to get the job done and interpersonal aspects may very well be ignored when choosing who will be on the team. The consequence of this approach is that initially on a newly formed team, team cohesion and morale may be low. Collaboration and productivity are likely to suffer unless steps are taken to boost collective cohesion and morale. As an individual team member, what can you do? 1. Go above and beyond what is needed in your own role on the team. 2. Bake cookies for your team. One of the best team-building tools I know is home-made Dutch apple pie. 3. Watch out for individuals who upset the team’s balance in terms of effort and sharing.

page 18

Apple pie is a great team-building tool. This one was auctioned for charity at ADP West.

I am going to elaborate on what you can do ensure that all team members engage in a similar fashion. Part of this should be by design and through discussion with the whole team. The foundation should be a common understanding of the team’s Definition of Done and how the team members feel about Sustainable Pace. If an individual team member puts in a lot more effort it will actually upset the balance, because it raises expectations and the team’s velocity may not be sustainable. Take any over-achievers to one side before discussing the team’s velocity at the next retrospective. A common issue that many teams face is a team member who is not good at sharing. If you want a ‘loner’ to become a team player, the best course of action is to speak to them individually. Enable them to engage and feel wanted by asking them to explain something to you. Ask for a review of your work. Then proceed to offer to review their work in return, long before it is complete. Explain that the most useful feedback is that which is received early on, long before all of the details are worked out. Once a person has experienced the uplifting feeling and added value of engaging in someone else’s work and vice versa, reverting to a solitary style of working becomes unlikely.


Investing in knowledge transfer What if the above strategy does not work? Suppose that one team member does not really want to collaborate or show an interest in other people’s work, and that this individual holds key knowledge in some areas. Harsh measures are then called for. Do not allow the unsuitable member to stay on the team indefinitely just because of this key knowledge. Instead, enforce the start of knowledge transfer as a measure to lower the bus factor. So, time needs to be reserved in the next one or two sprints for other team members to actively absorb the missing knowledge. After this time, you are in a position to simply say goodbye to the former key knowledge holder – which would be the recommended course of action if this person had not shown enough signs of wanting to collaborate with their team. Creating an open learning environment In a healthy team, the situation in which a single team member holds key knowledge should not arise if all team members invest some of their time in reviewing and really being involved in each other’s work. It is also necessary to strive for an atmosphere in which team players can freely admit mistakes and go to great lengths to help each other out. This is very important, because the hectic pace of most teams does not allow an individual to waste much time in struggling or figuring out some knowledge which is already present in the team. For any team and any organization, a starting point for the learning environment can be established by simply being clear about the core Agile values and key Agile practices which they want everyone to embrace. Key Agile values and practices 1. 100% reviews. A sound competitive atmosphere is within reach if all team members know that their work is certain to be reviewed and shared by one or more team members. It also encourages team members to look at work outside their own specialist field. Teams that use promiscuous pairing for simultaneous creation and review quickly reap the benefits of expanded knowledge in the domain as well as in technology. 2. Collective ownership of code and tests. Precisely because knowledge about the product and the solution is shared, any team member is eligible to alter the production code and the accompanying test suite. In fact, it is their duty to do so. For example, updating the test suite will be considered part of the work of engineering a database change. On a similar note, a tester or analyst should be allowed to outline a missing test or suggest a code change using a few comment lines and a tag in the shared codebase. Doing so avoids confusion and wasteful mail traffic. 3. Follow a clear Definition of Done. This is critically important for managing customer expectations. Typically, a team which has thought about its Definition of Done will endorse a set of coding standards as well. The latter is also needed for collective ownership. 4. Do not allow ‘team moments’ to dissipate. Danger signs are skipped standup meetings or retrospectives not being held at every sprint.

page 19

5. Celebrate victories, even small ones. Do not worry about calories. If your team has succeeded in reaching the sprint goal, there should be cake or ice cream, period. The short-term cost of such celebrations in terms of time and expense is usually insignificant compared with the long-term cost of not celebrating. The latter is hard to measure, but the detrimental effect on team morale and productivity can be enormous. 6. Vigilance against technical debt. This should go both ways. As a product owner, you must not pressure a team into releasing functionality that is not 100% Done nor argue to other stakeholders that this should be agreed. Team members should refactor zealously, and be watchful for short-term solutions. If a choice is made to deviate from the Definition of Done to meet a deadline, then time for a lasting solution should immediately be deducted from the available hours in the next sprint. To check whether this was followed through, an agenda item should be made for the retrospective which will be held after the next sprint. Of course, the list above is just a short one. A good seventh item would be to seek and cherish a customer willing to invest in the relationship with the team, and to educate or evangelize where needed. Challenge: how to establish a synergistic and uplifting teamcustomer relationship We have all read in the Manifesto that we value customer collaboration over contract negotiation. Get rid of the ”them” and ”us” and you have a common goal for developing great software together. However, this is easier said than done. The team commits to do their utmost to provide the customer with the best possible value. In turn, the customer should invest in the relationship with the team, support them in whatever demand on human resources they need, and motivate them by doing even more. For example, team-building items go on to the sprint backlog and the release plan. As a customer, this provides clarity and commitment. If, for example, the agreed release plan shows that, in the first week of sprint 3, the team will take a day off to play basketball and have a barbeque, then that is a powerful statement which should have a positive effect on team morale – both before and after the event. Give the product owner a contingency budget for project expenses. Allocate about 3% of the project budget to matters that do not involve team or the supporting staff hours. Suppose there is an impediment which could be removed through the purchase of a licensed tool. The product owner should be able to respond quickly – maybe just notifying the steering committee of his decision rather than awaiting their consent. If an organization shows its agility in such a situation, this will have an immediate effect on team morale. Engage customers and controllers. Any project should aim to produce a result that is actually used and accepted by the business. The key users must be identified early. Ideally, some users will be consulted when the project consists solely of a business case which is being formulated and reviewed. Early and continual involvement of key users forms a solid base for accepting the product long before it is built. The team directly benefits once


communication with key users is established. Acceptance criteria will be more clear and the appropriate checks will be anchored in the codebase. It is quite possible that acceptance criteria for “nonfunctional application behavior” will affect architectural choices. Therefore it is critical that such criteria are identified in time. On a similar note, it is vital to ensure that the controllers collaborate with the team. If their criteria are also heard, frequent delivery by the team will not be viewed as a nuisance. The only thing that does need to be clear is that the product owner is in charge. He or she must make choices when the requests from the various users conflict with each other or diverge from a chosen focus. The team should produce tangible results, including in sprint zero. Theoretically, it is not necessary to produce any tangible customer value in a preparatory sprint, because this is generally used to ensure that everything is in order and the sprint really starts afterwards. The top stories on the product backlog should be elaborated to ensure that they become sufficiently ‘Ready’ to be picked up in the first real sprint. Typical goals for sprint zero would be to establish the framework for the code and the automated tests. Technical challenges should also be identified at this stage. It makes sense to include a spike or a proof of concept for tackling one of the technical challenges. This provides more engagement than a ‘blank’ sprint. What a proof of concept also establishes is peace of mind – the confidence that the team can get the job done.

Agile teamwork is all about mutual commitment. A lot of coaching can and should be done by the team members themselves, because it is their duty to help each other along towards a common goal. A customer ought to go to great lengths to create the right conditions for the team to perform well. Empowerment stems from the long-term view, that a team has not been formed for a single project, but that a team is fostered and kept together for many more projects to come.

> about the author Eric Jimmink Erik is an Agile consultant at Ordina, based in The Netherlands. He has been a practitioner and a strong advocate of the Agile way of working ever since the term was coined in 2001. Eric has filled many roles on an Agile team: developer, tester, analyst, subject matter expert, and coach. He believes in leading by example, thinking outside of the box, and in Dutch apple pie as a team building tool. His recipes are open source. Eric likes to share his experiences in articles and at conferences. Eric co-authored a (Dutch) book about Agile testing, and he aims to finish a sequel before the end of the year.

Conclusion

License ISTQB and IREB Training Materials!

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

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

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

page 20


Bug Bash – a Collaboration Episode by Trinadh Kumar Bonam and Ramu A.

In this current market the customer is facing competetiveness. There is a need to increase responsiveness, deliver “first time right” solutions/services, market dynamics, political strategies and quality commitment from the service providers. There is a need for integration of communication and collaboration channels. Collaboration is not just a buzz word, it is a central pillar for making any project into a great one. Collaboration: Solving a problem with a team is different from solving a problem as an individual. The best team cultures develop where team members recognize that everyone else also has important value to contribute. Different people will have different views of the problem. When organized people engage in non-zero sum games fueled by collaboration, they achieve significant advantage – they always have and most likely always will. Within an organizational context they are better positioned to increase productivity and use of resources, have more efficient communication, increase quality of decisions, and create better quality of services. In order to enable delivery excellence, collaboration needs to be improved in Agile methodology, which can be done through collecting different perspectives, suggestions, and ideas from the team members in a control-free envrionment by giving them a free hand to express their thoughts. Things such as requirements and design processes may not be formalized in Agile models, but still they need to be carried out in order to minimize issues in the later phases. We know that prevention is better than cure and bearing this in mind ensures all mistakes can be identified early on in the SDLC. This can be done in different ways by ensuring that every design/development task has its associated review task and unit testing task for the developed code. Underperforming reviews and unit testing together account for a large number of bugs escaping into next phase, i.e. to system test. Component testing, component integration testing, system testing and system integration testing are the different test phases that will be performed by the test team in order to identify bugs that page 21

have been missed in earlier phases. The possible extent to which bugs are identified in these phases depends on several variables such as a) expertise of the tester, b) time available, c)resources available to the test team and d) tester’s knowledge and expertise. Although the test team identifies bugs in system testing and other phases, they may not be in a position to uncover all the hidden bugs in the application. That is when colloboration comes in to play. We need a collaborative event at which we can find all quality bugs, helping us to bring quality to the project/product through the colloboration of each and every individual as part of the succussful project/product. If it were possible to get more people, even they aren’t professional testers, to look at your software before it is released, they may be able to find bugs that you and your fellow testers failed to see. For projects that are chaotic, poorly planned, or in constant fundamental change, the reactive test strategies have the advantage. Bug bash is a reactive test strategy. Although collaboration does not necessarily guarantee success, “collaboration must be the name of the game” (Kayser, 1994, p. 19) if you are aiming for increased efficiency, effectiveness, or survival – and, for most organizations today, you need all three. Based on this context we can consider that a bug bash is a collaborative event in which all the developers, testers, project manager(s), technical architects, etc. are involved in finding undocumented, hidden and suspected bugs in the application/system. Advantages of team collaboration in a bug bash: 1. Collaborative Solutions: One of the important advantages of a team is the power of collaboration. When people work together on identifying problems or solving problems, different views and interpretations of the problem, together with the different facts and information which the people in the team bring with them, help to create better solutions. 2. Added Value: The key to collaboration is to open the door to ideas from each team member. Management and team members have a responsibility to create an environment where everyone is encouraged to provide and develop ideas


without threat of shame or disapproval. Ideas can be knowledge, interpretations and any insights that may come about. 3. Relax and Have Fun: Collaboration, when done well, is not a competitive exercise. With encouragement from the test manager, team members will feel comfortable offering ideas that might sound useless but could ignite a brainstorm in war rooms or triages. This white paper is useful for people who are looking for information on ‘bug bash’ events. When do these need to be conducted?, where should they be conducted?, who will conduct these events?, how should these events be conducted?, why do we need to conduct these events? All these questions are answered in this white paper. What is a bug bash? “Bug bash….what is this?” You won’t read about this in your software engineering classes and may not know anything about this. People who are aware of it may think that a ‘bug bash’ is a waste of time, but this is not true. You will find out ‘how?’ once you have gone through this topic. Bug bash is the most common quality control collaborative technique used worldwide. Bug bash is where all the developers, testers, project manager(s), technical architects, etc. are involved in finding undocumented, hidden and suspected bugs in the application. It is nothing but a ‘bug hunt’, or we could even call it a healthily competitive game for finding bugs. Why conduct a bug bash? A bug bash is a pre-planned, well organized event which needs to be conducted in order to identify: 1. Undocumented Bugs: These are observations or incidents that are not tracked by any individual in a project for any of the reasons below: a) Discussions: scenario cannot be identified when only one individual is working on it; however, it could be identified when explaining it or giving a demo to someone. b) Negligence: ‘I think I have already logged this bug’ – making an assumption without searching in the currents bugs’ database. c) Postponement: ‘I will log the bug tomorrow, as I need to catch a flight now.’ d) D-Wildness: Developers might identify the bug (in code/ design/architecture) and its root cause, but are not interested in revealing their own mistake and leave it as a brainteaser to test the team. Here is an example of reason a): This discussion passed between two test engineers. Consider a web application. Launch the website using IE and parallel launch the application using Firefox. (This may not happen in a real time scenario.) Here is the bug because the application which has already opened in IE is not responding. 2. Hidden Bugs: There is no application/product which is 100% bug free. Hidden bugs can be identified when the application/product is pounded.

page 22

3. Suspected Bugs: Team members (dev/test) will be confused as to whether the loophole identified in the application’s functionality is a bug or not. These kinds of bugs are normally ignored. They can be logged and documented in the bug tracking tool in a bug bash event. In this event we can expect all types of bugs to be uncovered, whether related to architecture, technical, functional or aesthetic. When should a bug bash be conducted? I can remember an interview I faced in my career. I included the statement ‘able to conduct A bug bash’ in my résumé and the interviewer asked me: ‘Is there a B type of bug bash?’ I laughed at him because I should have written ‘a’ instead of ‘A’. Now we come to our topic. Test lead should plan for both scripted and unscripted test execution. We are aware that test cases are sequenced based on 3 different priority levels, high, medium and low. Execution of sequenced test cases need to be flexible based on the test release schedules and size of overall test set. Test effort should be planned for both scripted testing and unscripted testing as suggested below: Scripted testing – 60% to 70% and Unscripted testing – 30% to 40% Unscripted test effort can be utilized as suggested below.

Unscripted test type

%

Confirmation testing

20% to 30%

Reactive testing

10% to 20%

Suggested techniques

Exploratory testing, Whittaker’s attacks, Hendrickson’s bug hunting techniques, Bug bash or Bug hunt etc.

A bug bash can be conducted at any time once the application is stable. In general it is planned after testing has been completed and in a time frame well before UAT starts. Conducting a bug bash may also depend on the situation or milestone of the project. Possibilities are given below: 1. Once system testing has been completed by the test team and if there is ample time to conduct UAT or deliver the project, 2. If the client/senior management* feels hidden bugs needs to be identified 3. If the client/senior management* want to make the product/ application stable, 4. If the client/senior management* want to increase the competitive spirit/team spirit among the test team members and make them identify hidden bugs. 5. If the service provider/senior management* feels that customer centricity can be shown by providing added value. Apart from the above, budget is the main criterion which needs to be considered in order to conduct the bug bash. *In the above context senior management means PM or test manager.


Who should conduct a bug bash? a) Who should conduct a Bug Bash? Bug bash sounds similar to “eat one’s own food” and is a tool used as part of the test management approach. The test manager(if the project team contains more than one test team, e.g. UI Test Team, Backend Test Team, Performance Test Team, Automation Test Team) or test lead should initiate a bug bash event. The test manager/test lead may be from on-site or offshore. b) Who should be involved in a bug bash? Developers, testers, project manager, and technical architects should be involved in a bug bash. Sometimes even usability researchers, designers, documentation staff, and marketing people put aside their regular day-to-day activities and hit the application/product in order to have as many eyes as possible look at the application/product. It is a good practice to involve all the teams within the SDLC phases, as well as upstream and downstream application teams who are literate in the application. How to conduct a bug bash? A bug bash is usually announced in advance to the team. Test management sends out the scope, event timings and other details in an email. Here are some of the teasers/fun pictures that can be added as an attachment to the bug bash email.

a) Before a Bug Bash: There are certain things that need to be done before you (i.e.: typically a test manager or test lead) make plans to conduct a Bug Bash. These are discussed below i. No to the fly alarm: Never say to the team that we have an event where everyone in the project should find bugs! This creates fear in the test team that ‘If we missed any bugs we are not doing testing properly’. Communicate well in advance by cross-checking the project milestones and line up leads and key players to support the effort by having a prior meeting. ii. Stable build: You cannot do a bug bash on a moving target. Communicate and coordinate with the dev team to provide a stable environment which contains the latest code changes and make sure that no one touches the codebase during the bug bash event. Make sure the entire development and test team understands the basic event rules. iii. Support from contributors: Identify the key players in the team, either key leaders or star performers and get them to help, promote and contribute.

Get ready to find bugs using any of the approaches below. You choose the one(s) you like. Finally, quality bugs are counted.

iv. Event details: Communicate with the entire team about the event rules and regulations by sending an email (email template above, i.e. ‘Project Name-Release 12 Bug Bash 20012’). Make sure the game score and prize details are in the email in order to improve the spirit of the event. v. No war: Tell the team that the entire game/event may be stopped if people fight over bugs and that no one will win.

Please see the email template on page 22 The diagram below shows the phases of a bug bash.

vi. Create atmosphere: Let your team members help to create the event environment by putting some bug pictures and bug toys in the cubicles. Keep some welcome print-outs in the entrance to your floor which mention the bug bash. Distribute bug bash hand bands for the real participants and ask them to wear. Create a competitive environment. vii. How to log a bug: Testers may be aware of how to log bugs, but the rest of the players may not have much idea about this. Explain it by sending a separate email or by arranging a meeting before the event starts and send a template to them once that is

page 23


page 24


explained in the meeting. This helps to keep control of the participants who are trying to be smart in the bug bash, by logging Not Repro, Invalid, Duplicate, and By Design bugs. Remind everyone that bad bugs create extra work. Provide details of two different bugs as an example, one good and one bad. In the good example show the title, description, clear repro steps, proper prioritization and valid severity. In the bad one show an incomprehensible title, descriptions, impossible repro steps, etc. If you do not provide an example, do not expect people to magically know what you are looking for. Rejecting the bad bugs after discussion in the triage is a waste of everyone’s time. Even we can circulate a Test Charter (A statement of test objectives, and possibly test ideas on how to test. Test charters are often used in exploratory testing) to control the participants in logging Not Repro, Invalid, Duplicate, and By Design bugs. b) In a bug bash: There are certain things that need to be done by you (i.e. typically a participant) in a bug bash, which are: i.

Area of Focus: In order to find bugs in the applications, the strategy is different for the participants: Testers: Since testers are aware of the functionality, first do a smoke test and then uncover the bugs in the functional area that you own. Try to recollect the issues that you feel/doubt are bugs and which are not logged. Since testers are aware of the process of logging bugs, don’t try to log Duplicate, Invalid or By Design bugs as it may degrade your fame. Once you have finished with these, try to dig into the other functional areas. Finally, it is preferable to find bugs by doing ad-hoc testing. Others: You may or may not know most functional areas of the application. Try to get to know the application’s functionality or the remaining functional areas that you do not know before participating in the event. Try to find bugs by performing monkey testing (if you are not aware of that functional area), otherwise perform ad-hoc testing to uncover the bugs. Don’t worry about By Design or Invalid bugs, but try to avoid Duplicate bugs by searching the bugs database before logging a bug.

ii.

Email alarm(s): Apart from these, there are certain things that need to done by a test manager/test lead when a bug bash event is going on. Try to send the event status reports which contain ‘who stood first’, ‘bugs logged so far’, etc. Encourage the team in the emails. Increase the frequency of emails when the time is up.

iii. STOP: “Hey, STOP!”, shouted the test manager. No one should log a bug once time is up because such bugs will not be taken into consideration. c) After a bug bash: i. Round of applause: Once time is up, the test manager/test lead should send a congratulations email to the team about the entire event.

page 25

Send an informal meeting invite to the team to discuss the entire bug bash event’s status. ii. Bug triage: Reserve a conference room, get together and start discussing the bugs that were logged in the bug bash. This is called a ‘bug triage’. In this the bugs need to be re-prioritized by taking a vote from the members. The reason for re-prioritization is that most of the people involved in this have no testing background so they might assign the wrong priority or log Invalid or By Design bugs. Those bugs can be ignored or closed in this ‘bug triage’. Because development team members are available in this meeting, bugs can be assigned to the respective developer there and then. No individual will drive the bug triage; people will share the bugs among themselves. Note: the test manager or test lead will be a spectator in the bug triage, would respond when requires. Good to have features and suggestions given by the participants can be considered for fixing based on the interest of the business. They may depend on impact on existing functionality, time and cost for fixing. At the end of the bug triage you will have the bugs that need to be fixed. Order some snacks for the team if budget permits. iii. Count: Once the triage is completed, get the bug count based on the bugs in the database. Generate a report and circulate it to the team. Announce the winners of the event. iv. Honor: On the next day, grab a conference room and distribute the prizes to the winners. Prizes could be for ‘Most Twisted Bug’, ‘Highest Bug’, ‘Bug Least Likely to Ever Get Fixed’, etc. Prizes could be, for example, a book on software testing/project management’. Advantages and disadvantages of a bug bash: Advantages

Disadvantages

Undocumented, Hidden and Separate time need to be alSuspected bugs can be iden- located/updated for this in the test plan and project plan. tified. This collaboration and team Conflicts may arise among building activity increases team members if there is no team spirit among the people proper coordination. involved. Technical, Functional and Us- Budget needs to be considability bugs can be identified. ered. Competitive spirit among The test team could feel unthe test team members is in- comfortable because non-test creased. team members are identifying bugs. Talent can be recognized, ap- More bugs identified in a spepreciated and rewarded. cific functional area could demotivate respective tester who owned that functionality. (Don’t try to point out them.)


Advantages

Disadvantages

Bugs identified in a bug bash may make the project/product a ‘stable release candidate’

> about the authors Trinadh Kumar Bonam MSc (Computer Science), MTech (Software Engineering), Six Sigma (GB), Certified Scrum Master, HNC

Watching how someone else approaches a problem is a great way to learn new testing techniques.

(from NIIT), ISTQB foundation, is a test engineer and test lead with over 7 years of experience. His testing experience spans domains such as sales/partner sales, call centres, telecoms(OSS/BSS/VAS), retail, manufacturing, etc. as a test analyst in various projects covering multiple technologies (e.g. Siebel, MS CRM and SharePoint) and has been involved in Agile testing. He is now working for TATA Consultancy Services Ltd in India. His primary objective is ‘QUALITY’. He is interested in learning new things and finds never ending challenges in testing. He can be reached at trinadh. [email protected] and you can find more about him on LinkedIn. Ramu A. B.Tech(ECE), has an enormous amount of work experience in different service sectors. He is currently working for Tata Consultancy Services. His experience spans domains such as call centre and manufacturing. As an ITA, he has worked in various projects covering multiple technologies (e.g. SharePoint and .Net) and has been involved in Agile testing and Automation Testing. He is interested in learning new things.

page 26


Building a culture of collaboration and teamwork by Nishant Pandey

The ‘manifesto for agile software development’ stresses the value of collaboration and teamwork. The widespread use and success of Agile methods has ensured that the need for a culture of collaboration is understood by the software industry and Agile practitioners. Advantages made available by the use of Agile methods, tools, and techniques have led to an increased focus on collective performance. Agile practitioners understand that collaboration is a powerful tool with the power to transform ordinary groups of people into high performing teams. This article is aimed at sharing thoughts and insights around the essentials for building a culture of collaboration and teamwork, with an inclination towards software teams. Team 2.0 Today’s teams are more complex and diverse than those we have seen in the past. These teams are generally cross-functional, geographically dispersed and multi-cultural. These key attributes have led to an increased ability to deliver quick and lasting improvements. Instead of existing as a group aimed at sharing information, the new software team aims to generate positive synergy through coordinated efforts moving towards the shared goal of achieving team success. There is increased awareness that collaboration and teamwork play a crucial role in achieving project success.

A case for packs (no herds or mobs) The ‘herd’ mentality is characterized by a predictable and coordinated behavior of large groups of very similar individuals. While animal aggregations, such as flocks of birds and schools of fish, could benefit from enhanced foraging and increased locomotive efficiency, this tendency can often place work teams in a very disadvantageous position. A team environment which is characterized by lack of leaders, reduced creativity, and lack of will power in individuals to take independent decisions can drastically impact a team’s productivity, agility and output. The ‘mob’ mentality, on the other hand, can be characterized by a lack of coordination and an increased degree of chaos. There is little value in teams that have a chaotic setup where individuals are agitated and confrontational. It is the interdependent, proactive and coordinated ‘pack’ hunting behavior that makes wolves successful hunters. Rather than being viewed as herds or mobs, today’s high performing agile teams can be considered as ‘packs’ which have individuals who use their decision-making and leadership abilities to work collaboratively towards attacking the group’s problems in a coordinated and well practiced manner. Importance of collaboration Leaders of today’s Agile enterprises have to embrace the dynamics of a changed work place which is evolving at a fast pace. It is important that today’s leaders and managers work towards increasing the software team’s effectiveness and efficiency. Today’s practitioners have come to understand that there is tremendous value in cross-functional, diverse teams. When nurtured in a culture of collaboration and teamwork, these teams can deliver excellent results while also reducing time to market and increasing the team’s ability to respond to changes. A culture of collaboration and teamwork can lead to a team performance that is greater than the sum of its individual inputs.

Figure 1: Composition of today’s software team

page 27


Power of leadership Effective leadership is an important aspect that can help greatly in setting up a collaborative culture. Bad policies and poor leadership have an adverse effect on the ability of teams to deliver results. Astute leadership can help teams increase their productivity and improve communication with internal and external stakeholders. It is important that the attributes and behaviors that contribute to effective management and leadership are understood, valued, and nurtured appropriately. Developing and nurturing these attributes in a team environment can help in many ways. A team that has individuals with good leadership skills is able to increase its resourcefulness, creativity, and problem solving abilities – attributes that can help the team deliver better results and service. It is a myth that authority is the same as leadership. The success of high performing Agile teams has indicated that authority has little to do with leadership. Successful teams make individuals individually and jointly accountable for shared goals which are specific, measurable, achievable, and realistic. Role of trust and communication Trust and communication are two very important aspects that influence the culture of collaboration in a team. Trust empowers team members by maintaining a positive outlook on team goals. When team members trust each other, they are able to confidently take risks, share opinions, and work collaboratively. Due to the power of trust, they are assured of the fact that they will not be taken advantage of.

Team members are motivated to collaborate best in an environment that is impartial, open, and fair. The leaders of the software enterprise need to strive constantly to assure and reassure these feelings. Respecting the opinion of team members, giving them due and timely credit for their contributions, and empowering those who embody these characteristics go a long way to ensuring that a culture of trust and collaboration thrives in an organization. Listening to others Listening to the concerns, complaints, and ideas of various team members is a very important factor in creating and maintaining the team’s motivation and trust. It is important that all key team members understand the importance of listening skills and practice these to improve the team environment. Other parameters Other parameters that support the concept of trust include competence, consistency, loyalty, and integrity. The effectiveness of a team’s ability relies heavily on the ease with which individual contributors are able to acquire the trust of each other.

Lack of communication breeds distrust. It has been observed that, in the absence of information, many people have the tendency to make negative assumptions when filling in the blanks. This impacts on their morale, motivation and, ultimately, their ability to collaborate for team success. Effective communication and trust have become increasingly important due to the new team‘s composition and the need for agility. While working towards ensuring that communication is well directed and appropriately tailored, practitioners need to be aware of cultural differences. They must also take into account the increased complexity that accompanies today’s multicultural and geographically dispersed teams. Influencing trust to foster collaboration While it is important to understand the role that trust plays in creating a collaborative culture, it is absolutely essential that the factors which can influence the feeling of trust are understood and practiced. The following aspects can have a tremendous impact on creating and nurturing trust in a team setting. Clear and consistent goals Well communicated, clear, and consistent goals have the power of simplifying the complexities that accompany today’s work environment. Clarity of objectives at a team level enables team members to set logical and balanced personal targets which can lead to periodically measurable progress. It is recommended that goals be discussed, revised, and revamped from time to time so that they remain relevant to the needs of the enterprise.

Figure 2: Inter-related factors that influence trust

Rewarding the right behavior An ill-conceived reward system which rewards bad behaviors can have a catastrophic effect on the collaborative culture in a team. It is very important that the right attributes and the individuals who practice these behaviors are rewarded instead. Leaders should work towards finding, acknowledging, coaching and rewarding role models. The right reward system ensures that individuals who are rewarded are those who most embody the collaborative culture the organization wants to create.

Openness and fairness

page 28


from each other, grow together in a team setting, and make the > about the author most of their collective abilities. A collaborative culture empowers individuals to find happiness in joint successes. Nishant Pandey works with Capgemini and is based in Chicago, USA. Nishant is a part of the Portfolio & Delivery Management Group for a reputed client of Capgemini. In his role as a project manager, he is responsible for managing multiple projects in the financial services domain. Nishant is a certified PMP® and loves to share his knowledge. He has trained more than 100 project managers and works actively with the training department of his organization. Nishant’s articles on software engineering and management have been published in Agile Record,

Figure 3: Rewarding the right behaviors

Testing Experience, and Quality Matters magazines. Recently, Nishant

Redefining personal success The African philosophy of ‘Ubuntu’ offers an interesting perspective on how individuals can align their goals and priorities to those of the group. In the words of Liberian peace activist Leymah R. Gbowee, the philosophy of Ubuntu states “I am what I am because of who we all are”. It is important that individual contributors understand that their personal success affects the extent to which their team’s goals are met.

has authored a chapter on Benchmarking in the book ‘The IFPUG Guide to IT and Software Measurement’. In his spare time, Nishant likes to make short films and write songs.

Since everyone likes to be successful, emphasizing the interconnectedness of individual and team goals can be an important step in the right direction and set the stage for creating a collaborative team culture. Enemies of the collaborative environment Workplace politics, arrogance, lack of trust, and competing egos are enemies of the collaborative culture. These factors can limit the growth of teams by negatively impacting teamwork and collaboration. All humans like to be included and appreciated for their contributions, thus an important aspect that negatively impacts on a team’s culture is the feeling of exclusion. Leaders should work towards creating a team that is based on affection, affiliation, and acknowledgement. Managers must work towards facilitating a healthy exchange of ideas and fostering a sense of personal self worth. Mismatched goals and aspirations, hidden personal agendas, and unclear roles and responsibilities are other enemies of a collaborative team culture.

Figure 4: Positive and negative influences on collaborative culture

Conclusion Investing in building a culture of collaboration and teamwork can go a long way towards empowering today’s teams to deliver better results. An atmosphere of collaboration allows individuals to learn page 29


Distributed Agile: The Power of Collaborative Spirit by Raja Bavani

All successful distributed teams have one prime factor in common. It is collaborative spirit! While collaborative spirit is essential for all project teams in general, the challenges of distributed agile teams necessitate the continuous existence of collaborative spirit at all times right from the early stages of projects in order to ensure successful product releases. In the IT industry, we have seen a gradual increase in the availability and advancement of hardware and software tools that promote collaboration among geographically distributed teams. This evolution in toolsets for collaboration among geographically distributed teams has come a long way, but measuring the effectiveness of collaboration has remained equally complex. I have noticed that a practical approach to understanding the effectiveness of collaboration in distributed agile teams is to observe the signs that matter the most. In this article I will share ten such signs and provide my concluding remarks on the importance of collaborative spirit. Ten Signs of Effective Collaboration 1. Focus on Backlog Grooming – In your project, do geographically distributed teams collaborate in order to ensure that backlog grooming is performed on time? If the answer is ‘yes’, be assured that your team starts every iteration or Sprint with the right first step. Collaborative teams facilitate ‘backlog grooming’ sessions at regular intervals ahead of time for each Sprint. Sprint N-1 (planning and execution)

Sprint N (planning and execution)

Sprint N+1 (planning and execution)

Backlog grooming for Sprint N

Backlog grooming for Sprint N+1

Backlog grooming for Sprint N+2

Figure 1 – Backlog Grooming Ahead of Sprint

As shown in Fig. 1, it is recommended that the product owner and business analyst(s) perform backlog grooming ahead of time. This will ensure that Scrum teams obtain groomed users stories for Sprint planning. page 30

2. Articulating the Definition of Ready – Do your teams articulate the definition of ready and check if groomed backlog items satisfy the definition of ready? Collaborative teams not only specify DoD (Definition of Done) for all user stories during Sprint planning but also articulate DoR (Definition of Ready) to check if groomed backlog items are detailed enough to initiate the planning exercise. 3. Clear Acceptance Criteria – Clear acceptance criteria are what make reviews effective. Distributed teams work together in defining clear acceptance criteria when they care for each other and have a common goal in mind. They collaborate intensively to discuss all complex scenarios and identify acceptance tests that can enhance product quality. 4. Efficient Resolution of Queries and Issues – Do you think your team members use collaboration tools efficiently to resolve queries and issues? Are they proactive? Do they think about alternative solutions to issues, or multiple answers to queries, and choose the right ones? Or do they come unprepared, think during a conversation or phone call, and delay their responses? When you admit that your teams are efficient in query or issue resolution, it is evident that they are powered by collaborative sprit. 5. Candid and Timely Feedback – Do you receive candid and timely feedback from virtual teams? Do team members share their ideas and suggestions? Do they appreciate each other when a job is well done? Do they hand-hold when someone is slow? Collaborative spirit is about making sure that candid and timely feedback ensures course correction and reduces delays. 6. Productive Retrospectives – Do you think the outcome of retrospectives justifies the time spent by all team members? Do retrospectives result in continuous improvement? Do you think team members hesitate to suggest improvement areas in retrospectives? When you find that retrospectives are


improving iteration after iteration and resulting in meaningful actions for continuous improvement, it indicates a high level of trust and collaboration among teams. 7. Efficient Resource Management – This is about the consumption and management of all resources such as software, hardware, infrastructure, time, etc. by team members. Have your team members established ‘quiet time’ or ‘do not disturb’ hours? Or do they consider their peers and teams from other locations available to chat or phone on an 18x7 or 20x7 basis? Do they use the right communication tool for the right purpose? Collaboration does not mean making oneself available at the convenience of others and spending unlimited resources. It is about empathy, respect, and efficiency. 8. Constructive Negotiations – Do your teams have a level playing field when it comes to negotiations? Are they pushed by one team all the time? Or do they understand the common purpose and engage in fact-based constructive negotiations? Collaborative spirit results in constructive negotiation. This is because there is no hidden agenda or goal. There is a shared vision and teams believe in understanding the facts and perspectives to conclude negotiations.

> about the author Raja Bavani is Chief Architect of Mindtree’s Product Engineering Services (PES) and IT Services (ITS) groups and plays the role of Agile Evangelist. He has more than 20 years of experience in the IT industry and has published papers at international conferences on topics related to code quality, distributed Agile, customer value management, and software estimation. He is a member of IEEE and IEEE Computer Society. He regularly interfaces with educational institutions to offer guest lectures and writes for technical conferences. He writes for magazines such as Agile Record, Cutter IT Journal, IEEE Software and SD Times. His distributed agile blog posts, articles, and white papers are available at www.blogs.mindtree.com/author/raja-bavani and www.se-thoughtograph.blogspot.in. He can be reached at [email protected].

9. Team Initiatives – Do your teams come up with their own initiatives? Such initiatives can be related to learning, sharing, continuous improvement, reuse, team outings, or fun events. Collaborative teams take the initiative, come up with new ideas, and celebrate success. They do it together as a whole team. 10. Continuous Improvement – Do you think continuous improvement happens in all geographically distributed teams in your project? Or is it a fad among some teams and ritual in other teams? When continuous improvement is practiced with the same rigor in all your distributed teams, it is an indication of shared beliefs and constructive collaboration. This leaves no room for double standards. Collaborative Spirit Boosts Communication and Coordination I have experienced this in my project teams. When there is collaborative spirit, team members learn faster, improve their skills in speaking foreign languages, and foster mutual respect. The result is a collaborative culture with a tremendous increase in efficient communication and coordination skills among distributed teams. Conclusion Collaboration does not mean the availability of collaboration tools or team members to initiate and conduct meetings or discussions. Collaboration does not mean the freedom to be reactive at all times. Collaboration does not mean initiating the blame game when an opportunity strikes. It is not about withholding feedback. Collaboration is about respecting the time and resources of fellow professionals and of the organization. It is about believing in collective decisions. It is about participatory conflict resolution. It is about action-orientation. Collaborative spirit is contagious and it enables project teams go beyond the pre-defined set of ceremonies prescribed by methodologies. This is when teams identify processes that serve the purpose and thereby maximize the value delivered to customers.

page 31


Column Managing Agile Results at Several Levels of Organization by Kai and Tom Gilb

In our previous Column (The Top 10 Critical Requirements are the Most Agile Way to Run Agile Projects, August 2012, Ref 3) we emphasized the necessity of controlling delivery of value to stakeholders by using multidimensional top level quantified project objectives. In this column we are going to take you a step further. We are going to present the idea of multiple levels of control of the agile project. It is not enough that an agile project simply deliver the IT system’s top level qualities like, usability, security and adaptability. Even though even that direct delivery and management of quality levels is missing from most agile methods in practice. This is what we discussed in the previous column. If the project is large and complicated, meaning the project is delivering results to many and varied stakeholders, like a hospital system. You will need to manage the delivery of value to each type of stakeholder. Usability for nurses is not the same as for a surgeon or administrator. In addition, if the project is expected to have results for the large organization (Hospital level for example), then a third level of management is required, to relate the stakeholder results to the larger organization.

Kai Gilb practiced this successfully on a project for the ‘Bring’ organization in Norway (Ref. 2). This method turned a failed Scrum project (sales went drastically down when the new web portal was delivered) into a successful project. The process Kai used can be viewed as one that stands above, and controls the Scrum process. We call it a Value Management process. The stakeholder vision level specifies the most critical values required by each stakeholder. The prioritization step determines which stakeholders will get ‘how much’ of their value, delivered in the next delivery cycle (Sprint). This prioritization is based on several factors such as deadlines, levels delivered to date, minimum tolerable levels and other factors. (See depth paper Managing Priorities ref 4) The detailed ‘modeling’ of the value flow is done using Impact Estimation tables (ref. 1). 1. on the left side, critical objectives (like Profit) are named with a tag, which cross references a more-detailed specification (with Scale of Measure and Numeric Goal level) 2. On the top side a series of strategy columns (like Training Costs) are referenced (more detail on them is specified elsewhere under that tag)

Figure 1: Two levels of result management, above a Scrum process. The Business level is missing here. We are just managing delivery of results to stakeholders.

page 32


Figure 2: The use of Impact Estimation Tables (Ref. 1) as ‘Value Decision’ Tables. This is a very simplified view of the real model used at Bring. It includes the Business level.

3. The estimated impact, on reaching to Goal levels, due to the strategies is primarily given as a percentage of the ‘distance to the Goal level’. 0% means no impact, 100% means all the way to the Goal level, for stated conditions (such as when, where, for which stakeholder) 4. The resources % is a % of a budget, or project time scope. You will see that the higher level strategies are reused as objectives in the level below. In this way there is a direct numeric and dynamically track-able (through project delivery cycles) relationship between the top levels and the level of design for the IT system (the prioritized list, the backlog). This allows management to see the connection between IT design and architecture, and its impact on the rest of the organization; at a stakeholder level and at the general organization level. Here is a sample explanation of how it works, based on the tables above. 1. Code Optimization (a design strategy, to be implemented by developers in Scrum) contributes an estimated 80% to Performance Goal level.

3. Training Costs (when at its Goal level) contributes an estimated 50% towards reaching our Market Share Goal level. The ‘developers’ are not concerned with this process above the coding. Unfortunately they don’t even consider, and plan for, the larger system (data, machines, people). They are narrowly concerned with source code, frameworks, testing and bugs. That is why projects fail, if left to traditional developers alone, and to Scrum in isolation. There is no manageable connection to the real world. You cannot expect a developer to develop this management results framework. At best it is the responsibility of the Product Owner function to manage it. But if we expect real value-to-stakeholder to flow, and that is the main point of Agile, then someone (management) must articulate these values, their relation, and track them incrementally, until all Goals are met (‘Done’). Smaller projects do not need this management framework. But since Agile is being used for non trivial projects, there is a point where we need to introduce relevant value management. The small additional effort (5%?, a few days) is a small price to pay for ensuring real success.

2. The Performance attribute (of the IT system) contributes (when at its Goal level) an estimated 50% towards the reduction of Training Costs.

page 33


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

page 34


Online Training & Exam Preparation

ISTQB® Certified Tester Foundation Level (English & German) ISTQB® Certified Tester Advanced Level – Test Manager (English) ISTQB® Certified Tester Advanced Level – Test Analyst (English) ISTQB® Certified Tester Advanced Level – Technical Test Analyst (English) ISEB Intermediate Certificate in Software Testing (English) Sample Questions & Answers, Exam Simulation, Quiz & Exercises, Videos

Our company saves up to

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

© iStockphoto/Yuri_Arcurs

www.te-trainings-shop.com

Stealth Collaboration: How to Go Agile Without Management Support by Mark Kilby When organizations adopt Agile practices, a fundamental shift in culture is often required. Teams are suddenly asked to participate in the decision-making process and to take ownership of commitments. Project leaders are expected to create and facilitate this shift to a collaborative culture. While collaborative cultures often create stronger, more productive teams with a vested interest in an organization’s success, the move to Agile and a collaborative culture can sometimes be a challenge. Teams without management support are often forced to go underground in a covert collaboration endeavor. Paddling Toward the Same Goal Collaboration is defined as the ability to work together. Unfortunately, many organizational structures are, instead, set up for competition. In a simple analogy told by leadership coach Christopher Avery, it is clear to see the power of collaboration and working toward the same goal. Mike and Chris are paddling together in the same canoe. Chris sees a hole in the boat – he immediately tells Mike and they safely bring the boat ashore to make the repair. In another scenario, Mike and Chris are in two separate canoes. They are paddling toward the same goal but are competing for budget and resources. Chris sees a hole in Mike’s boat. Does he tell him? In our hyper-competitive corporate environments, the answer is almost always ‘no’. Faster, Better, Cheaper – Pick Two A common scenario at many software companies is one in which a development team is told by management to increase quality, produce code faster and improve efficiency – but is not given a larger budget, more resources or more time to accomplish this Herculean task. Often, the team surmises that it must change the way it works and begins the move to collaborative practices such as Agile. Ideally, leadership would be supportive of a move to Agile practices and collaboration, but this is not always the case. If management does not support the move to go Agile, it can pose a real problem for the development team. Management often does not want to hear about Agile; they may be worried about making a drastic change or could be uncomfortable with transparency and open communication. As a result, the Agile effort is forced underground and becomes something of an undercover project, also known as “stealth collaboration”. This is how many companies begin their Agile efforts: a team goes “renegade”, insists on a move to Agile methodology and, after a notable success, reveals how they did it. For a team considering this approach, the project manager plays a vital role in protecting the team from the non-collaborative interference of other departments. The team needs a courageous project manager who is willing to provide traditional management reports while also facilitating collaboration in the team. page 36

Skunk Works in Action Stealth collaboration is how many Agile transformations begin. One industry story is about an organization in New Zealand that had such an experience. At that time, Agile was not mainstream “down under”. The team completed Agile training based on Scrum concepts and learned how to structure the teams’ roles for a successful Agile project. They took the learnings and covertly applied them to a small project – the team then delivered in record time at a fraction of the cost. When dramatic project delivery improvement catches the attention of a high level executive, for example, organizational acceptance of collaboration can start to take hold. As word spreads, this Agile approach can become the standard for future projects and teams may be able to roll out collaborative concepts and Agile practices openly throughout the organization. By implementing a collaborative culture with leadership that is truly committed to Agile practices, companies can more effectively work toward solving the common problems associated with software delivery. If management is not on board with the move to Agile, stealth collaboration brings with it a grassroots energy that can spread like wildfire throughout the organization. Once Agile becomes “proven”, then collaboration concepts are usually met with less resistance. Successful collaboration is one of the most important cornerstones of Agile practices. Collaborative cultures often create stronger, more productive teams with a vested interest in an organization’s success. If you don’t have management support for Agile, but you have a team willing to try it, stealth collaboration could be the way to prove the benefits of going Agile. As they say, sometimes it is easier to ask for forgiveness than permission – especially if you can achieve faster time to market with better quality and less cost through Agile.

> about the author Mark Kilby Mark Kilby is an Agile Coach with Rally Software in Orlando, Florida. Since 1990, Mark has helped teams develop unique software and system solutions for government, industry, and academia as a developer, architect, project manager, instructor, methodologist and scrummaster. His experience spans full life cycle development of new and legacy applications for the military, NASA, publishing, telecommunications, and other industries. His passion is working with distributed teams to become great teams through collaboration, automation, and other agile best practices. Mark is a Certified ScrumMaster and received a Masters degree in Electrical Engineering from the University of Florida and a Masters in Computer Science from University of Central Florida.


The psychology of work groups by Johannes Staffans

How do you go about creating good software? I know that, for me personally, having a high measure of technical excellence was for a long time the answer to this question. Techniques such as TDD, continuous integration, and design patterns seemed to provide the one true answer to the problem of delivering high-quality software and delighting the customer. The craftsmanship aspect of software development is still a guiding star for me but, over time, I have come to realize that there is so much more to the software engineering process than just engineering. Software development is, above all, a thought process. Contrary to, for example, industrial manufacturing, we do not have machines that stamp out lines of code. They are written by us humans (and humans in the plural) because modern software development is almost always performed by teams consisting of multiple individuals. An assembly line can be fine-tuned through process engineering to provide maximum output but, unfortunately, we cannot use the same techniques in organizing software development. We have to try to figure out how to make the people on the development team work better together. Sometimes I wish I had studied psychology instead of computer science at university. It certainly would have provided me with more relevant power for handling the everyday problems in trying to help a software development team work smoothly together. As it is, I find myself spending as much time studying the mysteries of the human mind as I do trying to improve my technical skills. The psychology of work groups We all know that many things contribute to the success of a software development team, for example a suitable work environment, proper tools, and team members who possess the appropriate skills. To my mind, what makes the biggest difference during the day-to-day activities of the team is how effective the communication is, both within the team itself and between the team and the customer. “Communication” is, however, such an abstract term that it is much harder to put your finger on what effective communication is than, for instance, on what an effective work environment should look like. This is where you need to consider the mental page 37

processes going on inside the heads of the team members – the psychology of the work group. I find it strange that so little emphasis is put on the psychology of work groups in our field, even though we depend on teams of people to such a great extent. It is great that many organizations nowadays adopt Agile development techniques such as Scrum, but Scrum only functions as well as the people who are doing it are able to work together. Of course, Scrum helps because it introduces certain things that align well with how a high-performing team works, such as retrospectives. But have you ever been in a situation in a retrospective when there has been a proverbial elephant in the room? When, for example, everyone silently thinks that there is a problem with a particular team member, but no one addresses it because no one wants that person to lose face? What about the last time your beautiful piece of code was criticised by a fellow team member for not adhering to the “keep it simple, stupid” principle? Did you automatically go on the defensive (“He just can’t see how elegant this solution is!”) or did you keep a cool mind, stay objective and try to see it from the other person’s point of view? I know that I made a lot of mistakes during my early days as an Agile coach. I saw myself as an Agile evangelist in the organization where I worked at the time and I was excited to be put in charge of the adaptation of Scrum for a complex project with multiple, distributed teams. We hit a lot of snags trying to get it off the ground and some of the team members questioned both the transformation to Agile itself and my abilities as a coach. I was of the mind that we spent too much time arguing and that, after a few sprints of producing working software, the power of the Agile process would become clear to everyone. So, I made many cardinal mistakes. I tried to get the team into the fold by asking leading questions, for example: “Don’t you think it would be great if we tried this?” When I heard the usual criticisms during retrospectives I tried to brush them off and move on to the next subject. I constructed arguments using authority – “this works because said so”. Some of the team members were more open to Scrum and we used to talk together


about how stubborn the sceptics were and how it was hurting our progress while, of course, withholding these conversations from the rest of the team. These are just some of the actions that I later recognized as being damaging to the team. At the time, though, I was certain that – yes, you guessed it – I was quite simply right and the others were wrong. Everything that applies to the development team also applies to the special work group formed by the team and the customer. I bet many people have, at some point, spent time complaining to colleagues about a particular customer over the coffee machine but have never found an effective way to discuss the troublesome issues with the customer themselves. I have seen seemingly well functioning teams crash and burn because the communication with the customer simply was not working. A core concept of Agile software development is that the team should involve itself more directly with the customer which, unfortunately, can lead to many problems if the team members have no idea of how to communicate effectively. So, tell me what to do! To my mind, the old adage of “the more you learn, the more you realize how little you know” is particularly fitting to the subject of human psychology. Fortunately, it really is possible to stand on the shoulders of giants in this area because a lot of research has gone into the subject. There are many good books out there, my current favourite being The Skilled Facilitator by Roger Schwarz. I really recommend reading up on the subject to anyone involved in software development, not just Scrum Masters or project managers. In the meantime, I can offer you some thoughts on the techniques that I have found to be among the most important. First off, be aware of your shortcomings. It is a natural reaction for we humans to defend our ideas and positions vigorously when we are criticised and it is natural to assume that we are right and everyone else is wrong. This reaction is built into us and is activated subconsciously, so you really have to make an effort to combat it. Next time it happens, take a deep breath and think about the situation at hand – does the other person maybe know something you don’t? Have you explained your thinking clearly and completely, without withholding any critical piece of information? Make all information available. This is important because we want all team members to have a common base of information on which to make decisions. This generates a higher level of commitment to a decision. Sharing information involves explaining the reasoning and intent behind your positions. This includes the items of information that weaken your position – say, for example, that you have spent the last few days trying to refactor some old, nasty legacy code into a beautiful design pattern but have encountered problems that might endanger the successful conclusion of the sprint. Abandoning your solution and going for a simpler one might seem like a personal defeat for you, and you might feel reluctant to reveal the problems you are having to the group, but it might be more beneficial for the team as a whole if you were to save the big refactoring for a later time.

the frustration will never go away, but if you manage to discuss it in a productive fashion the other team member can perhaps make an informed decision in their own mind that, for the good of the team, it would be better if they changed their behaviour. Don’t assume. I once had an issue with a fellow team member who did not seem to be able to conform to the version control guidelines that were in place for the team. We had recently switched from Subversion to Git and I assumed that the team member, who had been on the team for a much longer time than me and had voiced some doubts about the switch, was just being stubborn and rebelling against the change. It turned out that the team member (who was not co-located but working from home) simply had not got the version control tool working properly and was doing their best to follow the guidelines. Once we got the tool fixed and went over the procedures, the issues went away. Discuss undiscussable issues openly. Say, for example, that you feel disappointed by the seemingly low level of interest a particular team member shows during team meetings. How can you bring this issue to the team without having the team member lose face, something that everyone usually wants to avoid at all costs? This is a difficult thing to do for all of us and it might take a while before you can do it. If communication within the team already works reasonably well it is a much smaller step to take. Just remember to focus on the issue from the perspective of the team and do not make it personal. Realize that you have a problem. If you, for instance, are experiencing an aggravated relation with the customer, you should avoid adopting an us vs. them attitude since it leads nowhere with regard to improving the relationship. Be aware of how difficult it can be to communicate effectively. Share all information, do not assume anything, and discuss your problems openly. If you still do not see any progress, consider bringing in a professional facilitator. Conclusion For me, one of the greatest things about Agile software development is how much more fun it is to work on a highly energized team where everyone is pulling in the same direction. Extend this to the customer and you have a dream come true. But you cannot achieve this by elbowing your way forward and focusing just on the engineering side of software development, you must consider the human aspect as well. Effective communication leads to everimproving relationships within the group and is key to achieving stellar performance.

> about the author Johannes Staffans is a software development consultant and Agile coach based in Helsinki, Finland. He holds an M. Sc. in Computer Science from the Åbo Akademi University in Turku, Finland. He has worked in software development for a decade but has not yet achieved his dream of writing code for a Mars lander. For more information visit www.bitrite.fi/johannes or follow @jstaffans on Twitter.

Sharing all information also includes talking about feelings, for example if you feel frustrated by the actions of another team member. Not sharing this bit of information makes it certain that page 38


Communicate with impact by Vicky De Roeck Everyone knows that communication makes or breaks a team. And good communication can be quite hard to achieve. Nevertheless, anyone can become a master communicator by applying a proper communication strategy. This topic has already been discussed at length in other sectors; now it is time to make the bridge between soft skills and testing. Getting your point across Did you notice that you communicate a whole lot better with likeminded people? People who are on the same wavelength as you are? These are typically people with whom you have something in common. People will naturally look for resemblances and will automatically feel affinity when they find them. Think about your partner, your best friend, or why you like someone in your team or dislike someone else. This often has to do with resemblances. The key to a good communication strategy is to create resemblances yourself. And that is not about making everyone wear the same uniform, rather it is all about subtle things. What is the other person’s behavior while talking to you? Is he or she very enthusiastic or rather reserved? Are they confident or embarrassed? How is the other person seated? How is he or she talking? It may be a bit too quick or too slow, intermixed with a lot of slang, or even with a stutter. When you notice these behaviors, you may start to imitate them. It must not be your intention to do this so obviously that it makes the other person uncomfortable, because that would not help at all. But if you can subtly take over some of the other’s behavior, you can create more affinity and people simply communicate better when there is more affinity between them. They will understand each other better and find it more pleasant to talk to each other. Those are important steps towards cooperation. None of this is new, of course. This technique is called ‘mirroring’. It has grown from NLP (neuro-linguistic programming) and has been known to master communicators for a long time. In fact, mirroring goes a lot further than what has been discussed so far. To give you an idea, the following can be mirrored too:

applying it at work. You will notice that mirroring is easy in your inner circle because there is more affinity to start with. If you are not ready to start mirroring yet, you can still optimize your communication through one or more of the techniques below. Dealing with difficult questions Everyone comes across difficult questions, but what is the best way to deal with them? An honest answer may reveal more information than you are willing to share, but a lie could damage your reputation. So here is a very useful trick. For instance, when someone asks you how much money you earn since your promotion, reply with something along the lines of “Thank you for your interest in my promotion, but may I ask you why you are asking this question?”. This way, you return the ball to the other side, which gives you some extra time to think. Most often, the other person will be surprised by the return question and not pursue the subject. Getting an answer to your question I have come across many situations where one of my questions remained unanswered. When asking for a status update, for instance, I got great stories about all the things that had been done so far, but in the end it was still unclear what the exact status was. If you feel that your question remains unanswered, you can use the “broken record” technique, which is dead simple. Remember those old record players? A scratch on the record’s vinyl surface would lead the needle to loop back and play the same couple of seconds over and over again. And that is exactly what you do to apply this technique – repeat your question until you are satisfied with the answer. In our example, you could restate your question as follows: “Thank you for your explanation, but I am still wondering what the exact status is. How many days of work remain until everything is complete?” Now, do not be a bad workman and blame your tools. If your question remained unanswered, it may not have been clear enough. Of course, it was clear to you – after all, you formulated it. But if the question was unclear to your listeners, you may have to reformulate it.

Physical

Voice

Gestures

Volume

Facial expression

Tempo

Eye contact

Pitch

Vicky De Roeck

Breathing (from the breast or the belly)

Words

Vicky De Roeck is an experienced functional tester

> about the author

in agile software development as well as in waterfall systems. In all circumstances her strategy is to get the

Touching

best out of every performance. She focuses on soft

External characteristics, such as clothing

skills and especially on communication strategies which can be used to improve test performances and to obtain the best possible result in every task. Her device: “With the right strategy everything is possible;

Do not mindlessly copy the other person’s behavior. When your partner in dialogue changes position, wait a couple of seconds before changing yours. Be subtle. Start out by practicing this technique in your inner circle. Begin by applying it to people whom you trust and whom you have no trouble communicating with before page 39

even the sky is not the limit!” Today Vicky is a test engineer at Ps_testware NV were she also gives presentations about the optimization of test performances.


© Pitopia / Klaus-Peter Adler, 2007

Enjoy Test Case Design in the Cloud CaseMaker SaaS supports systematically the test cases design by covering the techniques taught in the “ISTQB® Certified Tester program” and standardized within the British Standard BS 7925. The implemented techniques are: Equivalence Partitioning, Boundary Check, Error Guessing, Decision Tables and Pairwise Testing. Furthermore Risk Based Testing is supported. CaseMaker SaaS fits 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

Secret Recipe for Building High-Performance Agile Teams by Rathinakumar Balasubramanian

Introduction Agile places a huge emphasis on “people” who build the products. Agile Manifesto begins with an emphatic statement that it values ‘individuals and interactions over processes and tools’. The success of Agile projects largely depends on the team’s performance. It is not an overstatement that Agile teams either swim together or sink together. Building a high-performance Agile project team that delivers consistent results is the greatest of the mysteries for many Agile practitioners. This article unravels the secret recipe for building a high-performance Agile team and discusses the challenges in building a high-performance Agile project team. People Puzzles in Agile Teams According to authors Michael C. Mankins and Richard Steele in their August 2005 Harvard Business Review article entitled “Turning Strategy into Great Performance”, the average team achieves only 63% of the objectives of their strategic plans. This means about 37% of performance is lost due to various reasons. When it comes to Agile teams, they either achieve superlative results or fail spectacularly. Agile teams are ideally small in size. The optimal size for an Agile team is 3-9 members. Agile teams are co-located and prefer highbandwidth face-to-face communication. They are cross-functional and self-organizing in nature. They do not have command-andcontrol. So it is natural that Agile teams are expected to deliver a superlative performance. But the puzzle is not that easy in real life. Challenges in Building a High-Performance Team

Agile teams face enormous challenges by virtue of some of their very own characteristics. We will look at some of the major challenges in building a high-performance Agile team. 1. Trust Deficit When the team members trust each other there is open communication, a feeling of safety, and a free flow of ideas. In a low trust environment, communication gets blocked and progress slows down significantly. An environment of mistrust does not allow team work to blossom, let alone produce high performance. Trust deficit in the team is the number one challenge to building a high-performance team. 2. Lack of Ownership Team members should have accountability. Lack of ownership or accountability could be due to the team not having a unified vision. There may be no buy-in from the team members to the team goals and the team may be ducking the responsibility to work. 3. Organizational Culture The organizational culture plays a major role in how easy it is to build a high-performance Agile team. Does the team have a purpose in line with the organizational vision? Does the organizational culture promote competition or collaboration among employees? Does the organizational culture actively support team goals and team results ahead of individual goals and results across the board? If the answers are no, we are talking about an impediment to high-performance teams. A culture of command and control or micro management just does not help when it comes to making teams perform to their potential. 4. Fear of Conflict Many team members have a general tendency to avoid conflict. They perceive it as a virtue to ignore conflict or live with it. Avoiding or fearing conflict is not a solution. Avoiding conflicts instead of confronting them with constructive conversation is a sure sign of a low performance team. Conflicts bring a diversity of views and collective perspective to a problem. Building Blocks of High-Performance Agile Teams There are two fundamental building blocks for building a highperformance Agile team. High-performance Agile teams are built on a foundation of trust and are framed with collaboration.

page 41


Trust is the fibre of the high-performance team, and speed and trust are directly connected. In a high trust environment there can be a free flow of ideas, constructive criticism, and open communication, enabling continual improvement. In a low trust environment things slow down to a crawl. Trust is the foundation of a high-performance team. Stephen M.R. Covey, in his hugely popular book “The Speed of Trust” says “If there is one thing that changes everything, it is trust”. He points out that the ability to build trust with customers, bosses, co-workers, and subordinates is essential to business success. When trust declines in a team, speed will decrease, and cost will increase at an alarming rate.

When trust in a team improves, speed will increase, and cost will decrease.

culture’ or a ‘Kaizen attitude’, then we are surely looking at a highperformance Agile team with superlative results. ‘Learning culture’ refers to a culture of continuous improvement. It is this principle that transforms the ordinary team into a superlative high-performance team. The best teams have a self-driven zeal for relentless improvement (Kaizen) and look for any way to be more effective and efficient. Iteration reviews and retrospectives (iteration, release, and project) are classical tools or opportunities in the hands of a high-performance agile team. TRUST + COLLABORATION + LEARNING CULTURE = SUPERLATIVE PERFORMANCE Building a high-performance team in an Agile environment is not effortless. But the fruits of a high-performance team are worth the effort. Let us go and start building high-performance teams around us now. “The best time to plant a tree is 20 years ago. The second best time is today. ” – Chinese Proverb.

> about the author Rathinakumar Balasubramanian

Trust stems from mutual respect in the team. Agile teams respect everyone in the team. Respect is a value espoused by almost all Agile methodologies – be it SCRUM or Extreme Programming (XP). Collaboration is the superstructure that stands tall to deliver performance. In Bruce Tuckman’s Team Formation model of Forming – Storming – Norming – Performing, the team reaches the performing stage only when they collaborate among themselves. When there is collaboration, the team works as a single unit. A high-performance team always remembers that team goals are more important than individual goals. This will ensure that there are no egos or unhealthy competition within the team that can jeopardize the high-performance team environment.

is an expert in Agile project management methodologies. With more than 15 years of broad experience in traditional and Agile project management practices at organizations like Infosys Ltd., Accelrys Software Solutions, and Valtech India, he has coached and trained hundreds of project practitioners in Agile methodologies. His expertise includes transforming project teams to Agile delivery, building high-performance Agile teams, establishing Agile processes, managing Agile product development, saving troubled projects, and setting up PMOs. He has authored several white papers and presented insights on Agile project management to participants at various international project management forums. A certified PMP, PMI-ACP (PMI-Agile Certified Practitioner) and CSM

Secret Recipe for Building High-Performance Teams

(Certified Scrum Master), Rathinakumar currently heads the Agile Practice of SABCONS, India’s First REP.

Here is the secret recipe for building high-performance teams. An Agile team that thrives on trust and collaborates together, providing focussed momentum, will certainly be a high-performing team. Add to this the third and final ingredient called ‘learning and growing

page 42


Characteristics of an Agile Scrum Team by Rashmi Wadhawan

A cohesive and tightly coupled team with a cross functional skill set is a recipe for success in an Agile Scrum. Below are the key characteristics of a scrum team. Helping–Asking for help whenever you are stuck should be the first mantra for an Agile team. Gone are the days when people found solutions after spending long nights at the office. If you have spent more than half an hour on a problem and cannot find a solution, ask for help from other team members. Together you might be able to solve the problems in a faster and better way. You will also get an opportunity to learn from the other person’s experience. This give-and-take relationship will strengthen your team and help you create an excellent project. Proactive – Pick tasks whenever you have bandwidth. If you have finished your tasks, go ahead and take new tasks from the sprint backlog. There are no project managers allocating tasks to people in Scrum, every team member manages his/her own work. A proactive attitude to taking ownership of features and driving them to a successful delivery is the second mantra for an Agile team. Excellent Communicators – You should be able to express yourself. Every day you should talk about your work and any roadblocks you face. You should share impediments during the daily stand up meeting. Any ideas for overall process improvements should be shared in the sprint retrospective meeting. During sprint planning, you should be able to justify the story points identified for a story with good logical reasoning and detailed tasks thought through by you. Good communication is vital to your project’s success. Diplomatic – Human beings are bundles of emotions. You should be tactful and skilled in dealing with sensitive matters or people. You should raise interpersonal issues with caution and use proper language. You should say things in a polite and non-hurtful way. A good and closely knit team is a key success factor. Messages which are impolite or attack individuals could create unnecessary barriers within the team. Jack of All Trades and Master of Some – A true Agile team is cross-functional. Any team member should be able to perform or contribute to all tasks that might be involved in a sprint. In Scrum, there are only three roles: Scrum Master, Product Owner and Team Member. And as a team member, you should be able to make a contribution to tasks at all levels. There is famous saying in Scrum: “All pigs, i.e. Agile team members, are equal but some are more equal than others”. Team/People Skills – Pair testing, pair developments and pairing at dev-tester level are common ways of working together in Scrum. As an Agile member, you will be required to pair up with any of your team members. You should be able to gel well with people and perform. Agile teams create pair matrices with team members on the left and top sides. This helps them to see the pair collaboration within the team.

page 43

Avid Reader and Learner – You cannot keep on inventing wheels every time you have to build a car. As an Agile member, it is your moral responsibility to keep learning and make sure that you are not reinventing the wheel in your work. You should keep learning new stuff from the latest developments in the market through reading books or attending webinars. Fun Loving – As the sprint size is very small and there is a constant focus on delivering something usable every sprint, the team may feel some pressure to deliver. This pressure can be reduced by celebrating success. Go for a team outing after every few releases to enjoy yourselves and refuel so you can work at your full potential again. This will create a good and jovial working environment for the team. Empowered – The team has the power to select the scope of the sprint. They are the ones who provide estimates. They are the ones who make continuous improvements though continuously tweaking their project execution methodology. They are the ones who make all the important decisions which impact on delivery. Committed – The team is committed to the feature set to be delivered in a sprint. Once they have promised to deliver a particular scope, they will put all their efforts into fulfilling the committed scope. Additional tasks discovered during the sprint execution are absorbed within the team. Stand up for Each Other – A Scrum team supports its team members by taking work off other team members whenever someone is behind schedule or is stuck on a task. Ready for Change – A Scrum team is always flexible enough to accommodate changes to the scope of the upcoming sprint. They understand that nothing is fixed beyond the scope of the sprint which is currently running. And the only attribute that is constant about the product back log is that it will constantly change as per the business priorities. Upfront Designing – Scrum teams work in test-driven development. They write design for the feature through failed test cases. After the tests fail, they write underlying code to make it pass. Zero code is churned in sprints that do not have upfront test cases, i.e. design.

> about the author Rashmi Wadhawan Rashmi is Head of Quality Assurance and Centre of Excellence at GrapeCity India and has 12 years of experience in the software industry. She is a certified Scrum Master practicing the Agile scrum process in her projects. Prior to GrapeCity, she worked with Globallogic. She is an active member of the process improvement group at GrapeCity and is proud to be associated with one award winning product. She has played all kinds of roles in the software Industry including business analyst, technical lead and test architect.


The swing early bird Decem s its wings u to cat ber 23, 201 ntil ch it a 2 nd sa – try 400,0 ve up to 0 €.

March 4–7, 2013 in Berlin/Potsdam, Germany The Conference for Agile Developers Retrospectives on Agile – Forward Reasoning www.agiledevpratices.com

Masthead

ISSN 2191-1320

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

LAYOUT & DESIGN Díaz & Hilterscheid Lucas Jahn

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 Zeitschriftenverleger Berlin-Brandenburg e.V.”

WEBSITE www.agilerecord.com

EDITORIAL José Díaz

ADVERTISEMENTS [email protected]

ARTICLES & AUTHORS [email protected]

PRICE online 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.

ics or texts in other electronic or printed media is not permitted without the express consent of Díaz & Hilterscheid Unternehmensberatung GmbH.

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 duplication or use of such graph-

The opinions expressed within the articles and contents herein do not necessarily express those of the publisher. Only the authors are responsible for the content of their articles. No material in this publication may be reproduced in any form without permission. Reprints of individual articles available.

Picture Credits © nyul – Fotolia.com 1

© endostock – Fotolia.com 27

© pressmaster – Fotolia.com 4

© Andresr – istockphoto.com 30

© Peter Atkins – Fotolia.com 9

© adimas– Fotolia.com 37

© Chagin – istockphoto.com 13

© Daniel Kvarfordt – Fotolia.com 41

© arlindo71 – istockphoto.com 21

Index Of Advertisers CAT – Certified Agile Tester U2

Agile Record 26

SWE Guild 8

Online Training 35

Testing Experience 12

CaseMaker SaaS 40

IREB 17

Agile Dev Practices 44

Díaz & Hilterscheid 20

page 45
