Category Archives: Leadership

Technical and personnel leadership

Leadership, Methodologies

Listen to the old ones, or re-invent the wheel

Leave a comment

Some while back I read a blog entry from Jason Gorman on Wheel-driven reinvention. His core statement is, that there is nothing new in the world of software development. When you start to trace back any common hype in the software industry, you will most likely end up in the 1960s or 1970s finding the core idea raised by that time. When I first read his blog entry, I was going to write a follow-up describing how little the great old ones help us understand their solutions to the problems of the software industry in the last decades or so. Since I know that I had to incorporate Gorman’s thoughts into my models I decided to postpone it a bit, and get some time to think over it.

There are just a few professionals who actually did what I was claiming, but the more striking point for me is how little time we spent listening to them. One excellent example of a great old one is Gerald M. Weinberg, who worked on project Mercury for the NASA, and was part of the first testing teams when the latest hype was to do testing independently back in the 1970s. Recently I came across a paper from Edsger Dijkstra, written by hand. Into that line fits also Brook’s Mythical Man-month or the No Silver Bullet article. And I know that there are other great examples of great old ones, to which we should pay attention, in order to learn something new.

That said, I read a blog entry from James Shore yesterday on Large-scale Agile. He put up a great effort to describe how to combine the ideas from Scrum and the ideas from Kanban together to scale Agile up on a larger basis with sub-dividing teams. His ideas are interesting, and I gave up half-way through trying to understand all of his premises. Remembering back my math teacher in school when I showed him a proof that one equals two, he stated: “When working from a false premise, you can show anything.” This is even true in writing.

How come there is nothing new about large-scale Agile? The textbooks on Scrum just mention the Scrum of Scrums, but not how to apply them. XP and Kanban just work on smaller teams, so he’s actually writing something new. Really? No. Obviously not. the Crystal methodologies, and recommendations for large-scale Agile. Thought, he stated that there is a barrier to Agile and their light-weight methodologies at project size of about 500 persons. Scaling Agile up, though comes with a prize. Larger teams need other communication channels for example. You may put a team of 12 into a single room. The team can work up with osmotic communication. On a 500 person project, you may have difficulty to find a room large enough, and obviously not everyone will be able to overhear the conversations of all colleagues. There are other penalties you have to pay for scaling Agile up. Whole-heartedly I recommend reading his book on Agile Software development.

Additionally, what I learned from Cockburn is the notion of a sweet-spot of Agile methodologies. The lightweight nature of Agile methodologies has a sweet-spot on a lower team-size with fewer effort put into ceremony overhead for hand-offs. When increasing the team size, you automatically get a larger communication-need. There are non-linear increases in the amount of possible communication channels among team members, as well as slower communication channels like informations flowing across different rooms. That said, if you don’t fulfill the need for more communication, you may find yourself set up for Agile failure.

There are many other factors which need to be increased for the larger team-size in a non-linear way. In case you’re searching for an answer on these questions, I recommend to read all of the following book

  • The Mythical Man-month from Frederick P. Brooks Jr.
  • Quality Software Management Volume 1 – Systems Thinking from Gerald M. Weinberg
  • Agile Software Development – The Cooperative Game (2nd edition) from Alistair Cockburn

Listen to the old ones, or re-invent the wheel.

Leadership, Software Craft

Ethics in Software projects

Leave a comment

Personally, I love to relate different aspects from other areas to my life as a software professional. Today the aunt of my wife celebrated a birthday, and I got the opportunity to overhear a discussion between my father-in-law and an uncle from my wife, who are both truck drivers. Since I read Secrets of a buccaneer-scholar, I became aware of combining different areas of my life together to learn something new.

Now, German laws demand high discipline from drivers on the road – especially truck drivers. There are given rest times for truck drivers, regulated by the local police officer. These laws evolved over time, to protect innocent truck drivers and other traffic participants from fatal injuries caused by drivers with too few sleep. There are other regulations that protect trucks from getting off-track, especially on the German Autobahn, where truck speeds of 100 km/h are usual – and cars drive with as much as double this speed.

So, working as a truck driver puts a certain challenge on you. You want to deliver your wares to the destination and hit back home. Your boss wants to deliver the wares to the promised date. Traffic jams, alternative routes, and other variables may put the predetermined schedule from your boss at stake. Today
I learned that it is common that the boss will then ask the drivers to skip their rest times.

