Agile Software Development

What is your definition of a Scrum Master?

2011-11-17T15:36:00.001+01:00

We organize every month a Scrum Master guild meeting. This is a meeting where all the scrum master meet and discuss topics related to being a Scrum Master, agile, lean, etc. The topic of our last guild meeting was "What is our definition of a Scrum Master?".

I did some research (=read googled) on the internet to find out what the common definition of a Scrum Master is.

I found the following scrum master definitions:

Wikipedia

The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.

Scrum Alliance

The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner in the following ways:

Remove the barriers between the development and the product owner so that the product owner directly drives development.
Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
Improve the lives of the development team by facilitating creativity and empowerment.
Improve the productivity of the development team in any way possible.
Improve the engineering practices and tools so that each increment of functionality is potentially shippable
Keep information about the team's progress up to date and visible to all parties.

AgileForAll

A ScrumMaster removes impediments for the team. A ScrumMaster is a servant leader helping the team be accountable to themselves for the commitments they make.

TechTarget

A scrum master is the facilitator for a product development team that uses scrum. The scrum master manages the process for how information is exchanged.

BrightHub

The ScrumMaster is responsible for empowering the team to control over how they will perform their work. The team looks up to the ScrumMaster as a top athlete would look up to a sports coach. It is not only about knowing the SCRUM process, but also motivation and understanding the team’s psychology. The ScrumMaster's role requires more than basic project management skills.

Techopedia

Scrum masters serve to facilitate both product owners and the team. They neither have management authority, nor can they commit to work on the team's behalf. A scrum master may also be referred to as a servant leader. The scrum master is accountable for removing disorders so as to produce sprint deliverables. The scrum master acts as a buffer between the product owner and team, ensuring that the scrum process is used as intended. Scrum masters also enforce scrum rules within the scrum.

Mountain Goat Software

The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint.The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those meetings. The ScrumMaster role is typically filled by a project manager or a technical team leader but can be anyone.

ScrumCrazy

Acts as a servant leader to the Scrum Team and Organization, helping them to adopt and get better at Scrum.
Ensures impediments to Scrum Team delivery of high value software are removed.
Ensures that the Scrum Team adheres to the Scrum principles, values, roles, rules, and practices.
Helps Product Owners and Development Team members play their Scrum role, but otherwise does not in any way control or strongly influence how the software is developed and delivered.

ScrumMethodology

The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team

And the list continues... I read different kind of descriptions. Is the Scrum Alliance right or is ScrumCrazy right? Some definitions are even conflicting in my opinion. For example "the scrum master acts as a buffer between the product owner and team" and "Remove the barriers between the development and the product owner so that the product owner directly drives development.". You could argue Techopedia has no knowledge of Scrum Masters. I believe they have a very good knowledge of Scrum Masters (I never met Mr. Techopedia). Their description of Scrum Master is perfect for their organisation.

After reading all the definitions, discussing the definitions in our Scrum Guild Meeting, we came to the conclusion that the definition of Scrum Master depends on the organisation where the Scrum Master operates.

In our case, RES Software, a Scrum Master is someone who:

creates awareness of the progress of the team in the team
makes sure the team is removing their own impediments
makes sure the team lives up by our Scrum values
guards the scrum/kanban/etc. process
facilitates the team in managing their own project
focuses on the process, not the tools or engineering/testing/requiment/technical writer practices
is an example to the team, be on time, follow the process
has as goal to make the team self steering.

What is your definition of a Scrum Master or do you believe the ScrumAlliance is always right?

Pen and Sticky Notes

2011-11-09T08:56:00.001+01:00

Are you familiar with the concept of GTD? GTD is abbreviation of Getting Things Done. A famous book about GTD is the book "Getting Things Done" of David Allen. If you search the internet for GTD you will find a lot of information and tools you can use to realize GTD. Software that I use to realize GTD is Evernote and Remember The Milk.

One of the things David Allen describes in his book is always ask yourself "What's the next action?". I believe you should apply this concept also to meetings. Always identify a next action when you leave a meeting. If you have a meeting that lasts one, two or even three hours and you leave the meeting without any actions, you should feel uncomfortable...

Whenever I'm the chairman or facilitator of a meeting, I try to identify next action. In the worst case scenario a next action could be plan a meeting to identify the next action. I also try to delegate actions to other people, also one of the concept of GTD.

The following scenario happened to me already several times:
We had a meeting, identified several actions and we assigned the actions to the attendees. We left the meeting and nothing happened.... Where did it go wrong?

Not everyone has a GTD system implemented and I notice some people don't write down their actions. They left the meeting and most of the time they met someone or dived back into their complex software/test problem.

My solution is to help those people to set up a simple GTD system. As chairman or facilitator I take a pen and sticky notes with me. For every action we identify and assign to someone, I write down a stick note and hand the sticky note over to the person. He walks back to his desk with the note, it doesn't matter how many conversation he has on the way to his desk or how complex his current assignment is, he has a sticky note to remember him of the action.

This gives doesn't guarantee 100% success. However, it will help you in making sure actions are done.

Do you have any other ideas to make sure actions are done?

Some of my notes of the leader's workshop with Mary and Tom Poppendieck

2011-10-06T10:08:00.000+02:00

I attended the Leader's workshop of Mary and Tom Poppendieck. I already read their books. However, I thought it would be very useful to attend a two days workshop covering lean management. I was right, it was very useful and gave me new energy to start working to implement lean thinking at RES Software.

I made some notes for myself, thinks to think about, etc. I would like to share them with you instead of keeping them only to myself (I could also share my Evernote Note with your...), maybe it triggers you to think about things. To be clear, all credits go to Mary and Tom Poppendieck! There is no real structure in this blog entry, just a mind dump of my thoughts that could be useful to trigger something in you.

In the book Outliers, author Malcolm Gladwell says that it takes roughly ten thousand hours of practice to achieve mastery in a field. Did you ever met a developer or tester who worked in IT for five years and called himself a principal? Let's assume, a developer or tester is able to work 5 hours per day on software development of testing. 52 weeks a year, 52*5=260 potential working days, 25 days holiday (Yes, I know, we should not complain in the Netherlands), results in 235 potential working days, training, illness, and may public holidays, results in 230 working days. 230*5 = 1150 working hours per year. 10.000 / 1150 = 8,6 years... it will take at least 8,6 years for someone to become a master in his profession. Next time you meet someone who calls himself a principal with 5 experience in IT, you know he can't be a principal.

As we all know, you learn when you make mistake. What will happen when you work in an organization where you not allowed to make mistakes? Indeed, you will hide your mistake and definitively not spend much attention on the mistake. As a result, you will not take all opportunities to learn from the mistakes. As Lean manager you should create a culture where making mistakes is seen as an opportunity to learn. A mistake will give you a reason to spend time on improving the process/product. Make sure you take this change. Implementing this will require trust and courage, trust that you will learn and courage to make mistakes.

One of the attendees in the workshop said he asked his team members regularly how much happy time they had during the day. That's a question that could trigger some interesting answers... I would expect that when a developer has to answer this question he will count all programming hours as happy time. A tester all hours spent on improving the product as happy time. I'm sure a lot of meetings during the day, will bring the happy time down.

The Chinese wishers games proves (I know, not scientifically) that handovers cause loss of information. To prevent this, make you sure have all the required disciplines in your team or at least close to your team. The more handovers, the more loss of knowledge. Something like the graph below.

As independent software vendor (ISV) knowledge is your greatest asset, knowledge of the domain, knowledge of our software, knowledge of our processes. This knowledge in the heads of your employees. Therefore, knowledge == employees. We should make sure people like working at RES Software, and fortunately they do :). When employees leave, knowledge leaves. When knowledge leave, real important asset is leaving.

Some nice one-liners, or interesting statement to make you think:

Tom Poppedieck: "Source code is not for computers, it's for feature developers to change."...
All code that you write without an automated test harness is automatically legacy code...
Conway's Law: "Structure of your organization is displayed in your code"...

Did you hear about the three motivators according to Danial Pink? Watch this video, very interesting and you could use it to convince your management that giving extra awards based on production targets is not helping.

You should try to find T-Shirt shaped people for your people. T-Shirt shaped people? A person who is above average in for example testing, but is also capable of doing some basic programming and (because he is a native speaker of another language) he can do translations. This person is able to help also other disciplines in the team.

If you are interested in how to organize a large project with Kanban and Lean ideas, read this great paper of Henrik Kniberg. It's similar to Scrum From The Trenches, but this time about Lean.

Did you ever happen to be in a project that missed it's deadlines? That is turns out nobody believed in the deadline, but no one spoke out his opinion? A nice idea to prevent this comes from Henrik Kniberg. Vote how realistic the goal/deadline is every (two) week(s). Ask all team members to raise the number fingers they believe the goal can be met, 5 is absolute, 1 is totally not realistic. Write down the score and discuss the score, why does a person don't believe the goal is not realistic? Did you forgot about something, do you need extra capacity, redefine the scope, etc. One of the important things of lean is to make things visualize, this action visualizes the trust in of the team members in your project. It would be strange if you have a goal and no one of the team believes this goal is realistic...

I often try to explain to people why projects based software development is different than product development software. Mary and Tom Poppendieck gave me some new arguments to explain the difference. The key, in my opinion is, that product based companies go for increasing market share in the long term. A product based company is not interested in short term strategies, your goal should to be in the business for the 47 years. For a project based company success is most of the times defined as keeping cost/schedule/scope under control. It's not about a long strategy. The project ends but when the project ends the software doesn't end...

So far my public notes... if you have the opportunity to attend this workshop in the future I would advise you to do so. If you have any questions or you disagree with me, please comment. This gives me a opportunity to learn!

Meet your team members

2011-08-29T10:30:00.000+02:00

Imagine, you start as project manager on a new project. There are some issues with the project, that is also of course the reason why they hired you. You have a tool box full of agile experiences to get the project going again. Is individual meetings with your team members one of those tools?

If not, you really have to add the tool to your toolbox! As project manager or manager or any one who is leading a group of people, you should have regular peer to peer (P2P) or one to one(1-2-1) meetings with your team members. Plan 30 minutes, in room where you can discuss things privately. Make sure you have some room in your agenda in case the meeting takes more time. It would be a shame when you have to stop a good conversation about something personal or emotional because you have another meeting. No meeting can be more important than a 1-2-1 meeting! You don't have to create a formal agenda or minutes, it should be a free meeting to discuss anything you would like to discuss. Of course, are you allowed to think about the meeting before the meeting starts...

I hear some of you thinking, why should I plan a meeting? If we need to discuss something in our project, we will plan a meeting we already have so many meetings. In that case two remarks. Firstly, if you already have to many meetings, cancel all meetings and find out which one you really need. Secondly, in most cases you are too late... if one your team members would like to discuss with you that (s)he has an issue with a colleague, it's already too late. You should have prevented this to become an issue... Plan regular meetings, every 4 weeks for example. If you don't have anything to discuss your done within 5 minutes, otherwise take the time or even more time if necessary.

Why do you need to have P2P? Do you know what kind of project management style your team members like? Do they like freedom, just a global description of a task, or do they like to have small steps predefined? How are you able to facilitate/help/manage them if you don't know what they like?

Do you know what the core motivation is of your team members? Why do they come to the office? Most of them will say for the money. ok but what's there next driver. What are their personal drivers besides money? For example:

John loves to work in a team and deliver a great results with the team;
Jane loves to help other people, act as a coach;
George would like to get the best out of him self, be a winner;
Betty loves to work with new technologies, new concepts;

If you know the personal drivers of people, you also know which people to ask (not assign!) for which tasks. For example, who would you ask for team with several new team members? Betty is maybe not a good choice... I think Jane would be a better choice. There is a small project, to prove a new concept, who would you ask?

Of course, it's not always possible to ask everyone for his or her ideal task. However, when you have know what drivers are of people, you are able to motivate people.

As project manager you should regular ask feedback about your self. What should you start doing as a project manager and what should you stop doing? I could imagine you feel afraid to ask these questions in a team room. The 1-2-1 meetings are a perfect moment to ask feedback about your self. Additionally, also to give feedback to the team members.

I hope this blog helps you and that you will add an extra tool to your agile toolbox.

Please leave your comments, when did you had a 1-2-1 with your manager or team members for the last time? Was it useful?

Inspected with Pride

2011-07-19T08:15:00.001+02:00

I checked out my new laptop bag last week and found an interesting card my bag.

This card raised a few questions...

First of all, who is inspector 46... are there 82 inspectors working at the laptop bag factory, does every inspector has his own card, did inspector 46 really inspect my bag? I did some Googling... but inspector 46 is not very know on the internet.. he or she has a facebook page.

Secondly, would (s)he sometimes inspect bags without pride...? Would (s)he still add this card or does (s)he also have other cards?

Thirdly, what did (s)he inspect? Did only inspect the outside, the inside, did (s)he perform a stress test on my bag?

And last, would this be something for testers and/or developers to add to their software...

Imagine, the first time you open an application, it displays the message "This application has been tested with pride by tester 23", or when you open a menu item "This application has been tested and developed with pride by software development team Zulu".

Why not? I believe most software development teams don't get the credits they deserve. They only get the complaints and issue/bug reports from customers. How often did you contacted the help desk to give them compliment about with a new feature (and asked explicit to also compliment the development team) or contacted the development team directly to give them some compliments? How often do you see a development team on stage to get the applause of customers?

It's not in our nature to thank people. It's easy to complain. We, Dutch people certainly, are the masters in complaining.

I would like to ask you: Next time you work with software that you really like, or does exactly what you would like to do it (=Quality), send a mail or contact the development team and thank them explicit!

Or we could end up with all kind of messages in the application where development teams state how pride they are!

Things a Tester can learn from a Programmer

2011-05-03T13:31:00.157+02:00

UPDATE: This blog was also published as an article in Testting Experience, read the article here.

I sent a presentation with the topic Things a Tester can learn from a Programmer to the organization of Agile Testing Days 2011 in Berlin. Unfortunately, they did not select my session. However, I still would like to share the things a tester can learn from a programmer with you.

There is often a healthy rivalry between testers and programmers. Programmers never read the specifications, never test their own software, it always works on their machines. Testers, always are nagging about details, act as if they are the customer, and bother programmers the whole day with their questions.

I used to be a programmer and I'm currently responsible for test management in a development organization. (No Mr. Programmer, this is not a degradation ;) ) I discovered that it has some advantages as a tester when you were a programmer. I would like to share those advantages with you, maybe you recognize some of them or maybe it inspires you to think about some of the advantages and try to implement them in your organization.

Code Reviews
Most programmers do code reviews on their code. It is a very good practice and I think almost required when you do no pair programming. Goal is to improve the quality of the code and increase the knowledge a certain area.

As tester you should also implement reviews, review your test cases with programmers, customers and requirement engineers. Additionally, also automated test scripts should be reviewed.

When you organize code reviews, don't focus only on what the code does. For example, one person is the scribe, one person looks if the code complies with the guide lines, one person looks if the code is understandably, etc. The normal approach used by formal inspections.