But wait, what has this to do with software development? Well, if there are delayed deliveries from third-parties, shortcuts to requirements and/or design, among other variables, your project will be put on pressure. The predetermined project plan may become out of date. As the truck drivers’ boss, your project manager may ask to skip testing.

So, what is different in the truck driving part of this analogy is the fact that there is a police checking for too long driving periods. The German law then enforces penalties to the truck driver for giving in to the demand from their boss, so they may even lose their drivers license in extreme situations.

Seriously, I doubt that most projects would deliver untested software, if there was a project police in place, that would charge penalties from developers and even project managers for skipping testing. Sure, an overtired truck driver may deliver their goods on time in 90% of the cases, but if he just naps in front of the steering wheel once, and ends up in a massive traffic accident, the results will be dramatically fatal. The same may as well go for some software projects. However, avoid to give in the temptation to say “my project won’t cause fatal accidents, if I skip testing.”

If you didn’t get my main point, I would like to finally point you out to a fable about testing from Gerald M. Weinberg. His granddaughter Camille got the point from it at the age of four, can you get it, too?

Leadership, Testing

Deliberate Learning

Leave a comment

Today after two weeks of reading, I finished Secrets of a buccaneer-scholar from James Marcus Bach. I was amazed on how he describes my attitude towards learning. Over the course of the last ten years I had always believed in more traditional ways to get educated. Well, when looking back at the education I got in school and the education I got at the university, and reflecting it over the stuff I need now on my day-to-day work, there is little that I have learned in those more traditional systems that help me now. Maybe ten percent of it does any service to me today. The remainder I learned myself ever since I started to work at a software company as a software tester – right when I didn’t know anything about testing software and how complex that field even is. This passion for learning has always driven myself and helped me get further ahead. When looking at my colleagues I was amazed that I seemed to be the only one, who was practicing self-education besides their day job. A key attitude I have built upon early on is the attitude for life-long learning – and I live it.

Now, reflecting back on the last four weekend of Weekend Testing in Europe, I noticed a pattern and a relationship to self-education – or buccaneer-scholarship how James calls it. Remembering back on our first session we had an online image processing tool and were asked to test it. There were two or three people who had experience with image manipulation, and the remaining three or four did not know anything about it. Since the mission was provided at the start of the session, this meant that no one really knew what was going to happen to prepare. Since no one dropped out of the session either, all participants were very, very eager to learn something new.

Indeed, when you face a situation which you don’t know anything about, some may react with fear about it. James taught me from his book the most valuable lesson: A buccaneer-scholar is not afraid of new situations. Even when you just now a tiny little piece of information about the product you’re going to test, or the project you’re asked to work upon, your deliberate learning attitude can and will help you. There is no big impediment to get to know something new. Maybe it gets you out of your comfort-zone, but imagine all the stuff you will know in addition to now. You will be able to make associative connections to stuff you already know. This is how your brain works. By making new connections, you may also reflect on stuff you already know and learn new things about that, either.

Deliberate learning can help you become used to learning as a competitive advantage. I see this happening for myself, I see it happening for James Bach (take a look on the videos on his buccaneer-scholar site), and I know that it may very well work for you as well.

Happy learning.

Leadership, Testing

Burning Issues of the Day – Revisited

Leave a comment

Michael Bolton published his speech from EuroStar 2009. It’s humorous. In fact there is one story line which hit my face when I viewed his presentation some time earlier.

  • When a manager asks you to show him your test cases, ask him to show you his management cases.
  • When a manager asks you to show him your test scripts, ask him to show you his management scripts.
  • When a manager insists that every test should have an expected, predicted result, ask him if every management action should have an expected, predicted result.
  • When a manager insists that we lower the cost of testing by bringing in test automation, ask if we can lower the cost of management by bringing in management automation.
  • When a manager wants to evaluate testers based on “defect escape ratios”, ask if we can evaluate management by “bad management decision escape ratios”.

The series seems to be inspired from James Bach as can be seen on the slides.

The interested reader will of course immediately notice there are some points left out. So, let me introduce them here:
When your manager asks you how many percent of your test cases were finished, ask her how many percent of her management cases were finished.

Testing, just like software development, is an activity, which is highly influenced by humans, individuals, their intrinsic and extrinsic motivations, abilities, and contexts. If every testing activity was highly predictable, then how come there are so many of those predictable models? How come there are several schools (in the Kuhnian sense) keeping on arguing over it? If we could identify all relevant quality issues up-front, why wouldn’t we avoid problems in there in first place?

When your manager asks you how many testing is planned to be left, ask her how many management is planned to be left.

Testing is a human activity and in most cases it is hard to predict how long it may take. There are a lot of factors that influence how long a previous planned testing activity may take. Instead, you should ask: “do we have gathered enough quality-related information about the product in order to make a ship/not-ship decision?”. But, leave that decision to the management.

When your manager asks you about best testing practices, ask her about best management practices.

Don’t do this. They might answer your call.

Leadership, Retrospectives, Testing

On Feedback

Leave a comment

In a comment on my last blog entry, Thomas Ponnet reminded me of something I experienced during my years at the university while I was working in a local shop. By that time I was responsible for ordering beer and non-alcoholic soft-drinks, and getting them into the shelves. We had a weekly ordering cycle, and some of the better brands needed to be ordered in large amounts and refilled over the course of the week – i.e. directly before the weekend.

My direct superior switched jobs to another shop, and we got a new superior. The first thing our new boss changed, was the responsibility for all orders in the food department. Just the new boss and his substitute would make all the orders in the department. Groceries, meat, alcoholic and non-alcoholic drinks, etc. We were asked to simply fill the shelves, and keep the shop beautiful.

Now, think shortly over how this felt. Our self-responsibility was taken away. This resulted in a more senior student temp to quit. The new orders from his new boss were just too ridiculous to stay there any longer. I decided to stay, but I also got the exceptional status to still order goods myself. So, in order to demoralize a team completely, just take their self-responsibility and observe the degeneration. This holds for teams in your local shops as well as for software development teams.

Now, over time I observed the other areas, where I wasn’t mainly responsible, but helped to fill in the shelves from time to time. The food substitute ordered more and more goods. The problem was, that the substitute did no longer have the time to do the refills. Over time she was simply noting down the orders during her shifts. The problem was, that she started to make mistakes based on the time pressure I think she had to finish all these orders off in the time given to her. So, time pressure resulted in more human errors. Sounds natural, doesn’t it? This also holds for software development teams, doesn’t it?

What then happened, was striking me. We noticed all the errors the substitute made during noting down the orders. Since we took the new goods and put them in the shelves, we noticed there were blanks after we finished, and there were remains we needed to carry over to storage in the back – hopefully the remains would fit into the shelves in a week or so. But, instead, the substitute while noting down the orders for the next week, saw the blank place on the shelf. She then did the same mistake again, ordering just those goods, that were full and we had still some remains in the storage, instead of the product that was actually missing. Since she didn’t have the feedback from her orders, they got worse and worse, ever resulting in larger and larger piles in the storage. Over the course of a year the remains in the storage raised by a factor of four.

What I learned over the course of two to three years by then was, that people responsible for a job have to get the feedback of their actions. This holds for shop ordering teams in the same ways as for software development teams. Without the feedback on problems and errors, I cannot learn to avoid these errors the next time. I will be pretty oblivious to my courses of actions. In the software world, there are several things we may pile up. Maybe it’s a large test suite with unreasonable execution time, maybe we pile up Technical Debt, or maybe we pile up Design Debt, or, or, or…

This is why Agile development teams iterate and reflect. They get their feedback regularly and decide how to adapt to problems and new situations regularly. That feedback is crucial, don’t remove that feedback from your teams – and please leave them their responsibility.

Leadership, Testing

On Attitude

4 Comments

Last week I came across a tweet from James Bach on Twitter:

I break dreams about products, not products.

Since I am currently reading through Quality Software Management – Volume 4: Anticipating Change from Gerald M. Weinberg, I had the Satir Change Model in mind. Jerry cites Virginia Satir there:

It may look like a crisis, but it’s only the end of an illusion.

Adopting the citation from Weinberg, putting it into James Bach’s citation then became the following tweet:

Testers don’t break software, we end illusions about its usefulness.

Alistair Cockburn commented on this with the following:

I liked when a tester said, “My job is to see that once it gets past me, it doesn’t break for anyone else.”

This made me thoughtful. Finally, I realized that I need to put my phrase into context.

What I had in mind with testers ending illusions about software, is the fact, that testers do not put quality into the software just by their work. Tester interactions with the project manager, the business analysts and product owners, the developers and the customer probably end up in high quality software. Often, testers are the messengers of the bad news and might get the blame for their messages, but they shouldn’t. Testers just test the software they get handed and make evaluations about it. We collect the information and our reports maybe let developers fix bugs or make project managers delay product deliveries, but testers don’t create quality, we try to make it transparent. So, my statement is more against the management view on testing as it is prevalent in some organizations nowadays.