Programming
If there is one thing that programmers are good in, it is programming and organizing a software project. (Or at least most of the programmers). Depending on your background as tester, you have to admit that programmers have more knowledge about programming as you. Brett Pettichord wrote several papers on test automation.

Test Automation == programming!

Use the knowledge of your programmers when you start with test automation. Ask one or more programmers to become part of the team/project group who will start with the test automation. This has two advantages, first they become also committed to the project and secondly you are able to use their knowledge about software projects.

When you set up test automation you should for example think about:

Version Control, where do you store your test scripts?
Labeling, do you label your scripts when you release software?
Project structure, do you create some kind of framework?
Project structure, are you able to work with multiple testers in the same project?
Language, how do you handle other language? Do your script support multi languages?
When do you update your test automation tool, at the start of a new release, during a release, one day before the end day of the project?

If it looks good then it is good
This section contains (some) prejudices, I already apologize on forehand.

Programmers don't care too much about the details. They focus on the main requirements and don't spend too much time on all the exceptions. As a tester it your job to think about all the exceptions.

Some times (I know I'm walking thin ice) a testers focus too much on the details and exceptions. Most software should be good enough, most software doesn't have to be perfect!

Gerald Weinberg description of quality is: "value of a product", extended by James Bach and/or Michael Bolton to quality is: "value of a product to someone who matters". With this description, it is possible to deliver a product that contains bugs in exceptional cases/some areas. If the user never uses those areas, he is not interested in spending too much time on testing those areas.

Be careful as tester to spend too much time on testing certain areas. Act as a programmer sometimes and don't spend too much time on testing in all cases.

(Ok, start flaming me about all assumptions I made....)

Pair Programming

One of the good practices of Extreme Programming is Pair Programming. Pair Programming is code created by two people working together at a single computer. Pair Programming has many advantages, and believe me, it's not inefficient.

As tester you could work in pair in two areas,

Pair Testing, read this blog of me about pair testing;
Pair Programming. create test automation scripts with two testers working at a single computer;

Test Dojo's
I'm already applying my next section, be lazy... ;) Everything about test dojo's is already here.

Be lazy
A good habit of a good programmer is, laziness. He hates repetitive tasks and always tries to automate boring and/or repetitive tasks with macros, scripts or (custom made) tools.

I often see testers who do a lot of repetitive tasks, for example install a new version of the software every morning, scan log files for errors, create complex reports with standard reports, etc. Why not start up your machine at 6.00am and start automatically an AutoIT script to start the installation, create a tool to scan your logs automatically or create some SQL statement to export the data to Excel?

Be creative and ask support of your programmers to automate your boring daily routines.

Use Patterns

Every programmer know the Gang of Four and the book they wrote, Design Patterns.

A pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. My definition of a pattern is: a predefined described solution for a problem that occurs often.

Programmers use design patterns very often, a pattern that is often used is a singleton.

Why not create test patterns for tests that you have to test frequently? It's not about features you have to test every release. It is about problems that you frequently face, and that can be solved by the same approach every time. Read some information on this blog about software test patterns.

How to write good comments
As programmer I wrote and read a lot of comments in the code. Some example of comments (in pseudo code) you often see are:

//If a < 1 then calculate a new value for X
if a<1 then calculateX;

try
CalculateNewDate;
except
//If an exception occurs during calculating of new date we raise an exception
raise E.Msg("Calculation new date has failed");
end;

Tell me, what is the value of this kind of comments? This is the so called how-we-do-it comments, adding no value. Every programmer can read the statements above, it has no value to describe the statement again in the comments.

A good programmer writes why-do-we-do-this comments. For example in the above code, he describes why a should be less than 1 and why he raises an exception.

As tester always try to write why-do-we-do-this comments, in your test scripts and in your automated test scripts. How you test, that is clear, describe why you are testing the software.

Conclusion
Let's end this blog with a conclusion...

I know I used a lot of prejudices and assumed also a lot.... but try to ignore the prejudices and all assumptions and see if there is something you can learn from the programmers.

Did I miss anything, or did I exaggerate too much... please leave a comment for me.

My Essential Tools

2011-04-29T16:26:00.001+02:00

I have some tools installed on my machine that I use regularly and make my life easy. Maybe you already know some of those tools, maybe not... any way I write this blog to share them with you. Here are the tools, in random order:

7-Zip, despite all the terra bytes available, I still need some times to archive files, the tool I use is 7-Zip. An open source tool, and also capable of opening java ear files for example;
AutoIt, essential for me to automate anything I would like to automate. Read this blog for more information;
Belvedere, keep your desktop or any other folder on your hard drive organized and under control with Belvedere, an automated Windows file management tool. Use Belvedere's friendly interface to create advanced rules to move, copy, delete, rename, or open files based on their name, extension, size, creation date, and more;
Wink, wink is a tutorial and presentation creation software, primarily aimed at creating tutorials on how to use software (like a tutor for MS-Word/Excel etc). Using Wink you can capture screenshots, add explanations boxes, buttons, titles etc and generate a highly effective tutorial for your users. I personally use Wink to create movies to show programmers the reproduction steps for complex issues;
Desktops, Desktops allows you to organize your applications on up to four virtual desktops. Read email on one, browse the web on the second, and do work in your productivity software on the third, without the clutter of the windows you're not using. After you configure hotkeys for switching desktops, you can create and switch desktops either by clicking on the tray icon to open a desktop preview and switching window, or by using the hotkeys. Most Virtual Desktops applications on Windows have the disadvantage that some applications still show up on other desktops, no with this app!
Everything, Everything is an tool that locates files and folders by filename instantly for Windows.
Unlike Windows search Everything initially displays every file and folder on your computer. You type in a search filter to limit what files and folders are displayed. Only one disadvantage, it only works on local NTFS volumes;
MultiMon, very useful application when you multiple monitors. It adds a second taskbar to your extended desktop on monitor 2 and only shows the application in the taskbar from that monitor;
XpDesktopHeap, when you have memory issues with the app Desktop, use this application to increase your heap size;
Notepad++, a very very very powerful text editor. Don't use Windows Notepad, use this application!
Paint.net, I'm not very experienced with photo editing. A basic tool for me, is Paint.net. Paint.NET is free image and photo editing software;
ProcessExplorer, a very very very powerful task manager. It is showing much more information then the Windows task manager. A must have for every professional Windows user, certainly for people working in software development;
Snippy, sometimes less is more. With this application (only works on Windows XP) you can easily create screenshots or copy parts from the screen to the clipboard;
SpaceSn iffer, SpaceSniffer is an application that lets you understand how folders and files are structured on your disks. By using a Treemap visualization layout, you have immediate perception of where big folders and files are placed on your devices;
Oracle SQL Developer, SQL Developer is a free and fully supported graphical tool for database development. With SQL Developer, you can browse database objects, run SQL statements and SQL scripts, and edit and debug PL/SQL statements. It not only supports Oracle, it also supports MySQL, SQL Server, MSAcces and partially Sybase;
TranslateCli ent, a free translator for Windows which enables the fast translation of text in the most applications, such as Web Browsers, Office apps, Messengers and etc. using the Google Translate service;
XMind, an open source to create Mindmaps. It looks nice and is very user friendly to use;

That are the tools that I used, besides Skype, Office and Chrome. By the way, the order was not completely random...

If you have any tips for me please leave a comment with the tool I really should use.

Bug Hunt Sessions

2011-04-08T15:47:00.000+02:00

In our development process we expect teams to do all testing necessary to deliver quality software. One of the disadvantages of our approach is that all product backlog (PBL) items are tested by testers (or if necessary and possible programmers or requirement engineers) from the team who also builds the software. In most cases this is not a problem. However, sometimes it could really improve the quality when others testers (or programmers, requirement engineers and/or technical writers) from other teams test the software.

There are some PBL items that don’t need to be tested by other teams, like business rules. However, PBL items:

that could affect client of server performance;
that could affect user interface of for example a Web client (that can't be tested automatically);
are about usability;
that are high risk;

are candidates to be tested also by other teams. However, in a Scrum environment every team has his own planning.

We introduced the Bug hunt sessions.

A regular meeting, every two weeks where everyone is free to step in and do some testing. Teams are able to report PBL items that can be tested in the bug hunt sessions. It is a regular meeting of one hour, the impact on the planning is low. Therefore, other team members are willing more easy to participate.

The approach of Bug Hunt Sessions is:

We introduce the concept to all development employees and ask who is interested to participate in these sessions;
We plan a recurrent meeting, every two weeks on Friday from 11:30 – 12:30 CET (16:00 – 17:00 IST);
When a team has a subject for the bug hunt session, they inform all teams and publish a link to the information required for the participants;
One day for the session, everyone is reminded again;
The bug hunt session will be started with a short introduction (maximum ten minutes) by the team who send in the topic using for example GotoMeeting. If a team needs more than ten minutes to explain the topic, it is too complex for the bug hunt session;
The session starts, maximum one hour. During the session the organizing team is available for support;
All findings are reported to the organizing team by email or Skype. The organizing team creates the calls and filters out any double reported calls;
The person who will find the most valuable call(s) will be Mr. or Mrs. Bug-Hunter until a new session is organized :)

We are organizing the first session the coming months, as soon as we have some experiences I will share them with you. And of course we will improve our approach after every iteration, bug hunt session.

Are you already familiar with such a concept? Do you you believe everything should always be tested by only the team who develops the software or should there always be an independent tester be involved? Please leave your comments.

Send Skype Messages Automatically to publish the Tip of the Day

2011-03-24T11:09:00.000+01:00

I work in a project with testers located on different sites. Additionally, at one site they are also located in different rooms. I always prefer face-to-face communication, but be honest, sometimes a group chat is also very effective to quickly find the answer for your question. Questions are, which team worked in this module, why are all automated test suites failing, etc.

We use Skype as communication tool and Skype has a feature to set up a group chat. We use this as a virtual test room, where testers can meet and ask questions. It is not intended for peer discussions.

In our last How-Did-We-Miss-That-Sessions we identified some tips for testers. I could send those tips to the testers once a week, or publish them somewhere on our intranet. However, I don't believe testers will read a tip document on the intranet and I will forget to send the tips every week.

The solution is to automatically send a chat with the tip of the day to the virtual test room, the Skype chat were all testers are present. I have created a small script with AutoIT, using the Skype API to send a tip of the day every day to the group chat. I have scheduled this script automatically with Windows Task scheduler and it reads the tip of the day from a text file.

I have included the script and text file I use in this zip file. Feel free to use it and adapt it to your own specific situation. For more information on how to use AutoIT and the Skype API read this thread on the AutoIT Forum.

If you have any questions feel free to contact me!

just a Development Department

2011-03-16T19:24:00.003+01:00

This blog describes my current vision, important values and the required focus of an agile software department. This text is not a silver bullet, it is my personal vision. It is a summary of my experiences, blogs, knowledge and ideas. It is based on visions of, for example, Jeff Sutherland, Mary Poppendieck, Micheal Bolton, Jurgen Appelo and others.

What is the goal of a Software Department

The primary objective of a software development department is to deliver, on a regular basis, quality software using a light-weight process.

Regular: when a product is not released on a regular basis, there is no link with the business. In today’s markets, it is required for almost all organizations to be able to deliver new features on a frequent basis.

Quality: quality is the value of a product to someone who matters. A product that does not deliver value to a user is of low quality. A product could have several bugs and still have much value, the other way around is also possible.

Light-weight process: a development process should be based on a light-weight process framework. It should contain no or as little overhead as possible. There should be a process in place that teams can rely on; a process with clear and meaningful process steps. It could be Scrum. However, any light-weight process is possible. The process should empower teams to deliver software.

What Kind of Process?

Software development is a creative and empirical process. It is not possible to compare software development with, for example, construction work or an assembly line. It requires a different approach when you need to solve problems. In most cases, it is not possible to use common root-cause analyses. Problems in a software development process require, in most cases, systems thinking.

Trust in Employees

I believe you should trust your employees. You should trust employees that they deliver the best possible within the given constraints of the available processes and tooling. When teams, processes and tooling are stable, the output will be stable. There will be some variation in the output. However, this is statistic variation.

Measuring Productivity or Creating the Possibility to be Productive

In books and blogs, people talk about hyper-productive teams. When is a team hyper productive? I believe measuring the outcome of a team is not how you determine if a team is hyper productive. As management, you should create a hyper-productive environment for development teams. I wrote a blog about this topic. Below is a short summary.

The most important environment variables are:

Constantly Improving;
Good Preparation;
No Dependencies;
Have Fun.

In the sections below you will find more information about the above values.

Constantly Improving, A team should constantly improve themselves, remove impediments constantly. A software development process is never stable, technique changes, requirements change, the organisation changes, knowledge of people changes, everything changes;

Good Preparation, Agile or not, you need to prepare your work before you start working. I believe when product backlog (PBL) items are well prepared, the team is able to have a high velocity. Preparing PBL items for me is enough communication between team and product owner. The team should clearly know what the goals are of the PBL items, it should be clear what the product owner expects and there should be some rough ideas about the technical solutions.

No Dependencies, Dependencies between teams increase communication. Communication is difficult, there are a lot of blogs/books/articles about how difficult communication is.

Have Fun, when a team doesn't have fun, it will never become hyper productive. Are you motivated to do something that you don't enjoy? Fun is not only telling jokes, fun is much more for example: good hardware, a comfortable Office, appreciated by colleagues or management.

When all the above is in place, I believe a team can become hyper productive. How do you know when your team becomes hyper productive... you will know trust me, trust your own gut feeling.

Transparency

Management should be as transparent as possible. It is dangerous to think employees are not able to handle certain information. When something is decided or not, and the information about the why is lacking, people will make assumptions. This will often lead to a lot of unrest. It also implies that you think your employees are not capable of handling certain information. Again, this is not showing that you trust your employees. There are of course situations when information is not ready to be shared with employees, such as some financial data, discussions about reorganizations or issues related to individuals.

Standard Process

As said before, a process is important. You should strive to have standard processes in place that are used, and therefore understood, by all teams. As soon as there is a standard process, an organization will always be able to rely on this process. It should always be possible to deviate from the standard process. However, when there is a standard process in place, it is possible to deviate. When there is no standard process, every deviation could be the standard.

Teams Versus Individuals

I speak about teams and not about individual programmers, testers or technical writers. This is with reason and not without. No individual is able to deliver software alone. Building and delivering complex software is something that needs to be done with a group of people, a team. Individuals are not able to deliver the same quality software as teams are. When you have a good team, 1+1 = 3 or even more.

Discuss or Just Start...

Starting to use a new tool, process or building a new product is difficult. However, it will never be a success when you only talk about it. When something new comes in, discuss it shortly and start using it or build it. After the first days/weeks you will have gained new insights and you will be able to make better decisions. Additionally, you could use retrospectives to improve the team or process.

Scrum Evolution

Many teams start using Scrum or any agile method leaving sometime between the iterations. The time between the iterations is used to finish up the old iteration and to prepare the new iteration. When a team is able to finish and prepare the iteration during the iteration, the time between the iterations is no longer needed. A next step is to prepare every product backlog item when it is needed and to start working on the product backlog item when it is possible. In this last scrum variant, the team slowly moves to Kanban. A Kanban process delivers new features continuously. This requires a very high quality automated environment of for example test automation and build environments. It should be possible to deliver software at any moment in time.

Conclusion

This blog described several important aspects of software development. It is my current vision. However, this vision can change every day, week or month. I try to continuously improve myself by using the feedback from my environment. Is there currently an organization that has all of the above in place, probably not? Most important, however, is to realize that in most organizations, there is always room for improvement. The most important thing that an organization can achieve, is to realize that there is almost always room for improvement and that the organization is willing to improve.

Made a mistake: "I should not push the team"

2011-03-04T13:07:00.000+01:00

I don't know why, but I would like to share my mistake (during work time) of the day/week with you. Maybe to prevent you for making the same mistake. On the other hand, I made the mistake already a few times in my career as scrum master. Maybe confessing this mistake to the world, and you, prevents me of making the mistake again. However, I'm afraid I will the mistake again somewhere in the future.

You are probably wondering what did I do? I'm coaching a new team, they started two months ago and are all experienced with working in an agile environment. I thought I'm a great scrum master, and I know how you should work together as a team.I know what is important for you....

Hmmmmm, could be... I tried to (indirectly) convince the team that they should work as I think it should be. No surprise, they disagreed... and they are absolutely right!Who am I to say how they should work/communicate... is there any issue in the team currently? No, there isn't... why should the team than work as I think they should...

It resulted in discussion, that absolutely had no value. After the discussion, with only losers, I took a cup of coffee and did a short retro on myself. The conclusion is in this blog.

And now? I will take a few steps back from the team, let them find their own way. And as soon as they encounter an issue, in the process, communication or something else I can share my experience with them. It is then up to the team to decide how to improve. And I think discussing the issue with the team is already enough for them, they probably don't need my experience. The only thing that I should do is facilitate the team to discuss the problem and find a solution. I should trust the team that they are capable of organizing them selves, and deliver quality software with a controlled process.

I know how a scrum master should act, I know that telling people what to do doesn't work, I know I should have trust in people. Still, I make this mistake sometimes. Hopefully for the last time, if not I already apologize to you for the situation when you are part of a new team that I coach. Just remember me to this blog, "I should not push the team".

Hyper productive..., don't measure the outcome

2011-03-01T16:03:00.000+01:00

Scrum is great, when implemented successfully it gives you several benefits. One of the benefit that is also often mentioned is hyper productive output of your development teams.

I read several blogs about hyper productive and I could not find a real definition of hyper productivity. It is not defined as x % more output than current output. What if a team improves themselves and only the quality is improved? Is the team become hyper productive? What if you have a team with freshers and one team with the most experienced team members of your organisation, can both teams become hyper productive? I believe that measuring the outcome of a team is possible but if this proves if a team is hyper productive... I don't believe so.

After some discussions with companies/organisations like Bol.com and reading books/blogs about Lean (management) last months I came to conclusion: "You should not measure the outcome, but create the environment to become hyper productive". An organisation should do everything to set the team in position to score. If the team is able to score you should have trust they will score the goals.

I believe a team needs the following to become hyper productive:

Constantly Improving;
Good Preparation;
No Dependencies;
Have Fun.

In the sections below you will find more information about the above values.

Constantly Improving

A team should constantly improve themselves, remove impediments constantly. A software development process is never stable, technique changes, requirements change, the organisation changes, knowledge of people changes, everything changes. When a team does not improve themselves, by adapting themselves to the new environment they will not benefit from the new opportunities and even be slowed down when new impediments arise.

Good Preparation

Agile or not, you need to prepare your work before you start working. I believe when product backlog (PBL) items are well prepared, the team is able to have a high velocity.

I hear you thinking, what is well prepared? Do I need to write a complete functional and technical design of 42 pages? I would say it depends.... However, I tend to say no :)