On the other hand, what Alistair is referring to is the attitude of a tester at work. Of course, I want to be proud of the job I did and sign for the testing I did. Taking it to the extreme that no one else will find a problem, when I’m finished with the product is a really good attitude. Most good testers I have met had just this attitude. When I have finished testing the product and the manager decides to ship it upon my report, it’s a moment of pride for the work I achieved.

But there is a problem with quality. Quality is time-effective. Software that is perceived to be of high quality, may be of poor quality tomorrow when a competitor delivers a new version of his product and puts my company out of business with it. As a tester, there is little I can do about that. I can communicate about the information I got while interacting with the software. I can communicate about the information that bug fixing seems to take longer and longer, which might indicate Technical Debt. But since I don’t have control over the business schedule, the developers and resources on the project, I cannot decide to do something about it. Instead, I make informations about quality transparent.

Of course, the right attitude for a tester is great, and as I learned the tester Alistair mentioned got promoted several times in the last two decades. But, testing attitude alone does not lead to quality software in itself. On the downside, there are decisions taken for testers and they receive the blame in the end, as Michael Bolton pointed out:

People give testers scripts with explicit steps and observations, then ask /the tester/ “Why didn’t you find that bug?!”

Now, that’s ridiculous!

Leadership, Methodologies, Retrospectives, Testing

Planned conferences in 2010

Leave a comment

Zeger van Hese‘s summary of the Agile Testing Days in 2009 reminded me to write about some of the conferences I plan to attend over the course of this year. And yes, Zeger is right, since it was my first conference presentation back in October, I was very nervous. Thanks again to Gojko Adzic and Mike Scott, who gave me great feedback the evening before during the Oktoberfest took place. On a second note, Zeger attended nearly all the presentations I was also in – despite the tutorial.

That said, I’m going to attend the Agile Testing Days from 4th to 7th of October again. The submissions are still open until end of January, but I think one of my proposals may be selected. Additionally, this year it’s going to be a four day conference. So, I plan to be fully blown afterwards.

Another great conference last year was the Software Craftsmanship Conference in London in early July. Thus far Jason Gorman has not decided upon the programme, but he’s working on the submissions. If I can make it by any means, I will attend again and maybe get one or the other book signed. I don’t plan to submit an own session.

A conference I haven’t visited last year is the XP2010 conference in Trondheim from 1st to 4th of June. I’m not sure whether to participate there. I will make this dependent on whether my submission will be taken.

Last, but not least, I plan for the XP Days Germany, though I haven’t seen any planning for the conference thus far. Last year the conference was great. Personally I had great exchanges with Alistair Cockburn on methodologies, the Agile manifesto, and a possible future for Crystal. That said, I hope to attend the conference and get to know another great keynote speaker there, hopefully.

Leadership, Software Craft, Testing

Patterns for Test Automation

Leave a comment

Robert C. Martin brought up a blog entry yesterday called The Polyglot Tester. He argues about the Behavior-driven development style of automated tests the table style encouraged from FIT, Slim, RobotFramework and others. While I’m not going to jump into the discussion which of the existing tools is better, worse or more suitable to do some job, here are some references to patterns for test automation, which I came across.

Continue reading Patterns for Test Automation →
Leadership, Software Craft, Testing

People Learning

2 Comments

Nearly everything in software involves some humans doing the job. Today I got a phone call:

Caller: Do you have some resources for me?
Me: Sorry, I don’t have resources for you here. Just people.

Reflecting back on my university years it’s interesting to notice, that we teach computers to learn just like humans, in order to replace humans by computers. But, while we’re doing so, we treat people like things. In addition most of the time people in the software get treated as resources, who can be sent to some course, get a degree or a certification, come back and know everything – inwards and outwards. Sure, this is how it works, of course. Maybe they will be inventing some injections in the near future. Then people – sorry – resources can be as productive all the time without the need to send them to trainings. Now THAT would be an improvement.

This is not how it’s going to work. Let me try to transport this concept to teaching swimming – one of my leisure activities I need in order to gain work-life balance. When setting up a swimming course like most of the projects I’ve been in to, this would look somehow like the following. In Germany the first certification is the “Seepferdchen” (tiny seahorse). By the time the kids know one to two techniques, are able to swim 25 meters (we use metrics here!) continuously and can jump from the edge of the pool right into the water. They can dive and fetch some rings from 1.2 meters depth (metrics!). That’s it.