Preparing PBL items for me is enough communication between team and product owner. The team should clearly know what the goal is of the PBL items, it should be clear what the product owner expects and there should be some rough ideas about the technical solutions. The team should be able to create a work breakdown structure that consists out of tasks of maximum eight hours.

Of course, there will be situations where a team prepares a PBL item and something unexpected happens during realization. That's life, you have to deal with it. That's why constantly improving is important, the team should perform a retrospective on the situation. What can they learn from it, how can they improve?

No Dependencies

Dependencies between teams increase communication. Communication is difficult, there are a lot of blogs/books/articles about how difficult communication is. The search term Communication results in 376.000.000 hits in Google, Communication difficult results in 124.000.000 hits... it is allowed to say 32% of the page about communication is about how difficult communication is?

When you have multiple teams that are dependent on each other, the team with the lowest velocity will partially determine the velocity of other teams. The customer teams have to wait until the supplier team delivers their PBL items. Additionally, when there is one supplier team for multiple customer teams, who comes first?

Another dependency could be on the product owner who has the requirements not yet clear.A team could start working on the PBL item. However, when the product owner is not available, or needs to discuss the requirements first with the real customers, the team can't continue. When they continue there is a risk they have to do rework. They have to wait until the requirements are clear, this kind of dependencies will stop the team to become hyper productive. It is also in conflict with the previous precondition, preparation.

Have Fun

When a team doesn't have fun, it will never become hyper productive. Are you motivated to do something that you don't enjoy?

Fun is not only telling jokes, fun is much more. To have fun you should have for example:

Good Hardware, fun is not waiting for a software build that takes 22 minutes;
Office, Windows in the office, air condition during a warm summer, a desk that is adjustable in height;
Appreciated by colleagues or management. When did you receive a compliment for the last time? Didn't it make you feel good? The power of giving and receiving compliments is ofter under estimated. However, giving and receiving compliments does often increase the fun in the team.

When all the above is in place, I believe a team can become hyper productive. How do you know when your team becomes hyper productive... you will know trust me, trust your own gut feeling.

During writing this blog I already changed partially my vision. Please leave your comments, I don't mind changing my vision again when it becomes a better vision.

Incremental development versus Iterative development... what is what?

2011-02-22T13:20:00.001+01:00

There are a lot of blogs and articles about the differences between incremental and iterative development. In my opinion it does not add much value to write again about the differences :)

However, I saw two pictures last week that clearly state the difference for me. The pictures are displayed below... (the pictures on this page are used with permission of Jeff Patton).That's why I wrote this blog, to share the pictures with you and give you some links about the incremental and iterative development. If you are new to agile development, it could be interesting.

Incremental development, every iteration you add a piece of the complete picture. The picture is ready when all iterations are done.

Iterative development, you deliver a picture and decide if you would like to continue to extend the picture.

There are some interesting and good blogs about the incremental and iterative development:

Blog of Jeff Patton, http://www.agileproductdesign.com/blog/dont_know_what_i_want.html
Wikipage, http://en.wikipedia.org/wiki/Iterative_and_incremental_development
Alistair Cockburn, http://alistair.cockburn.us/Incremental+versus+iterative+development3
Article of Pascal Cauwenberghe in Methods & Tools, http://www.methodsandtools.com/archive/archive.php?id=14

When you have read the above pages, you should have a good understanding of what incremental and iterative development is.

Share your vision with you employees to empower them

2010-12-27T12:53:00.000+01:00

When you would like steering teams and employees to make decisions that are in line with the vision of the organization, make sure they know the vision!

I had a short discussion with a colleague last week about if we should leave a decision over to a team or should come with a proposal our selves. I had to make a compromise with him in the end. You read my arguments to leave the decision to the team in this blog.

I believe in self steering teams and empowering the knowledge of your employees. Assuming you have qualified people in your project, you should do everything to use their knowledge and experience. You as, manager or as management team have limited knowledge because you are alone or just with a small group of people. The more people think about an issue, the better the solution. You could make a decision or a proposal for an improvement and discuss this improvement with your employees to get feedback. However, it will be your decision or proposal, it will never be completely owned by the employees.

I believe you should be as transparent as possible in your vision or goals of your organization. When the employees know your vision or goal, they will come up with proposals to reach this vision or goal. Additionally, they will feel owner of the improvement and will do almost everything that is in their power to realize the improvement. If they disagree with the vision or goal, they could decide to leave the organization. However, I think you prevent this if possible because this could be waste of knowledge.

When you are not transparent in your goal, it is almost impossible for your employees to come up with proposals for improvement. You can't empower people when you have a secret or hidden agenda.

It is the partially same as with children. When they do something that is not allowed, for example playing with fireworks. You tell them they are not allowed to play with fireworks, but also why it is not allowed. Even better is to explain why they are not allowed to do something before they would do it.

Please leave your comments…

Distributed Agile Project Teams

2010-12-20T16:27:00.171+01:00

Nicole Belilos and I gave a session called "My Buddy Is Over The Ocean" on the XP Days Benelux 2010. We had some good feedback on our session.

As we don’t like presentations with lots of text, the slides of the session don't contain much information. Therefore, we wrote this short summary to share our experiences. If have questions or remarks please contact us, we will always respond!

Distributed Approaches
There are several distributed approaches possible. For example:

Most of the team members are located in one site, and one or maximum two individuals work from another location;
The team is completely distributed, with all team members working from different locations;
The team members work from two locations, for example Netherlands and India.

Why work in distributed teams?
When you read books about agile software development, all books explain why it is important to work co-located. So why then would anyone choose not to work co-located?

There are several reason to work distributed:

Expansion. When it is hard to find qualified employees in your local country, it could be argument to start working distributed. For example, every year millions Chinese students graduate from university. Therefore, it is relative easy to find well qualified employees over there;
Historical. More and more organisations are merging to combine their powers. As a result, these companies end up with employees working from different sites;
Support. When you need to support multinationals like Shell, Philips, etc. you need to have support 24/7. When you have multiple sites across the globe, it is easier to give 24/7 support, without need for one site to work 24 hours a day.

Distributed. Yes, but...
Suppose you have been working in a distributed team and you have finished the first couple of iterations. Chances are that you have had the following thoughts:

They never say what they really think;
There are always so negative;
What is this English they speak?;
Oh no, the Internet connection is down again;
We never get what we asked for;
They really don't understand what is working with such a small bandwidth;
They don't treat us a equal;
I have to work in the middle of the night.

In our session we gave our experiences with the above problems and also some tips.

Building a Team
We believe building software starts with building a good team. This is the same for co-located as well as for distributed teams. Building good software with seven individuals on your team is a problem, whether they are co-located or not. True team work is the basis for good software.

However, building a true team in a distributed environment is difficult. There are several challenges you have to face.

Travel
Distributed teams members must travel! When you are able to meet each other frequently, you will be able to build a better team. Even if it is possible to build a team via Skype, the best thing is to see each other in real life.

Although travelling is important, you can't expect people to fly constantly between sites. Travelling costs a lot of energy, especially when it is across multiple time zones. Also, most people don't like to be away from their family or private life for longer periods of time.

When you build a new team, try to co-locate all the team members for several weeks and have them work together. The primarily goal should not be to transfer knowledge, but to get to know each other. When new team members join an existing team, the same approach can be used to quickly integrate those new members.

Time Zones
The greater the number of time zones involved, the more difficult it gets. How do you plan a meeting when you have people working in the USA, Europe and India? It is almost impossible to plan a meeting during everyone’s regular office hours.

A common solution is to share the pain. Plan the meetings at different times, so that one day the USA people must get up early and India should stay in late, and the other day it’s the other way around.

When you have an office in Norway and India, you will notice that the overlapping time slots are always filled with meetings. Therefore, it is important to always plan local meetings around those shared time slots.

There is no real solution for working with multiple time zones. But make sure it is not always the same people who have to stay in late or come in early.

Cultural Differences
There are thousands of books on cultural differences. It is a fact that many cultural differences exist, not only between different countries, but also within countries and even within companies! As a rule of thumb, accept cultural differences, respect each other and enjoy the differences!

Meetings
Unfortunately or fortunately :), it is not possible to develop software without communication. There are several meetings that are part, in some form, of every agile method:

Stand-up, a short informal meeting to inform each other in the team;
Planning, a meeting with the team to plan a new iteration or user stories;
Demo, demonstrate the software with the (proxy) customer to generate new input for the next iterations;
Retrospective, a meeting to evaluate the last iteration or to discuss certain issues in the team;

Is it just a matter of switching on a web cam?

Language Barrier
In most projects the common language is English. However, there are a lot of different English accents...You probably are able to understand the English your colleague speaks. However, is someone from the other side of the world also able to understand your English, with your local Russian/Indian/Dutch/French/German/Kenyan accent?

When you use phone or software to communicate, be aware that it could be even more difficult to understand your English.

Meeting Guidelines
While all meetings benefit from good facilitation, distributed meetings need it even more. Make sure you have clear meeting rules. Below is a good example of a set of meeting guidelines.

Phone Conferences

Allow time for connecting;
Strict time boxed and facilitated;
Use a good phone and head sets;
Let everyone announce himself;
Start with 5 minute chitchat;
Announce your name before you speak;
Take turns when speaking. Don’t interrupt a speaker;
Listen and don’t work on other things at the same time;

Video conferences

Allow time for setting up;

Have a strict agenda;

Use good web cams and audio;

Spend 5 minutes to actively ‘see’ each other;

Point the web cam to the person who is talking;

Two rooms: have a facilitator in each room;

One room and x remote people: Have a ‘web cam buddy’ in the main room;

Stand-up & Planning Meeting
The Daily Stand-up and the Planning Meeting have a lot in common. Make sure you have a good web cam and a good microphone. Make sure everyone is visible on the web cam. Try to always use the web cam; receiving visual feedback is very important. Does everyone understand what you are saying, is everyone paying attention and/ or are they making notes during the meeting? Is a planning meeting without making notes possible...

When you have a planning meeting it is advisable to have a separate machine to share the desktop, documents, tools, etc. Make sure you have one dedicated machine for the communication tools and another machine for the project information.

A site that could be useful is http://www.planningpoker.com/, especially when you have all team members working from different locations.

Demo software
The meeting to demo the software is a challenge. This depends on the number of teams in the project and the number of distributed locations.

When there is just one team working on the project, and this team is located in just two locations, the demo is relatively easy. Make sure the customer knows you are working distributed and is able to speak English. When the every team member is located at another site, the demo meeting will be more challenging. How do you share your desktop with all team members and the customer? Are you able to use web cams with multiple locations?

When you have multiple teams working on a project, how do you demonstrate the software to all teams and customers? How do you facilitate discussion? How can everyone hear the people who are together in one room? You could use a wireless microphone. Then make sure only the team member or customer holding the microphone is allowed to speak.

When you want different team members to demonstrate parts of the software, you have to switch the presenter mode regular. How do you prevent this from becoming a bottleneck or annoying part of the meeting?

There are a lot of issues that could occur during this meeting. Make sure you prepare it well, that includes the software and hardware for communication. Additionally, you should have a good chairman or facilitator for this meeting.

Make sure the primary goal of the meeting is still there. Demonstrate (potentially) shippable software and discuss the software to generate insights for the new iterations.

Retrospective
If you think the demonstration meeting is hard, the retrospective is even harder! We believe a good retrospective is all about doing things together and about communication. 55% of communication is done by body language. As a facilitator it is important to be able to observe the people who attend the retrospective. This is very hard to via a web cam.

A retrospective should be very interactive if possible. But how are you going to have an interactive retrospective when the team is distributed? You find a nice example in this blog.

The distributed retrospective is a real challenge, but when you, as a facilitator, prepare it well, it is still possible.

Tools
Tools could be a great help or a burden when you use the wrong tools. Additionally, tools won't solve any problem in the process.

In this section we share some of our experiences with tools. If you know some extra tools, just add them by entering a comment.

Infrastructure & Development Tools

CVS versus VSS, we used Microsoft Visual Source Safe 6.0 in the begin to store our documents. VSS is not build to be used in a relative slow network, make sure you use a source control system that is build or at least optimized to be used in a distributed environment. Take a look at the tools that are used by open source projects, they often use tooling that is build to work in distributed projects;
Sharepoint, use an Intranet system or content management system to maintain documents;
Web Enabled Bug Tracking System, using a fat client could not be a good idea when you a relative slow network;
Remote Desktop, take over a system in another location with RDP or for example VNC to only transfer screen information and not all data;
Citrix, all your applications in your own virtual desktop environment.

What else... your experiences...just add them by adding a comment.

Communication Tools
We make a distinction between software and hardware:

Software

Office Communicator
Skype (Free), Skype 5 with multiple video streaming!;
Mikogo for desktop sharing (Free);
GotoMeeting (Not for free), on-line meetings;
Yammer, Twitter for inside a company, share information via an informal way;
MeetingPlace, on-line meetings;

Hardware

Conference phone, these phones are optimized to be used in hands-free mode;
web cam (HD and Wide Angle), don't save money on this... it is important to see all people in a meeting and to be able to see if they are happy or anger;
Headsets, it could happen you have to wear them for a few hours... make sure they are comfortable;
Wireless microphone for large meetings, to be able for everyone to join the discussion;
Dedicated communication corner in team room, a team should be able set up a meeting in a few meetings. When they have to walk to another room, it is to much effort and the team will not meet to discuss a topic;
Meeting rooms with fixed communication corner, it should be possible to meet easily with people from different teams or with the product owner and people from another site;

Planning & Tracking Tools
The number of planning and tracking tools is growing every year. A classic Scrum board that doesn't use a network cable should always prefer above any software tool if possible.

Possible tools are:

Excel / Google docs to keep track of progress;
Jira / Greenhopper plugin;
Take photo's of a Scrum board, print them and sitck them to the wall;
VersionOne/ Rallydev / Scrum works / Mingle / etc.

Conclusions
Do you need to bring back your buddy? No really..... if possible yes. If is not possible,
you should really invest in the team and make sure you use the most efficient tools for
your organisation.

Working in or with a distributed team is not easy. However, it is possible with hard
labour!

XP Days Benelux 2010

2010-11-29T16:46:00.003+01:00

Last week I visited the XP Days 2010 Benelux. a great conference! It is informal, everyone is open for discussion and real down-to-earth! A compliment for all attendees and the organisation. It was held in Conference Center Kapellerput, a very inspiring location in the lovely state Noord-Brabant, Netherlands.

This blog is a short summary of the sessions and my experiences on the conference.

The conference was opened at nine o'clock, and after some yoga and basic information the half-minutes-presentations (HMP) started. The presenter or organizer of a session/workshop is given 30 seconds to do a short promo about his session. Some promo's are straight forward, but some are really nice to see. A good start of the conference day, and a concept that should be used on more conferences.

After the plenary opening, Nicole Belilos and I prepared our own session. Had some discussion about the content by using Skype, while we sitting next to each other :). At 11:00 our session started. We, Nicole and I, experienced it as a good session. Of course, there is always room for improvement. Read the feedback on this page, if you attended our session and have would like to give some (extra) feedback please send me an email.

The lunch was great, as always in the Kapellerput. I had some time to catch up with a friend of my during lunch.

During the afternoon I attended the kanban workshop. In our group we did not experience the real Kanban experience. However, I made some nice frogs and had a a good time during this weekend with my daugther, folding frogs. I liked the idea of the Kanban workshop, for more information look here. I think the reserved time, 1.5 hours, was too short for a good workshop.

My second workshop in the afternoon was about a testing journey. I was hoping to see something new that we could use in our own test process. Unfortunately, this was not the case. However, I think the workshop gave a good overview to all people who were not familiar with a agile testing process. How do ET and Unit tests compare to each other for example.

The next day started again with some yoga, basic information and HMP's. My first session was about an introduction to value stream mapping (VSM). I already read something about VSM in the books of Mary and Tom Poppendieck. Still, a good session of the guys of iLean. I need to find some time to do some VSM at our organisation, trying to find some bottle necks in our process.

The second session I attended was about retrospectives. The first part of the session was about how retrospectives fit in the continuous improvement organisation of lean (I understood correctly..) and the second part was based on the book of Agile Retrospectives of Ester Derby and Diana Larsen. It was not really new for me, still a good session. Doing retrospectives is not easy, you need to facilitate and select different activities to prevent the retrospective to become a boring meeting with no value.If you would like to read something about distributed retrospectives, take a look here.

After another great lunch and catching up with Peter from iLean the last workshops started.

My first workshop was about feedback, Agile Feedback. Is Agile Feedback different from regular Feedback? No, only in an agile environment you are encouraged to give feedback. The session was about how to give and receive feedback. It was refreshing and remembered me to give active feedback to people. Feedback is a gift, and you should always be grateful when you receive feedback. It is an opportunity to improve yourself.

The last workshop of the conference was about team building using theme centered interaction.I really liked the part where you were able to learn about your team mates. However, I had some trouble to imagine how to use this approach in my daily work. I assume it was because it was already Friday afternoon and I had some problems concentrating. Some basic information about this topic can be found on the wikipedia.

During the sessions I met some nice people to share experiences with. Additionally, gave some advise to people, or at least my idea about the problem. I'm not able to give advice in a 15 minutes meeting ;)

Summary... two great days. As said at the start of this blog, I always like the good and inspiring atmosphere at the XP Days. It not only about coding, also about the soft skills that you need in a a (software) project.

Dojo who? Short introduction to Dojo's

2010-11-05T08:57:00.001+01:00

During the Agile Testing Days 2010 in Berlin I attended a presentation of Marcus Gaertner. He mentioned Testing Dojo in his session. I already heard the term Coding Dojo and was already interested to find out if it is possible to set up a Testing Dojo. To find out, I first started to find out what a Coding Dojo exactly is. I wrote a short memo about this and here is the result.... If you think I forgot something in my description, please leave a comment!

~~In a next blog I will try to describe how I think a Testing Dojo could be organized.~~ Marcus already wrote a excellent blog about a testing dojo. I will refer to this blog about what a testing dojo is, what you need and how to organize is.

This blog is based on the following resources:

· http://web.cs.wpi.edu/~gpollice/Dojo.html

· http://codingdojo.org/

· http://en.wikipedia.org/wiki/Randori

· http://en.wikipedia.org/wiki/Kata

Some other interesting links are:

Introduction

Testing is a skill, to become a master tester you need experience. You increase your experience by doing your daily work as a tester. Every day you will encounter new problems where you need to apply your existing knowledge to solve the problem. When the problem is solved, you have increased your knowledge and experiences.

To increase your knowledge as a tester you should meet with other testers. When you share your ideas of testing with other testers you will receive feedback. Feedback that makes you think about your testing approach.

It is your own responsibility to become an experienced tester. You should take initiative to grow as a tester, not wait until someone delivers the knowledge to you.

A testing dojo combines the things described above. You actively work on a challenging problem, meet with other testers and take your own responsibility in becoming a good tester.

In the sections below I try to describe what a Dojo meeting. It is a introduction for people who are not familiar with a Dojo meeting.

Dojo

A Dojo is a place where people come to improve their skills. Most common is a Coding Dojo. As important as improving the skills, it should also be fun!

The idea is people meet for a time boxed period, with a computer attached to a beamer or desktop sharing tool installed and a challenge. What kind of challenge will be discussed later. During the session the group works on the challenge. Remember it is time boxed, when time is up, the Dojo ends.

In a Dojo everyone is equal, there is no difference because of experience. A junior person could learn from an experienced person and an experienced person could learn from the fresh look of a junior person. Everyone should be respected for their knowledge and contribution to the Dojo.

The idea of the Coding Dojo comes from Dave Thomas's idea of Coding Kata. Laurent Bossavit's instituted a Coding Dojo in Paris where it has been running on a weekly basis since January 2005. It has been a weekly programming get together where programmers of varying skill levels meet as equals. The Coding dojo is not dependent upon any specific programming language. Often one person may exhibit a solution to a challenge one week in C++ and the next week, another member might solve the same problem in Ruby or .Net. The goal is to learn.

Forms of Dojo Meetings

There are two types of Dojo meetings, Kata and Randori. The description of both words according to Wikipedia:

Kata (型 or 形 literally: "form") is a Japanese word describing detailed choreographed patterns of movements practised either solo or in pairs;
Randori (乱取り) is a term used in Japanese martial arts to describe free-style practice or sparring, sometimes with multiple attackers. The term literally means "chaos taking" or "grasping freedom," implying a freedom from the structured practice of kata.

A Kata Dojo is session where someone solves how to solve a problem. The presenter thought about the problem in front of the meeting but did not do any work. In the Dojo the presenter creates the solution whereby everyone is able to see what the solution is. Every step the presenter takes should be clear for everyone, as soon as it not clear it should be explained to the group. During the Dojo the group should comments on the solution with the goal to improve the solution. In the end the group, including the presenter, should have the best possible solution with the knowledge available. It is wise to have some breaks during the Dojo to discuss in smaller groups the possible solutions.

In a Randori Dojo the whole group participates in creating the solution. By using pairs, two persons are constantly working on the problem. Every pair works time boxed, for example seven minutes. When this time box ends, the person (driver) who was controlling the keyboard and mouse, goes back to the audience. The person (navigator) who was thinking out loud and reviewing the work of the driver, becomes the driver. A new person from the audience becomes the new navigator.

Rules of Dojo
There are some simple rules you could follow when organizing a Dojo. It is wise to shortly evaluate every Dojo when it’s done and change the rules if necessary. There is always room for improvement.

Positive comments
Goal is to learn and everyone is equal. Try to give positive comments, it should be focused on improving.

Slow Down
Everyone should be able to follow your steps. Don’t rush, make sure everyone understands your steps.

Interrupt when it is not clear for you
When you see something happening what you don’t understand, ask a question. Goal is to learn, don’t assume you are the only one who does not understand what is going on.

Think out loud
The presenter or pair should think out loud. The group is not able to anyone’s mind. Therefore, explain what you are doing and why you are doing something.

Agenda and Facilitator of Dojo
It is wise to assign a facilitator. The facilitator should create an agenda and if necessary prepare the room, computer, etc. Make sure the agenda has also a time table, a Dojo is a time boxed meeting.

During the Dojo the facilitator should make sure the rules are followed. It is up to the facilitator to decide if he also would like to part in the Dojo.

An example agenda:

2 minutes: decide on date for next session;
30 minutes: solve the problem;
5 minutes: mid-session break to discuss how things are going;
30 minutes: code some more;
13 minutes: quick retrospective of the session.

Keep an eye on your log

2010-10-25T10:52:00.002+02:00

A great way to improve the testability of your software is to add logging! A log with all errors, warnings, faults, exceptions, dialog messages, or whatever is interesting for you in one file!

For most programmers it is relative easily to build in logging. When an application has a single class/procedure/library to handle errors, it is easy to build in logging. Depending on what you log it could become very easy for programmers to find the causes of crashes/bugs. If you are able log all user actions, it is just a matter of walking through the log file for the reproduction steps. Additionally, not all problems are visible in the GUI, sometimes a problem is only reported in a log file or some strange output is written to the log file.

However, when you have several servers up and running (database, application server, web server) it could produce a lot of logging. Testers are also humans.. so it could happen that you miss an important message in the log....

James Bach recognized this problem and wrote a small application in Perl to watch the log automatically. A great tool. However, the tool has some issues (for me):

When you have several logs to watch, an application is started for every log file. As a result, the Windows task bar is polluted by extra programs on the taskbar;
When you start the application, the old log is also watched. As a result, all already know issues are reported;
Only explicit audio feedback, when the application is minimized there is no visual feedback;

I wrote a tool in AutoIT, with some improvements. The new tool has the same basic functionality as the tool of James Bach. However, the improvements are:

The application is no longer visible in the task bar, it is visible in the notification area;
When the application is started, it does not parse the existing log content;
There is also visible feedback, by using a dialog;
The option to open the log file directly from the notification icon;

Feel free to download this tool and use it or change it to your personally requirements. I'm still working on this tool and improving the tool. However, this version is ready to be used by you.

File	Description
audio_logwatch.bat	An example file to start multiple instances of logwatcher.exe to watch files.
error.wav	Sample wav file, that gives you the raspy voice of James Bach during a bout of bronchitis.
license.txt	The program is released under the GPL 2.0 license.
logwatcher.au3	The source code of the program.
logwatcher.exe	A compiled version of the script, ready to be used.
readme.txt	A file with some information about the tool and credits to James Bach.
watchlist.txt	The file that contains the patterns to look for in the log files.

Automate your daily (test) work with AutoIT!

2010-10-25T10:36:00.000+02:00

I think it is good habit to be lazy... with the intention to automate as much as possible of your daily work. For example:

Every night a full integration build is delivered, and as a tester you need to install this every morning;
You need to configure some files before you start an application;
Simple regression testing;
In general: you need to do x when y happens or to start doing y;

There are a lot script tools or programming languages that you could use. One of my favorite scripting languages is AutoIT.

The official introduction text from the AutoIT Site:

AutoIt is a freeware Windows automation language. It can be used to script most simple Windows-based tasks.

AutoIt has been in popular use since 1999 and continues to provide users and administrators with an easy way to script the Windows GUI. In February 2004 the latest version of AutoIt - known as AutoIt v3 - was released and added powerful scripting features.

AutoIt v3 was developed in a small team with the help of contributors around the world and this has led to a great set of help files, examples, support forum, mailing list, editor files, and third-party utilities. Oh, and lets not forget some nice graphics and wallpapers too!

AutoIT has a great support forum, it is almost possible to find a solution for all of your questions related to AutoIT. It has a lot of standard procedures, but also options to call Windows API's directly (Not sure if that would make your life easier...). Another nice feature is the option to compile your scripts into small executables. It gives you a relative small (approx. 350k) application that contains all required libraries and can be distributed easily in your project/organisation.

I'm going to publish the tools/scripts I build with AutoIT on my blog. Feel free to use them and to improve them for you personal use.