Now, this is the basic certification a swimming student needs. By then he has the knowledge how to swim through the pool. Ok, let’s put her on a project – a swimming contest. She made her grade with an A, so we better have her sent to the national swimming competition. Of course she knows how to train for the event. Ready, steady go…. What do you think will happen?

Right, when battling the 100 meters against Michael Phelps or Alexander Poppov or Mark Spitz your kid will drown. Why? Because it lacks practice. It does not know how to swim properly with the resistance from the water. The experience of the water pressure is known to her, but not how to use it for her advantage. In addition the muscles has not been built properly to beat with world class swimmers like the ones I mentioned.

There is a pattern we observe each holiday season. Parents sent their kids to our swimming course, because they are going for two weeks to the sea and the kids need to be able to swim by then. Of course, six weeks are enough for anyone to learn to swim. After telling the parents that we have a waiting list for new kids, they take it disappointed to have to wait for a free place. In the end when the kid gets their certification (remember the seahorse), they take the kid with them for their holidays. Why is this dangerous? The kid has just practiced in a safe environment without waves and without streams. The kid knows how to hold their face above the water for some time, but without having the right condition to do it over time when the waves take them out far to the sea. Basically all that certification says, that the kid is able to do basic swimming without saying anything about the abilities.

I hope I raised the point for practicing far enough by now. In order to survive the waves of the software development projects to come, you need to practice your abilities. You need to train and have your programming and testing muscles being built up right in shape in order to survive the streams of the tar pit (see Brooks’ The Mythical Man Month) of software development projects.

But keep in mind that there is no pattern or schedule for people learning. In fact some kids take more than a year to learn enough to get the seahorse certification, others may be able to do the practices for it in just ten weeks. There is no way to have them scheduled on a certain date, because each kid has their own pre-requisite of moving behavior and familarity with water. Compare two kids. The first one has taken baby-swimming courses right after birth and is very comfortable with the element. The other one has nearly survived a fall into the local pond at age of three. The first one is likely to take a shorter period of time for learning how to swim. The second is more likely to have fears against the element that need to be removed before the kid can get trained on the techniques. So, it’s likely to take a longer period. My considerations are not guarantee, though. (On another note I would be happy if I got told about certain fears before starting to work with the kids sometimes.)

I hope it’s obvious to see the similarity to people learning how to test software or how to develop software. People differ in learning styles and learning speeds, but people learn. The difference is to get the hook on the past experiences of the people good enough for them to take the step beyond that gap to the new models you’re providing. Therefore a good learning approach is to settle for multiple models of your teachings in order to get as many people as possible and make them able to refer to your model as well.

Leadership, Software Craft, Testing

Multiple facets

1 Comment

As a swimming trainer I was taught that I reach some of my students with some exercises, some of my students with some tactile impulses while some others need to be taught the model by showing them my movements. Keeping in mind that “correct” is an interpretation from some human, I don’t think there is one and only one correct path to teach anyone anything. People vary in their ways of getting the hook on something.

That said I don’t believe in the single solution of a training model. I believe that we need multiple ways in our toolset to teach people what we’re actually doing. People perceive some of the lessons we teach them by one or more of the following:

  • formal training classes
  • reading a book
  • failure on the job
  • failure in some save environment like a training session
  • watching an experienced professional doing some work
  • (positive) on-the-job experience

Though we don’t make much use of tactile experiences in the software world as I may need as a swimming trainer, there are multiple facets of learning. Based on cultural aspects and diverse background from people there is multiple responsiveness to certain aspect on software development education. This also holds from my perspective for software testers – and I believe for nearly all jobs.

Over the course of this year I got to learn about Coding Dojos. The arrangement there is to have people from the audience brought in to some time-boxed hands-on experience in a save environment. The second aspect is watching two experienced developers developing code. This arrangement sets up people for various learning facets. The more ways we try to set up the learning, the broader our learning audience will be.

The interesting part here is that people can gain experience while they are work. They can be taught what they may need tomorrow. Since the learning is based on a broad set of tools enabling learning, we make sure to include more people – more people that may need more diverse techniques for learning. The concept behind Coding Dojos is very impressive, and it works.

The question that struck me nearly all year is, “May we use this idea also for training testers?” For quite some time I knew there is some way, but I didn’t know my model about. Then something happened that made it very clear for me. More on this in the next blog entry in this series on learning and education.