My Thoughts about Test Certification

2010-10-13T11:59:00.002+02:00

It is a real Indian Summer in the Netherlands and while I'm ironing the laundry (Yes, I sometimes take my responsibility as modern man ;) )and looking out on the garden, I'm thinking about the certification discussion on the Agile Testing Days in Berlin.

What is certification? According to the Oxford Dictionary:

a document confirming that someone has reached a certain level of achievement in a course of study or training

That is a real good description and ends the discussion I think....;) It does not say anyone is capable of doing something.When I translate this to ISTQB, somewhere in space, somewhere in time, you were able to answer the questions about how ISTQB thinks testing should be.

Anyone who saids (s)he is a good tester, because (s)he is certified is lying. (S)He could be a good tester and have a certification. It is comparable to a driver license, you are allowed to drive a car when you have license, you are not a good driver. To become a good driver you will need experience, a lot of experience.

I think it is good when a tester follows the training of ISTQB. The tester will, probably, learn new techniques, improve his techniques and is able to meet other testers. Discuss testing with other testers! The certification exam is not necessary, attending the training and discussing testers with other testers is already very valuable! We are doing agile for already six years and have developed our own agile approach, it works perfect for us. A lot of things you learn during a ISTQB training are not applicable to our approach. However, it makes you as a tester all round and more experienced.

I have to confess, we valued certification a lot in the past. We were wrong! Why, read the text above. Still, I think following the training is useful. However, instead of doing certification I will ask testers after the training to write an article, blog, present something at a congress, etc.. By participating in the testing communicty, they will discuss their vision/approach with colleague testers. That is much more valuable then a certification!

People who are attending certification programs are investigating in their capabilities as a tester! That is the really good thing! I think certification it self is not the right approach. It is up to you to convince those people having a certification is not the right approach.

During the session of Markus Gärtner about Alternative Paths forSelf-Education in Software Testing, Micheal Bolton made a remark that the real certification comes from the community. If you are appreciated by the community by writing blogs, articles, giving sessions, you are "certified". I agree with that remark. However, not everyone is able or has the capability to be active in the community. You could of course, follow blogs, read books and attend congresses. However, how do you get that explicit reward of the community? That is something that is still bothering me. I think feeling rewarded for your knowledge is important for professionals. Some of those professionals believe certification is such a reward, not! How do the testers that follow the community get rewarded for there experience? I don't know... I hope someone will write a blog or acticle or point me to article that covers this issue.

I hope this blog helps you forming your opinion about certification and I hope your feedback will help me build my opinion.

Oh by the way, I used ISTQB in this article. You could read any organisation that is doing certification, not only ISTQB.

Agile Performance Testing - How we integrated it into our process

2010-10-08T19:22:00.001+02:00

I would like to share my experience with agile performance testing with you. It is not about the knowledge of a tool like LoadRunner itself. it is about the process to set up a performance testing environment and how to embed it in your agile process. I had a session about this topic during the Agile Testing Days 2010 in Berlin.

This blog is a summary of that presentation, this is the second blog about how to integrate performance testing into your agile environment. In this blog I described how to set up an agile performance environment.

With performance testing we would like to do two things:

Teams should be able to deliver features that are done, including performance testing;
Detect regression;

If all development teams would need a time to do performance testing just before we release the software, we would need several weeks extra at the end of the release. Sounds like a waterfall approach isn't? We would like to have all user stories/product backlog items/features to be done at the end of the sprint. Done is including testing, documentation etc. Testing is including performance testing.

As soon as we had the Loadrunner framework in place, we trained all teams. All testers attended the training and everyone who was interested. Several programmers attended also the training. In the training they learned how to build scripts and how to execute them in the performance test environment.

We have identified two types of scripts, sprint scripts and weekend scripts. The sprint scripts are build by the teams to verify new features and weekend scripts are to detect regression.

Sprint Scripts

The goal of sprint script is to test a feature. We have the general requirement that the client always should respond within four seconds. In some cases the product owner has extra performance requirements.that need to tested. During the sprint planning it is discussed for features if a performance test is required. Reason could be for example a change in the framework. It is discussed with all the members of the team if a performance test is required.

If it is decided that a performance test is required, the testers build script. If necessary they use integration tests to generate data or request a customer database. The testers verify the scripts on their local machine and as soon as they are ready, the scripts are executed in the performance test environment. This is environment is available during weekdays for the teams. The new scripts are added to the cvs database.

The scripts have a lifespan of one sprint. The scripts are not maintained when the testing of the feature is done. If the new feature is important, that is determined by the team, product owner, lead architect, for the project or product owner, the scripts could be promoted to the weekend scripts or the weekend scripts could be expanded to cover the new feature.

Weekend scripts

The second goal of the performance tests environment is detect regression. It could be possible that a team develops a new feature that impact the global performance of the application. They did not think about writing a sprint script and did not expect any impact on the performance.

For these case we have developed weekend scripts. Weekend scripts detect regression and trend data is generated. As a result, we are able to see if the performance increases or decreases during a release of six months.

The weekend scripts cover the most import areas of our software. These areas are discussed with the architects, testers, product owner and lead architect. Goal of the weekend scripts is not to test everything. However, we try to test the 20% of the code that generates 80% of the generic performance problems.

The technical test engineer (toolsmith) is responsible for writing and maintaining the weekend scripts. He is supported by the development teams.

The weekend scripts are automatically executed during the weekend. The reporting process is explained in the next session.

Weekend scripts have a life span of multiple releases and need to be maintained. When the software changes, the weekend scripts need to be changed also (only when the change impacts the scripts of course).

Report Integration

In our organisation we use a lean principle, when there is an error in the production line, first fix the error, then continue the line. The teams first fix the failing automated tests, discuss the open problems found during development and as last start working on new features. When something fails in an automated tests or is reported as a problem, it is automatically processed in the process.

When a weekend script fails, this could be because of an error or the response time is to long, an call is created in our bug tracking system. The bug is assigned to the team responsible for the module. When the team comes in on Monday and discussed the open bugs, the bug reported by the performance test is automatically discussed and assigned to a team member. During the week the team will fix the bug, and in the next weekend the test will run green or fail again.. in the second case they are two bugs assigned to the team.

The problems found during the execution of sprint script are not reported automatically. These test are executed by testers during the sprint and any issues are handled during the test execution.

Conclusions

The advantages of this approach:

We don't need any extra testing when we deliver a new release. All the testing is already done during the sprint and the regression tests are executed every weekend;
Testing has become more attractive for (some) testers. Our testers are also executing performance tests, they have expended their work experience.

What did we learn:

teams still need support of the technical test engineer or more experienced testers. Especially when testers are doing performance tests the first time, Loadrunner generates a lot of data... where to look for the possible problems.
it is expensive to set up performance tests, mainly the time and also the licenses costs. Of course depending on which tool you use. Be wise, and determine if you are going to setup your own performance tests or use external capacity;

We made the right choice by implementing performance tests in our project. I spoke to an tester from an test company and they did some performance tests on our software for customer. They didn't find any issues.... that made me happy.

If you have any questions after reading this blog... please leave a comment or send me an email.

Agile Performance Testing Presentation

2010-10-08T10:56:00.001+02:00

This is the presentation I used during my session on the Agile Testing days in Berlin 2010. Read the background information of this session in this blog.

If you have any questions please contact me! Exchanging experiences, asking questions and answering questions is a great way to learn.

Agile Testing Days 2010 Berlin, part 2

2010-10-08T10:44:00.000+02:00

Back home... as already stated in my first report, it was a great conference!

It started with the keynote of Michael Bolton, several slides/visions were already discussed during this tutorial that I attended on Monday. It always surprises me how difficult people find it to answer the question what is quality.... I love the description of Micheal and James Bach: "value of a product to someone who matters". The description of testing that is used by Michael is also surprising simple and powerful: "testing is an investigation/exploration to get information about the quality of a product". I agree with Micheal that automated testing is very useful, but not the only thing that should be done in a project. I recognize the problem that testers focus too much on test automation and spend not enough time on exploratory testing.

I loved also the analogy between testing and CSI. Testers provide the data for the judge (In the Netherlands we don't have a jury ;) ) to make a verdict. Of course, the CSI investigators work closely with the police and judges. Testers work closely with the programmers (We are all developers, testers, technical writing, programmers, we all develop software) and customers.

The presentation of Gojko Adzic was a great statement against certification. He changed his presentation the night before and it was great. Check out twitter and all the blogs that are write about his presentation. One of the main topics during the conference was the discussion about certification. To state the general feeling: when you attend the scrum master certification for two days, you are certified Scrum Master... are you after two days a Scrum Master who is able to coach and improve a team... I don't think so...

Lior Friedman had good session about feedback. To summarize... agile is all about feedback and by making the steps smaller and smaller, you are able to get feedback sooner. As a result, it is possible to improve your self after every step. In the end he showed a tool to that automatically runs the unit tests that are affected by a code change. A very interesting tool, I will do some research and find out if there is an comparable tool for Java.

The last session I attended was of Markus Gärtner. He had a session about self educating, and is of the opinion that a tester should take his own responsibility in become an experienced/skilled testers. I totally agree with that. In his session he showed several ways how you could improve your self as a tester. For example http://weekendtesting.com/ and organizing Testing Dojo's.

It was my first time on the agile testing days. However, I hope not my last!

Agile Testing Days 2010 Berlin

2010-10-05T21:29:00.000+02:00

Perfect and great sessions... I'm thinking what I should say about the Agile Testing Days (ATD) 2010 in Berlin... it is great to meet and discuss agile testing with so many testers, developers, coaches, people who are interested in agile testing.

I attended a workshop of Michael Bolton on Monday. A lot of information on one day... he was doing the highlights of the Rapid Testing course in one day, normally this course takes three days. It was a very good tutorial, definitely worth the money and time. Some things I picked up from this session:

testing == gathering/developing information;
in agile environment is important to gather information as fast as possible;
humans have the nature to learn, that's what brought us to the 21nd century.. as a tester it is your task to learn thing about the software.. and you get even paid for learning things every day!
as a tester you are helping the team and customer, doesn't it give a warm feeling to help people? You get paid to help people ;);
it is good to have testers with different backgrounds.. diversity is good. You will find more bugs and issues when people have different backgrounds;
it is not your job as a tester to give a value about the software under tests, just provide the information to the stakeholders;
automated tests, they tell you when you're not done... They don't tell you when you are done. When all tests are green, you're not done testing;
every testers, will focus on the "" correct pattern".. you are looking for tests that confirm your findings... try to break that think pattern, test something that is not logical;

The first day of the conference was also very interesting, key notes of Lisa Crispin, Linda Rising and Elisabeth Hendrickson. Great key notes, some highlights of the keynotes:

Key note Lisa Crispin:

When you are not going to fix a problem, remove the problem from your bug registration system;
Only register bugs when it adds value, not because it is required;

Key note Linda Rising:

Difficult to explain, but is was great and fun!

Key note Elisabeth Hendrikson

She is really a good presenter, she had the last key note at 17:40!. Everyone was awake and paying attention!
The set up of the office is important, see also my blog about that topic;

I visited several interesting sessions during the day. A session about acceptance test driven development using Robot Framework by Pekka Klärck, Error Driven Development by Alexandra Imrie and Structures kill testing creativy by Rob Lambert.

Spoke with several people and exchanged ideas about agile testing. Got an introduction about testing in open source projects by Peter Vadja. Discussed distributed scrum with a person from Ctco. Realised that it is important to find out what the root cause of a problem is, despite good symptom fighting.

To summarize in one word... great!

Agile Performance Testing

2010-09-24T20:24:00.001+02:00

I would like to share my experience with agile performance testing with you. It is not about the knowledge of a tool like LoadRunner itself. it is about the process to set up a performance testing environment and how to embed it in your agile process. I had a session about this topic during the Agile Testing Days 2010 in Berlin. This blog is a summary of that presentation, this is the first blog about how to set up and agile performance testing environment. In the next blog I will describe how you could embed agile performance testing in your process.

For this moment I will assume:

you have implemented Scrum or some kind of comparable Agile project management method, and the implementation is successful;
quality is important in your organisation, if possible you first fix quality issues before you start developing new software;

How to set up Agile Performance Testing

One day you go to the office and decide to implement agile performance testing. Why? There could be different reasons, for example:

a customer found serious problems related to performance;
you would like to take no risk before you deliver software and would like to be certain there no performance issues;
you need to spend you yearly budget on software and decide to buy an expensive performance tool;
you start developing a complete new architecture and would like to monitor the performance from the start;

Where to start...

The first step should be of course to write down you requirements for the test tooling. There are several requirements when selecting a tool, for example:

what kind of technology are you using, or planning to use in the near future;
who is going to perform the performance tests, experienced developers or functional oriented testers with very less programming knowledge;
it is possible to monitor the things you would like to monitor, CPU, Memory, Hits per second, etc;
does it need to integrate with an existing tool, for example create automatically incidents in your incident system or link to requirements in the requirement management system.

Write down the requirements and perform research by surfing on the internet, reading magazines or visit congresses. The "normal" procedure for selecting a new tool or buying software. If possible try to arrange a demo of the performance test software in combination with your software. On paper everything is possible, always prefer to see live software with the features implemented that are important for you.

As soon as you have a tool selected, the next step is training. Quality should not only be the responsibility of the testers, the whole team should be responsibly for quality. Therefore, not only testers should attend the training, also the developers and the technical test engineers. Everyone should know what the possibilities are of the performance testing tool. Try to use your own software during the training. If you encounter problems, you could directly discuss them with the trainer/consultant.

If everything went well, you have a tool selected and trained the people. Time for the next step...

It is my opinion that all team members should be able to build performance tests. Record and play functionality is nice. However, most of the times it doesn't work or it is hard to maintain. This is because you are using the application structure directly in your test scripts. Therefore, you should build, if possible, a framework to build performance tests. The framework should be a layer that hides the application structure for the the person who creates the performance tests. The framework could be developed by some developers and testers in the team. In general, developers tend to have more knowledge about setting up a good framework then testers.

Almost there, we have a tool, team members are trained and a framework is there.... in my next post you will read how you could embed agile performance testing in your process.

Play the Game, Discuss Agile Specifications

2010-08-05T20:25:00.022+02:00

Imagine the following situation: There is project team of two developers already working for several months on a new and complicated feature of an Enterprise application. There are a lot of interfaces and they are doing agile, so documentation is not necessary....Management decides to speed up the project and adds two engineers and two testers. They still believe that when a woman delivers a baby in nine months, nine women deliver a baby in one month ;) You are the scrum master and you have the challenge to speed up the process...

I experienced this situation half a year ago. The major problem was lack of knowledge for the new team members. The team decided that all team members should be able to do all tasks. There should be no specialization, or at least as less as possible. Additionally, we decided to take the time to spread the knowledge. Knowing that investing in knowledge would pay of in the next iterations.

We started with some classic knowledge transfer (kt) sessions. The developers who were involved from the beginning explained how the system worked, using a whiteboard. Some knowledge was transferred. However, you already probably know that experiencing something is much more efficient way to learn then just listening to someone. At the end of every kt session the new team members said they understood the model Did they really understood the model or did they understand the what the presenter said... I decided this was not the way to go, the new developers and testers learned the system. However, it went to slow.

I read somewhere sometime something about bringing a model to life. (I can't remember where, if you know where please let me know). We played the Game. Remember, building software should also be fun and listening to someone explaining a model is not fun! Every team member represents a sub component or external component, during the game team members communicate with each other as the software would do.By playing the component itself, they experience the software itself.

After several kt sessions the new team members knew all different components and the basic interfaces. That was at least something we realized with the kt sessions ;). I assigned every developer to a basic component of the model. Some developers had to be assigned to more than one component. The testers were assigned to different user roles.Everyone looked forward to the meeting, they were excited and curious how it worked out. Until this meeting, no one looked forward to have a kt session.

The preparation was arrange a meeting room with an digital white board and enough space to walk around the whiteboard. Make sure every team member knew his role during the game.

We started the meeting, and the testers started the first simple cases. Simply, acting like a user and requesting data or entering new data. The developers accepted the request and passed the necessary data to the next component. The receiving component processed this data, and so on. The end of the chain was that a developer/component gave feedback to the tester. During this first round I wrote down the communication between the components on the whiteboard to make some kind of documentation/minutes.

In the next round the testers asked more complicated cases or "entered" incorrect data. The different component had to handle this incorrect data and give the correct feedback to the users.

The last round was to understand the recovery functionality. What happens when one component is not there? In this case it was just a matter of "removing" a developer from the game. The other components had to handle this correctly and again give the correct feedback to the user.

The game was a success. Everyone liked the game and the set-up. However, the most important was that all team members finally really understood the system and the complexity. They experience the system! The outcome was also some graphical models that the team members used to discuss improvements in the system.

All people involved will need some basic knowledge of the system. Therefore, some classic kt sessions are still necessary. Additionally, you will need support of management. If your team is expected to work only and have no kt session meetings... We called the meeting the Game...some people knit the brows when they heard we planned a game. Maybe it could help if use name the session kt session about .

The Agile Office - Part 3, Fun

2010-07-27T22:13:00.056+02:00

I gave a presentation about the Agile office on the Benelux XP Days 2009 and an improved version on the Mini XP Days 2010 in Rheeze, near Eindhoven. For the improved version I created an survey to collect data about the use, benefits, advantages, disadvantage, etc. of the agile office. I am still interested in extra data. Therefore, if you have time please fill in this survey.

In three articles I will explain what I think an agile office is. There are three elements important in an Agile Office:

In this last article I will discuss fun in the Agile Office. It is the smallest article of this thee articles. However, fun is probably most important ;)

If you have any questions, remarks, disagree, etc. please let me know! I understand that most of these topics are also nice to have in a not agile office. However, I think they should be really there in an agile office.

No Clean Desk Policy

People like to personalize their environment. We decorate our house with the furniture and accessories we like, we wear the cloth we like, why not personalize your desk the way you like? In some organisations there is a clean desk policy and employees are no allowed to personalize their desk or office. I think every employee should have the possibility to personalize his work environment. By doing this you feel at home and create an inspiring environment.

There is of course a difference between personalizing and a mess... the picture on the left side is far beyond personalizing.

Hardware

You are expected to deliver the best software possible, work as efficient as possible, create happy customers... is it not logic to have good tooling to do your job? I think it is very frustrated for a engineer to do his work with outdated hardware.

The hardware of an engineer should be at least what is required for a customer. In most cases it should be even more, especially when you are working in a multi-tier environment. You probably have an application server, database server, web server running at your local machine. This set up requires hardware that is more then average. For example, a solid state drive could boost your improvement.

Two monitors could also increase your happiness. You could use one monitor to display the application and the other monitor to display the IDE or test automation tool. There are several reports on the internet to prove your manager that multiple monitors improves efficiency. In most cases, when you are able to work more efficient, you also have more fun in your work.

Relax

Organize a soccer table, dartboard, ping pong table, Wii, at least something to relax during work time. Building, testing, describing software is an intense process. You have to be concentrated and focus on your work. There should be an option to relax during the day. A manager that believes you are concentrated the whole day, fools himself.

Make sure you set up a separate game room or at least don't disturb people who are working when you're relaxing.

The Agile Office - Part 2, Nature

2010-07-21T21:54:00.003+02:00

In three articles I will explain what I think an agile office is. There are three elements important in an Agile Office:

In this article I will discuss nature in the Agile Office. If you have any questions, remarks, disagree, etc. please let me know! I understand that most of these topics are also nice to have in a not agile office. However, I think they should be really there in an agile office.

Climate Control

Most countries have a seasons with different temperatures, in some countries it is always a summer and in some other countries it is almost always winter. A comfortable temperature for humans is between 20 °C and 25 °C. Without climate control the temperate in the office will be determined by the temperate outside. There will be days that the room temperature will be between 20 °C and 25 °C. However, there will be certain days that the room temperate is below or above a comfortable temperature.

An agile office should have some kind of climate control to make sure the temperate is in the comfortable zone during the whole year. When thinking about a climate control system, keep in mind that an agile office should be a team room. There will be more then two people working in the room, people also generate heat.

Every office should have climate control, not only the agile office of course! However, when you have to set up an agile office you should definitely not save money on the climate control.

Windows

We all lived outside, or at least our ancestors, 10.000 years ago. The last two centuries factories and office buildings have been build. In terms of evolution this is all on very short time scale.Therefore, I believe we are connected to the weather outside. When the sun shines, most of the people are happy and when it rains we are not happy.

Working in an office without any windows to experience the weather is something people don't like. 88% of the people who participated in my agile office survey really valued experience the weather outside. The photo of the office, in this section, where you don't see any windows doesn't look very motivating to me.

If possible, an agile office should have windows to experience the weather outside.

When you have a lot of windows in your office, you should also have some kind of climate control to control the temperature when the sun shines. See the previous section.

Chairs

As already described in the previous section, humans are not "designed" to work in an office. Therefore, the best chair is a bar stool, it is not comfortable. Therefore, it guarantees you will walk around and not site whole day in your chair.

Make sure there are desk chairs in the agile office that can be adjusted to your personal requirements. On the photo above you see some desk chairs that are ok for a meeting room, not for a workplace.

When you have flexible workplaces in your agile office, make sure you have also adjustable desk chairs for those workplaces.

Desk adjustable in height

As you probably knew, not every person has the same height. Therefore, every person needs a different desk height. It should be possible to adjust the height of the desks to create an ergonomic workplace.

When you have flexible workplaces in your office, you could consider a desk that is automatic adjustable in height. Just enter the height and press the button and the desk will adjust itself.

The Agile Office - Part 1, Communication

2010-07-16T21:12:00.004+02:00

One of the most important aspects of software development, as not the most important aspect, are the team members. The people who have to build the software. You could come up with all kind of processes, documents, methodologies, etc., in the end the team members have to build the software. Therefore, I believe the agile office is a very important aspect of software development. I would not say good software development is not possible in an agile office. However, the other way around is certainly true. A a real agile office stimulates good software development.

I gave a presentation about the Agile office on the Benelux XP Days 2009 and an improved version on the Mini XP Days 2010 in Rheeze, near Eindhoven. For the improved version I created an survey to collect data about the use, benefits, advantages, disadvantage, etc. of the agile office. I am still interested in extra data. Therefore, if you have time please fill in this survey.

In three articles I will explain what I think an agile office is. There are three elements important in an Agile Office:

In this article I will discuss communication in the Agile Office. If you have any questions, remarks, disagree, etc. please let me know!

Whiteboards

One the most important things in an agile office is a whiteboard. An agile office really needs one or if possible more whiteboards. The boards should be close to the engineers (Engineers are testers, developers, everyone working the development team), to make it easy to go to the whiteboard and start a discussion. When an engineer needs to walk ten meters, the step to use the whiteboard in a discussion is too high. The boards should, ideally, behind the engineers.

Make sure you always have some personal markers at your desk. How often did you not go to a whiteboard to find out there are no markers or all markers are empty... When you have a empty marker, throw it away immediately please.

What to do when you had a discussion and there are important notes on the whiteboard? Three options, first copy all the notes manually to you personal notebook. It could take some time. However, you are sure you have the notes in your personal administration. Secondly, make a photo with your fancy mobile or the fancy mobile of your colleague. Simple send the photo to all the people involved in the discussion. Sometimes it is difficult to make a photo of the whiteboard because of the reflection. If necessary, create four photo's to cover the whole whiteboard. The last option is to leave it on the whiteboard with a clear statement that people should not wipe out the notes. This is a good approach when the notes are only necessary during the sprint and you have multiple whiteboard in your team room.

If you have the budget, a active whiteboard is a real must have. We have one mobile active whiteboard in our department and many teams are using the board. There are two major advantages, you are able to save your notes and to share the whiteboard with team members working on a different location. Most active whiteboards have software to save your notes, and easily copy them. For example, a team is having a drawing a oo-model on the board. When you would like to create some alternatives, simple copy the current page and create a new page in which you make some changes. The original is still there, and the the alternative model also. When you are done, export the pages to pdf and send them to all team members. The other advantage is very useful when you are working with not co-located team. It is possible to share your active whiteboard with simple screen sharing tools like Mikogo or GotoMeeting. With a microphone and web-cam people all over the world can easily join and see all the notes that are created on the whiteboard. When the other side uses a digital pen it is even possible for them to participate in creating notes.

Meeting Rooms

Optimal communication is one of the most important aspects of (software) projects. When the team is located in one room communication could be maximised. Assuming there are not person related problems of the team members who refuse to talk to other team members. However, when you have eight persons in your team, in one room, it could be nice to have a separate meeting room. Not all discussions are interesting for everyone.A code review of developers is maybe interesting for a technical writer. Therefore, I believe every agile team should have at least one meeting room.

The meeting room should be in the neighbourhood of the team room. You are not going to walk to another floor or building to go to a meeting room. People tend to be lazy, if the room is too far away it will not be used. It should not be necessary to reserve the room in front, some meetings are planned in front. However, some discussion start spontaneously.

There are some requirements to the meeting room:

Whiteboards, there should be at least one whiteboard in the room to make notes and drawings;
Large table, make sure there is a large table so that there is room to make notes, move things around. You should not be limited in your freedom of movement during discussion because the table is too small;
Chairs..., in our organisation the chairs seems to be able to walk around alone. It happens very often you walk into a meeting room and first have to find some chairs. Make sure the chairs are always there, don't use desk chairs with wheels;
Beamer, when the engineers or customers have notebooks it is very effective to connect the notebook to the beamer and show the screen to all attendees. Sharing the screen for a demo, discussion about a feature or reading requirements together is very effective;
If your team is not a co-located team make sure there is a fixed communication machine. A personal computer with a web-cam, speakers, microphone and for example Skype already installed. When the communication tools are already there, it is very easily for engineers located somewhere else to join the meeting. Make sure the pc starts up automatically in the morning and shut-downs automatically in the evening.

Sometimes you are not allowed to install a communication machine in a meeting room because it is used by different departments or you have multiple meeting rooms available. A solution for this problem is a mobile communication corner. Instead of a desktop use a laptop and buy a mobile cabinet.

Keep always the five minutes rule in mind when installing and configuring a communication corner. If it doesn't work in five minutes, don't use it!

Flexible Workplaces

Most of the teams have fixed workplaces, all the team members work full time in the team or have their own desk. However, some people that you would like to sit together with the team are not part of the team. They are not 100% available, for example customers, proxy customers, product owners with multiple teams, lead architects, team members from other teams, external consultants, etc. Did you ever start in a team, did you have desktop, chair, network connection? Probably not, I guess most of those items had to be arranged before and after the team stand up.

To enable external people to join the team easy, make sure you have at least one flexible workplace. A flexible workplace should consist out of:

Desktop, easily configurable in height and not occupied by your old notes;
Chair;
Wireless network, to make sure the person is quick up and running or make sure you have some spare network cables in your team room that are not "borrowed" by other teams;
Docking station, if you use all the same notebooks in your organisation make sure you have one spare docking station available.

Face-To-Face

As you probably already read, I find communication important. Did you ever tried to communicate with someone with your back to each others. It is possible of course. However, you should agree with me that communication face-to-face is much more efficient.

An agile office should stimulate face-to-face communication.You should be able to topics directly with your team members. There should be no cabinet or wall between you and the rest of the team. Additionally, it should also be possible to discuss in a meeting room, see the section before above.

If you are working not co-located, a face-to-face discussion is still possible. Make sure all team members have a web-cam and headset. With the Skype, your team mate is just one-click away. You should make sure the barrier to communicate face-to-face is as low as possible.

Visualise

The last important topic of communication is visualisation. People are from nature visually oriented. When people have a discussion about a difficult subject, a picture really helps. There is a saying a picture is word a thousand words.

When some team members of you are located in a different time zone you could of course calculate the difference every time. Some of our team members use software to display the local time. However, the old fashion clocks are used most often!

Another very powerful visualisation is displaying the automated test results, build status, etc. People are lazy from nature, they will not look up the bug count, or release progress every day. By displaying this data on monitor in a central environment people walk by, stop and are able to see the status of the project in a few seconds. When you build a display, make sure you use clear colours. Red is failure, green is OK, orange is a possible problem. The data on the monitor should be updated regularly, if possible it should be real time.

If you have a team co-located, the use of scrum boards or kanban boards is very powerful. It has the same effect as the dashboard. In a single glance, you are able to see the status of the current iteration. For everyone in the room, engineers, customers, product owners, etc. the status is visible. A side advantage is, when a topic is done you have to physically move it. Everyone in the room is able to see the change and could anticipate on the change. When you have an excel as "scrum board", the change is not visible in the room, only after refreshing the excel file.

Distributed retro

2010-07-12T10:57:00.058+02:00

One of the most important steps of an agile process is the retrospective. It is a moment in time to evaluate the iteration, quarter, release or whatever the team would like to evaluate. Esther Derby and Diana Larsen wrote a great book about agile retrospectives. If you would like to organize a retro or are looking for a different approach, you should really read this book!

My intention is not discuss the book in this blog. However, I need to give you some information from the book to understand my problem.

A retro has different stages. Roughly:

Introduction, why are we here, what is the goal of the retro, what is the agenda;
Collect the data, facts, emotions, events, (un)completed user stories, etc. Make sure everyone has the same data;
Analyse the data, why did al those events happen?
Identify actionable items, what could the team do to improve or add used practice to there already existing process;
Close the retro, evaluate the retro and explicit close the retro.

For every stage Esther and Diana describe activities you could use. They describe many great activities in the book. Some the activities are already know to everyone, and some are refreshing. For example:

Check-in, an activity that could be used during the introduction. Ask every person attending the retro to answer a simple question in maximum five words. The question could be for example: "what it one thing that's on your mind about this topic that we are going to discuss?". Goal is to make sure everyone is in the retro and focussed on the retro;
Return on time invested (ROTI), an activity to generate feedback about the retro process itself and measure how the attendees experienced the retro. Draw a line on white board with five marks, starting with lost principle (no benefit received from time invested) ending with high return (received benefit greater than time invested). Ask every team member to give their ROTI of the retro and discuss why the ROTI is as it is. Find out how the retro could be improved.

Back to my situation. I had to facilitate a retro about Q1 of 2010 with a development team. The idea was to look back on several iterations (one iteration is one month) and learn from the all things that happened. There were some team changes in January and the team had to find a new balance. Furthermore, the team lead had left the team, how did the team cope with this?

Here comes the problem..... the team was not co-located.... Most of the activities described in the book of Esther and Diana assume you have a co located team. There are activities that require teams to write down things on a whiteboard, group index cards, write text on post-its. All those things are hard to do when you have four team members in India and four team members in the Netherlands.

Still, I think a retro should be fun. Therefore, I selected several activities from the book and tried to implement them in a distributed environment. I think it went pretty well, the retro was a success and everybody enjoyed the retro.I will first shortly explain the activities, and secondly how I implemented them in a distributed environment.

I selected the following activities:

Check-in, already described above.
Time line, create a time line of the period that is discussed in the review. Ask the team members to add events, emotions, etc. that they experienced during the period.
Like to Like, team members take turns in judging which events of the period best fits with their quality cards. As the cards are evaluated team members learn about each other perspectives on the same events. Quality cards are cards with words like, Fun, On-Time, Cool, Awesome, etc. For the detailed explanation you really need to read the book.

The physical set up I used:

Two meeting rooms, one in the Netherlands and one in India;
Skype, and both sides a high quality webcam;
Interactive Whiteboard with screen sharing, By using screen sharing the Indian team members could follow everything that was written or published on the board.

The check-in was relative easy, I asked all team members: "How would you describe Q1 in one or two words?". I wrote the answers on the whiteboard to make sure everyone could read them and understand them. This activity is relative easy to do with a not co-located team.

The time line activity is harder to do with a distributed team. Ester and Diana describe in their book, that team members should use stick notes, or just a marker to write their events on a whiteboard. People should discuss in small groups, two or three people. I solved this problem by preparing a digital slide on the interactive whiteboard. I draw a time line that covered Q1. I asked people just to call out events, emotions, user stories completed, etc during Q1. I wrote the items on the whiteboard and trigger the team members to come up with new items. The problem is that you don't have the small groups, and that people could be afraid to say something in a large group. However, everyone felt safe and comfortable to speak. In my opinion everyone actively participated in this activity.

The major challenge was applying the activity "like-to-like" in a distributed team. The activity involves playing quality cards, people need to quickly play their event card, etc. After the time line activity I asked all team members to write down things that we need to stop doing, continue doing or try. The input for most of the team members came from the time line activity. The team member used paper cards to write down their things. I created a digital quality cards (png files) and a small HTML page. The page uses a java script to display a random picture from a specific folder. During the retro I displayed the HTML page on the laptop that was connected to the digital whiteboard, team members in the Netherlands and India could see the page. As facilitator I opened the page to display the first quality card (By refreshing the page a new card was displayed), all team members could see the quality card. By using the HTML page, I was able to show a quality card to all distributed team members at the same time. We used the webcam to find out which team member played his card last, that card is removed from the game.

The action to identify improvements was also done by using the whiteboard. I wrote down the things I heard during the like-to-like game and we discussed them in the team.

The closing of the retro was done by using an activity called the perfection game. Relative simply for also distributed team.

Working in a distributed team has challenges. You have limits in the things you could do with team. However, when you are creative and use the right tools you could come close to a retrospective that is as efficient and as much fun as co located team. Be creative and don't hesitate to experiment! There is always room to improve!

For example, something I would improve next time is explain clearly the activity to make sure everyone understands the activity. Maybe inform the team in front about the activities that are used so they can prepare. When you, as facilitator, organize a retro as described above you will probably see team that is enjoying the retro and appreciates the effort you made.

I have included the materials (digital quality cards, HTML page and the agenda) I created for the retrospective, feel free to use them. I would appreciate with when you send me an email if you use them.

Software and Luck don't go hand in hand

2010-06-11T14:26:00.002+02:00

Why is everyone in software development always optimistic? Imagine the following situation....

A development team is working on a new product with a new architecture. They did six iterations of two weeks and realised twice their commitment in those six iterations. Their average velocity is 10 gummy bears. The load for the last two iterations of the release is 25 gummy bears.The team is discussing the progress of the release together with the product owner. Phrases that are used are:

If everything goes well...
We have estimated 5 gummy bears, it could be 1 and if we have bad luck 10....
We have done the difficult part...
I think it is possible. However, I will not bet...

Do you recognize such a situation, have you ever been in such situation? How often did it go well? How often did your project have all the luck it needed? How often was the user story over estimated? I think when you are honest... it almost never happened.

Why is almost everyone in software development teams always optimistic?

We believe we should please our customer almost always. I could agree with that. However, I don't agree in which way a customer should be satisfied.

Imagine you buy a second hand car of 15 years old for you girl-friend or boy-friend. The salesman tells you there has never been a problem with the car, not a single issue. Do you believe this salesman?

You are looking around for a new house. You and your partner visit two houses. The broker of the first house shows you around. The kitchen is pretty old and some hinges are old and need replacement. There was a leak in the bathroom and it has been fixed by an official plumber. For the rest the house looks pretty well. The second broker shows you around in his house and explains all the great things in the house, no single issue.

Do you trust the car salesman and which broker do you trust most?

What is different in software development? I think nothing. Let's go back to the case that I described in the begin. Imagine, there are two teams, with the same history. Team 1 is acting as in the described scenario. However, team 2 is acting different. They explain it will be very difficult to deliver all the user stories. They will definitely do their best. However, no commitment is given on the reminder user stories for the release.

You are the product owner, which team do you trust and with which team would you like to do business?

We should be realistic to our customers! When a project is difficult, when a release scope is not realistic, when the architecture is new, we should communicate this to the customer. I would say be honest and realistic to yourself and the customer. What do you think?

Agile Testing: A Report from the Frontline

2009-11-08T16:13:00.000+01:00

The first European Agile Testing conference was organised by Díaz & Hilterscheid In October 2009.

I gave a presentation about Testing and Scrum at the Scrum Gathering 2007 in London. A colleague of my revised the presentation and send in a paper with the title Agile Testing: A Report from the Frontline. The paper was was selected and the colleague of my created this presentation and gave it on the first day of the conference.

This year we have session about Agile Performance Testing, check out the program for more information.

Below is the summary of the presentation of 2009.

In the summer of 2005, a large software development project at Planon had spun out of control. Scrum was introduced to get the project back on track. Currently, eight development teams and one support team work on the Planon software suite.

Testers play an important role in our Scrum process. Typically a team consists of a functional designer, four developers, two testers and a technical writer. The testers act as the team’s quality conscience. They are good communicators and team players. Having them on the teams has contributed greatly to the success of our Agile projects.

During the sprint planning meeting, the testers estimate and plan their tasks. With their functional knowledge, they ask questions to clarify the requirements for the team. Our risk matrix helps them to determine the required test effort and coverage.

During the month-long sprint, testers perform their tasks: testing bug fixes, preparing ET charters or test cases, and setting up and maintaining automated regression tests. We try to prevent “mini-waterfalls”; this requires discipline from every team member.

Setting up and maintaining the test automation framework can become a pitfall when time and effort are not invested.

The test manager is responsible for the test policy and -strategy; he coaches the testers and facilitates the monthly professional circle and test retrospective meetings.

The transition to Agile proves to be hard for some testers. We focus on Agility during recruitment and training.

TestNet 2009 Fall Event

2009-10-15T16:56:00.000+02:00

At Planon we started with distributed teams in 2008. We use the set up discussed in a white paper of Jeff Surtherland.

The theme of TestNet 2009 Fall Event was Testing in different worlds. We created a presentation to present our experiences with distributed testing in a distributed scrum environment. My colleague send in the paper and was selected to give her presentation.

The summary of the presentation is below.

Planon develops a standard software suite and has adapted Scrum four years ago. To extend its software development capacity, Planon has recruited new staff in Hyderabad, India. Currently, seven out of nine teams are working in a distributed manner, i.e. one or more team members are located in India. The split is straight down the middle, not role-based. On average, half of the developers and testers are located in the Netherlands, and the other half is located in India.

Most challenges apply to the whole team, but some apply to the testers in particular. In India, the hierarchy in software development is much stronger, where the testers usually are at the bottom. Communication lines are long, with a lot of managers in between the developer and the tester. In our Scrum teams, all members are equal and the team manages itself. For our new Indian colleagues, that proved to be quite a “culture shock”.

We covered this issue while recruiting Indian testers; we assessed the candidates’ ability to adjust to our way of working. After a first selection (primarily focused on language), the candidates participated in a hands-on workshop with practical cases, which uncovered their communication and teamwork skills. Planon now employs eleven Indian testers.

Distributed testing also has logistical challenges: our nightly and continuous build processes provide the tester with new software versions regularly, but getting that software quickly to the other side of the world is difficult.

Agile Holland 2008

2008-10-25T15:41:00.000+02:00

This is a presentation that Maarten Smeets and I gave at Agile Holland 2008.

The idea was to let the audience decide the which subjects we should present. We just asked in which items they were interested, sorted the items based on interest. Every item was presented in a timebox of approx. five minutes.

The presentation is already two years old, a lot changed during those two years. If you would like to know more about a topic just send me an email.

Below is the description of the session on the site of agileholland.com.

Who are we to determine what you would like to know... isn't the product owner not responsible for the return on investment? The audience has the role of product owner, Maarten Smeets and Ralph van Roosmalen will play the team. They will transfer the product backlog items into value for the product owner.

The content of the presentation is determined by the audience. We offering the following subjects and the audience should create a ranking. The product backlog items are:

Release management
Requirement Management
Agile Testing
Retrospectives
Scrum and the impact on the rest of the organisation
Department structure and Scrum
Distributed Scrum
Tools
How is Scrum implemented at Planon

Planon started with Scrum in 2005. They have a rich experience on several aspects of Agile Software Development, from requirement management until release a new software release.

How to improve your team with retrospectives

2008-09-30T20:00:00.003+02:00

This is a presentation I gave at the Dutch 11th Spider Conference. It is an introduction about retrospectives and contains some lessons learned from the real world.

How to coach to testers on Exploratory Testing

2008-07-24T09:57:00.003+02:00

We are currently starting with distributed Scrum Teams. We have one part of a team located in the Netherlands and the other part in India. The Dutch side of the team exists out of one functional designer, one tester, one technical writer and two developers. The India side exists out of two developers and two testers. I am not going to discuss the distributed approach in this blog, only the problem of the Dutch tester ;)

We use a lot of Exploratory Testing (ET) in our test strategy. We have created a standard ET Charter, the tester has to decide per product backlog item which items are relevant to test. You need a lot of knowledge of the application and of testing to do good ET. The testers in India are familiar with testing. However, not with ET and of course relative new to our software. The problem of the Dutch tester was: "How can I coach the Indian testers and not do all the ET again to verify their work?"

We discussed this problem in our Test Retrospective and came up with the following ideas for him:

Accept that not all problems will be found;
Use pair-testing;
Select one item of the ET charter with tester X and discuss it, select another item of another ET Charter and discuss it with test Y;

Let me explain the ideas in more detail.

Accept that not all problems will be found
The only guarantee that you have when you deliver software that it contains bugs. You will never find all bugs for acceptable costs. If you hire a lot of testers, hire the best engineers, review all specs, etc., you have change of creating software without bugs. However, in most companies or projects this is not possible.

In our test strategy we have written that high risk items will be tested by the most senior tester of the team. The new Indian testers are not very experienced so they will not start testing the high risk items. The team selects it own work, that is part of Scrum, and will also select some simple features. The new Indian testers can be assigned to test the simple features, it is part of their training. The change that Developers introduce bugs is not that high and if so, the risk is very low because it concerns only simple features.

So we assign simple tasks to the new team members, the risk of introducing new problems is not high and the change of finding them is very high. In case a bug slips through it is no big risk for the customer because it is a low risk feature.

Use pair-testing
In a previous blog I wrote an article about pair testing. It is wise to use pair testing in combination with the next idea.

Select one item of the ET charter with tester X and discuss it, select another item of another ET Charter and discuss it with tester Y
We use a standard ET Charter as template for all ET testing. Standard features are tested with the same ET Charter and some configuration parts are used for in parts of our software. You could discuss every item of the ET Charter with every tester, this will cost a lot of time. However, an option is to select a certain item of the Charter and execute pair testing. The new tester is trained and learns from the experience of the senior tester. The new testers can transfer his knowledge also to his colleague in India.

The Dutch tester could test the same item with the other Indian tester. However, what is the value? Sure, the tester learns from the experience of the senior tester but the Indian tester that already did pair testing could also explain how to test the issue. We think it is more efficient to test another issue from the ET Charter with the second Indian tester. He can share his knowledge with his colleague tester, in this case you have trained two testers in India on different subjects.

Conclusion
It is no easy to train two new testers in a distributed Scrum team, that is located on the other side of the world. As (project/test/development/etc) manager you should be aware of the risk and accept that some problems will slip through. With good risk management done by the team, pair testing and efficient coaching you can train the testers as fast as possible on the job. In the end the most important issue is communication! If there is no communication between the testers every coaching model has no change of succeeding.

Pair Testing

2008-07-12T16:28:00.001+02:00

Introduction
This is an article about pair testing, maybe I going to create a presentation based on this articile. If you have any comments or remarks please let me know. Please also take a look at the sources at the end of the article, I have used their knowledge and opinions to form my own opinion and view on pair testing.

At our development department we use Scrum as a development framework. Scrum is an agile framework. Exploratory Testing (ET) and Pair Programming (PP) are often used in Agile environments. If you combine those techniques it results into Pair Testing (PT).

In this article I would like to explain to you what Pair Testing is. The article is intended for people who would like to start with Pair Testing or who are just interested in Pair Testing.

What is Pair Testing
Pair Testing is testing of software by two team members sitting behind one machine. One team member is in control of the mouse and keyboard, the other one is making notes, discussing the test scenarios and asking questions. One of the two should be a tester and the other one could be a developer or business analyst.

PT is not intended to execute formal test cases, PT uses Exploratory Testing. I will not cover ET in depth in this article. ET is an informal test technique and requires extensive test experience and/or good knowledge of the software under test (SUT). When you pair a developer or business analyst and a tester, you have test knowledge and knowledge of SUT.

Pair Programming is a common practice in Extreme Programming. Pair Programming is experienced as a good approach for programming software. Pair Testing is a similar technique for testing software.

If you use PT, both team members should be equal. It should not be that the senior team member is using the junior team member as a scribe. The team members should work together and actively contribute to the PT session.

Why use Pair Testing
Pair Testing has some clear advantages above normal ET. The advantages are:

Developer or business analysts approach the software from a different view. They think in good paths, for example “I have to create an address and edit the fields.” The testers will also look at the exceptions, for example “What happens when I create an address and press cancel instead of save…”
When PT is executed with a business analyst their will be automatically knowledge sharing between the business analyst and tester. The business analyst will share his knowledge of the application of business with the testers during the session.
If a new project is started with new team members who are new to agile development their will be often a barrier between testers and developers. By using PT the team members will work closely together and get to know each other better.
Working in Pairs keeps you sharp, you can not doze off. You will keep each other sharp.
If you find problems and decide to register them in a bug registration system, the problem is automatically reviewed. You work in pairs, so the data you entered is immediately reviewed by the other one.
As a tester you will encounter mysterious bugs that seem to occur at random. In a PT session with a developer you could find a pattern and thereby the cause of the bug. The developer will probably see the link between the problems because he has knowledge of the software framework.
The last reason to use PT is maybe the most important one: It is fun, working together with team members is fun.

When not use Pair Testing
If you don’t have set up the right conditions for PT you should not start using it. However, there are some circumstances that you could better not use PT even if the right conditions are set.

Do not use Pair Testing when:

All executed test should be automated. The result of PT is findings and no test cases. You can not use the output of a PT session directly for test automation. This problem also occurs when you use ET as a single tester.
Team members can not work together. If you have two team members who can not work together because their characters clash you should not use PT. The team members must be able to communicate well and work together without quarrels.
If you are only going to execute structured test cases. It does not add any value execute the test cases together. This kind of tasks can be done by one team member alone.
The SUT does not allow PT. Imagine a batch operation that runs for one hour and the result is comparing output data with an excel sheet. This kind of work can also be done by a team member alone.

Set up a Pair Testing environment
To allow good PT you need to set up a good environment.

The team members should work voluntarily together. It will not work to force cooperation so a Test manager, Scrum Master, Test lead, etc. you should create an atmosphere that team members are willing to work together.
A room or desk where the team members can work undisturbed. Two team members working together should not imply twice as much disruption ;). So for example switch of mobile phones and close the email application.
The workplace should support two people sitting behind one desk. You can not ask people to work together if there is no room behind the desk for two chairs.

Prepare Pair Testing Session
It is necessary to do preparation before the PT session starts. Most of the preparation is because you use ET, for more details Google “ET”.

Create an ET Charter
Define the focus and scope of the test.
Describe the targets for the test.
Agree together how much time you are going to test, it should be time boxed. Normally you have a session of 60 till 90 minutes. Do not forget to plan a break!
Plan the meeting in for example Outlook.

Executing Pair Testing Session
During the session the team members decide which test paths and how deeply the test will be. This should be of course in line with the targets, focus and scope of the tests described in the ET Charter.

One team member (the Driver) should be in control of the keyboard and mouse. The second team member thinks out-loud, asks questions, makes notes on paper and gets the coffee.

A PT session lasts for about 60 till 90 minutes, and don’t forget the break.

Finishing Pair Testing
After the PT session the findings will be added to the bug registration system, if necessary and not yet done. The ET Charter will be updated, which test targets are tested, which problems were found and other remarks if necessary.

A part of the ET Charter is also a short evaluation of the PT session, what went well and things that could be improved next time.

If during the PT session new test targets were found, a new PT session should be planned. The pair could even already create a new ET Charter for that session.

Conclusion
Is Pair Testing rocket science? No, it is a combination of working together and testing. However, it has a lot advantages above “single” testing. There will be knowledge sharing (about testing and the SUT), train new team members, break down barriers between team members and most important it is fun!

Be aware that you not always could and should use Pair Testing, use it when possible and use it wisely.

Sources

Agile Testing doesn't exist

2008-07-07T11:57:00.003+02:00

Agile testing.... hmmm what should I say about agile testing. I always try to prevent the term Agile Testing. Why, I believe the term doesn't exist.

Agile software development is for me, a process of specification, programming and testing. There is no such as Agile Specification or Agile Programming. If you implement Agile Development, you implement all aspects of software development in an Agile environment.

So Agile development, implicit means Agile Specification, Agile Programming and Agile testing. I don't think you can do agile testing in a waterfall environment, of course you can use some aspect of testing in an agile environment like ET testing or a lot of test automation.

What is my point? Nothing special, however next time I will skip the part that I explain that Agile Testing doesn't exist when you ask me how we do agile testing ;)

Scrum and Testing

2008-04-11T16:08:00.005+02:00

I attended a meeting about Scrum Yesterday. All the participants (approx. 20) were certified Scrum Masters and most them are using Scrum daily.

The idea was to exchange ideas about Scrum and to learn from experiences from each. It's a great idea, certainly because the number of companies in the Netherlands that use Scrum are not big. The Dutch Agile Group is not so active and there are not so many conferences in the Netherlands about Agile Software Development.

The host organised a retrospective to find some common Scrum problems and some actions to solve those problems. I personally don't believe in common solutions for Scrum problems, why not? Every project has a different culture, different people, different software factory, different customers, everything is different, so how can you describe a common solution for a common Scrum Problem. (By the way, there are no Scrum problems, just problems becoming visible because you use Scrum). So at the end of the meeting we discussed that we focus more on exchanging ideas the next time, probably an Open space conference.

But anyway... one of the most "common" problems was Testing and Scrum. I was wondering, why is that a problem? I could give you all kind of solutions but I won't, just one solution, OK three solutions.

The common solution for Testing and Scrum are:

Some general information about testing and Scrum, link to a website to find information ;)
My posting about ten tips for agile testing, to get some ideas to get you started;
JUST DO IT, stop finding the right process, stop complaining about missing requirements, stop finding reasons to don't start with testing in a development team. We have thirteen testers and they all like working in Agile environment, so why would your testers (or you, if you are a tester) don't like it?

Test automatisering in de theorie en in de praktijk

2008-04-08T08:19:00.006+02:00

This is a presentation I gave at the Dutch TestNet Conference 2007, it's about automatic testing, the theory and the real world.

The presentation is in Dutch, so sorry for you non-dutch speaking people. If you are really interested in a English version please let me know.

Ten Tips for Agile Testing

2008-04-07T17:22:00.003+02:00

This is an copy of an article I wrote last year for the Agile Development Magazine, it was published in summer 2007. Since that time we changed and improved ourselve, but I will discuss that later.

Two years ago I started as test manager on a J2EE project. The project team had switched from a waterfall approach to an agile approach with Scrum a few months earlier. The first question the project manager asked me was, “Can you write a test plan for our first release?”

I quickly produced a project test plan that called for a test phase of a few months and a separate test team. It came complete with a capacity calculation per week for the testers, a MS-project document, and a matrix with all the quality attributes and the effort we should spent to test every attribute. What a mistake!

Two years later, we’ve learned a great deal about agile testing. This article presents ten tips for agile testing based on our experience. However, don’t expect to find the perfect test approach for your company or software project in this article. That is still something you will have to find out yourself!

Integrate the testers in the development teams
Teams are responsible for delivering software that meets expected requirements and quality. However, if we want teams to test the software, we must give them the knowledge to do it right. Testers have that knowledge. By integrating testers into the development teams, teams obtain the skills they need to test their software. When you try this, make sure you choose the right mix: one tester on three programmers is a fair but minimal number.

Use risk based testing
You can never test everything with the same (extensive) depth; even in a waterfall project you have to make choices. In an agile project all the activities are time boxed so you have to make choices about how extensively you want to test each feature. We use a risk based approach to determine which test activities we are going to carry out for a feature during the iteration. The risk level of every feature is determined by the customer and the teams. It is a very transparent process so the customer knows exactly which test activities are executed for every feature.

Have testers review unit tests
In our organization the developers are responsible for creating and maintaining the unit tests. Unit tests are a very important part of our test harness. Developers often have a different way of thinking; for example, they tend to test only the success scenario.

To create unit tests that are as good as possible, our testers review the unit tests for all our high-risk items. The review has two advantages. First, the unit tests are improved because testers and developers supplement each other: the developer knows where the weak places in the source are, and the tester can use his knowledge of testing to give tips to improve the unit tests. Second, the testers know exactly which test cases are executed in the unit tests and can concentrate on executing other (e.g. higher-level) test cases.

Create a test automation framework and appoint a toolsmith
Automated testing is very important because new features and refactoring can introduce problems that can be difficult to find. By using an automated test framework, we can maintain quality levels during the iteration. Our testers are able to create new tests easily and quickly in the framework. We have a dedicated test engineer (we call him a toolsmith) that maintains and optimizes the test automation framework, reviews the new automated tests of the testers and analyzes the daily test results. Testers in the teams can spend more time creating and extending automated tests because the toolsmith supports them.

Display quality metrics in a public location
Almost every software project has a problem registration system, automated test results, and in some cases nightly or continuous build results. But how often do team members look at the results or count the open problems? We installed a monitor in the coffee room that displays the actual metrics of the currently open problems, the percentage of successful unit tests, the percentage of successful nightly builds, and the current state of the continuous build. By displaying the metrics in public the teams are confronted with the information. The information is no longer just a number in a system or a record with some information in a metrics database.

Add a test scrum
One advantage of having a separate test team in one room is that the communication between the testers is good. When you have a project like ours where the testers are distributed across several teams, the communication becomes more difficult. To solve this problem, we use a test scrum to align the test activities. Our test scrum is held twice a week and every team is represented by one tester. The test scrum is a scrum like the daily team scrum but focused on test activities. The test manager is the scrummaster of the test scrum.

Implement test retrospectives
Every team in our project holds a retrospective meeting at the end of the iteration. In the retrospective, the team discusses the process: what went well and what went wrong. The testers in the team learn and discover new ways to improve their tests; it is good when they share this knowledge with testers from the other teams.

We have a test retrospective every iteration so the testers can exchange knowledge and experience and discuss problems they have. It is important that the retrospective is only related to test issues; you shouldn’t discuss team issues (they should be discussed in the team retrospective). As with the test scrum, the test manager is the scrummaster of the test retrospective.

Plan open problems
We try to fix all the problems that we find during the iteration in that same iteration, but some times we end the iteration with open problems. The best way to handle those problems is to add those problems to the sprint backlog for the next iteration. By explicitly planning those problems, the chance that they are “forgotten” and pile up is very small.

Remember: Testing is still testing
When you test in an agile software project you can still use the “traditional” test techniques. We use exploratory testing but also apply test techniques such as boundary value analysis, equivalence partitioning, cause/effect diagram, and pair-wise testing. Which test technique we choose for a feature depend on its risk category. Exploratory testing is used in every category; but if the risk is higher we also apply more formal test techniques. The challenge for the tester is to use a formal test technique without delivering extensive test documentation.

Start doing it!
The last but most important tip is start doing it! Don't talk too much about how you are going to introduce testers, or which test approach is perfect for your organization. You are going to make mistakes or discover that the chosen approach doesn’t fit your organization. That’s a given. But, the sooner you start, the sooner you can begin learning and improving your test approach. With the retrospective meetings, you have the opportunity to adapt your test approach every month.

Conclusion
Last month, we delivered the new release of our software. We started developing this release in January. During the last two weeks of May, we did some more exploratory testing, solved the remaining problems, and prepared the delivery. I wrote no extensive test plan, did no capacity calculation, and created no matrix with quality attributes. We just started testing and improved our testing every month.

Testing and Scrum

2008-04-07T17:14:00.005+02:00

Here you can find a link to a presentation I gave during the Scrum Falls in London in November 2007 or just watch the presention below.

Below is a short description of the presentation.

Scrum is a project management framework; it doesn’t contain any developer or test practices. In most companies Scrum is used in combination with XP, Scrum is used for project management and XP practices are used to guide development.

If you’re a traditional tester and you start in a project that is going to use or is using scrum you will have a hard time to find out what you have to do. Scrum doesn’t say anything about testing and XP does say something about testing but it is not a guidebook for a tester.

I want to share our test experiences with the audience, we use scrum for two years and I think we have a good test process that is interesting for everyone who is involved in building software.

In this presentation I will share our experience from Planon about testing and scrum. I want to answer the following questions:

Do you need specialized testers in Scrum;
How did we introduce testers in the development teams;
What is the role of the tester in our team;
How do you recruit testers for a Scrum team;
How you do organize the testers over the teams;
Do you write a (master) test plan?
What about formal testing techniques in Scrum;
What kind of test automation harness do we use;
How do we report about testing;

The audience will have good overview of the test activities we do at Planon and will get tips how to improve the testing process in their own projects.

Our First Why-Did-We-Miss-That Session

2008-03-20T15:42:00.005+01:00

Today we had our first Why-Did-We-Miss-That session. I read about this meeting in the blog of Elisabeth Hendrickson.

We already discussed last year that we should analyse our customer problems. We didn't know how to do it via a structured way and because of all the other important things we didn't find time to sit down to analyse the problems.

So that's why I just planned this session, now your of course are curious to our experience...

I planned the session from 13:30 till 15:30, two hours. One hour for the first part en the rest for the second part.

I prepared the meeting, ordered index cards, reserved a room, created a filter in our bug registration system and send every tester the link to the blog. I explained the purpose of the meeting.

We started analyzing and discussing the problems. We analyzed approximately 40 problems of the 140 problems. We run out of time, so we stopped and started with the next step. But first coffee and smoke break.

One person read the cards and the rest of the team created groups. For some cards it was very clear to which group they belong, but we also had a lot of one-card groups. It didn't work let all persons group cards, we lost the overview. During the grouping it became clear that not all people wrote actionable cards, so some explanation was needed during grouping the cards.

After the grouping, we made up actions for every group. Turned the stack of card up side down and wrote down the actions on the cards. We came up with 15 actions, all kind of actions for example extend our default ET Charter should be extended, more installation testing and educate the help desk to make clear the differences between the old and new product.

As final test we selected random 15 problems and analyzed if they fitted in one the defined groups. 11 problems fitted in a group, only 4 problems would not have discovered. A good score in my opinion.

Of course we did retro at the end of the meeting, the following improvements the following items were mentioned:

It is a intensive meeting, so plan it early on the day and not with another meeting on the same day;
All calls should be in the same language;
We should make a pre-selection, but this has a risk that you will not find all improvements;
The next meeting will be a few months after a customer release (not an internal release) or when there is are for example 50 new problems;
We didn't find anything surprises.... I think this is a good thing and proves that our Test Retrospectives work well and that we already continuously try to improve our selves.

So what is the conclusion for us? A great tool to periodic analyse our test process.

Still wandering if this is something for you? Just try it and improve it, don't be afraid of trying something new.

InfoQ: Does "Done" Mean "Shippable"?

2008-02-26T10:13:00.001+01:00

A very interesting article about what is done and what is shippable, my opinion is in the comments of the article.

First time

2008-02-25T13:26:00.002+01:00

My first post on my blog, why this blog?

Two reasons, I want to share my experience with agile software development to make more people enthusiastic about agile software development and the second reason I want to ask you to comment my articles so I can learn from you.

So if you have any questions, comments or some thing else please, really please, let me know.