Category Archives: Leadership

Technical and personnel leadership

Journal, Leadership, Software Craft

My Long Road

1 Comment

Yesterday I finished reading through Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman from Dave Hoover and Adewale Oshineye. Personally I met Ade at the Software Craftsmanship conference in London earlier this year and participated in his session on Mapping personal practices. After I came back I used the format for Personnel development. Since May I have a video from Ade open in my browser tabs on How to walk the long road, which I still haven’t seen, yet. So, just after finishing the book, I decided to describe my personal development as a reflection of the last four years of my life using the pattern language provided in the book. So, here it is.

Continue reading My Long Road →
Leadership, Software Craft

Dial the manifesto

2 Comments

Elisabeth Hendrickson put up a response on Why I defined Agile in terms of results on her blog, which made me thoughtful about the dialogue I had last weekend with Alistair Cockburn on the XP Days Germany. Though a more thorough write-up of the conference from me is still missing, I decided to respond on Elisabeth Hendrickson’s blog entry.

During the Open Space session on Saturday Cockburn introduced to us the use of the value statements in the Agile Manifesto as dials. Overall there are eight dials on the meter to consider:

  • Individuals and interactions
  • processes and tools
  • Working software
  • documentation
  • Customer collaboration
  • contract negotiation
  • Responding to change
  • plan

Based on the particular context we tune the amount of individuals and interactions and the amount of processes and tools. Likewise the remaining six values can be adapted to our particular situation. Indeed, we value all eight mentioned terms. That means that we may sometimes need to create documentation. As Hendrickson pointed out to me at the Agile Testing Days earlier this year, being Agile does not equals being stupid. If there is need to create that thorough documentation so that you can be set-up for the next round in the Cooperative Game, then you better create it – now! On the other hand if you find out that you’re documentation is mostly waste, then you should reflect on how to recude it or get rid of it completely. But you need to consider your particular situation, the project, the customer, the people involved at hand. That is what good coaches do.

The second thing Cockburn pointed out was the fluent up and down among practices, principles and values. During our work we keep on continuously switching from one level of abstraction to another, up and down. Some time ago I thought that this fluent switch among the levels is comparable to skill-set development with Shu-Ha-Ri. The main difference is, that you go through the Shu-Ha-Ri stages when learning a new techique, like TDD or Refactoring or facilitating Retrospectives. When working in an Agile team, you switch quickly between the values like simplicity or responsibility and the practices and principles, like TDD, Refactoring or Emergent Design. From time to time you may adapt and adopt some of your principles, practices or even values. Indeed, the Software Craftsmanship Manifesto is just a result of such a value shift. Giving the Agile values, we have put our new values beneath them. This does not mean that we don’t value the statements from the Agile manifesto, but we found new value statements that we think are worth to consider for the next ten years or so.

Getting back to Elisabeth Hendrickson’s write-up, focussing on the results is essential in all the above. When we loose our focus on resulst, we start to day-dream and seldomly get something productive finished. You can use the dials from the Agile or Software Craftsmanship manifesto to finetune your situation, but do this based on the results you already got. The essential thing here is still reflection. Without reflection I constrain myself to self-blindness and No-Problem-Syndrome thinking. This hinders innovation and improvement in your actual work.

Leadership

Problem-solving with First-order measurements

Leave a comment

Today I attended a meeting at work, where I noticed a pattern. It was a problem solving meeting. Problem solving in the sense that it was identified where we wanted to get, then identified where we are and between both positions is the problem that needs to be solved.

The target

The pattern I realized is the fact that it seemed to be pretty clear to everyone in that meeting where we wanted to be at. Though where we wanted to be was clear for everyone I suspect in retrospection that we had a shared understanding of this. The target was implicit. No one spoke up where this would be. Personally I think the target was ambigious and therefore not well defined. Recently I read a similar example in Quality Software Management Vol. 2 from Jerry Weinberg. The amibious term in his example was “Quality”. In his example everyone would like to have “Quality”, but he found out about the different understandings of “Quality” by asking control-questions.

The current position

Since there were just weak second-order measurements available and no common understanding of the situation at hand, it was hard to gather where our current position was. There was a lot of speculation. Since we were hit with a problem from our colleagues in a timezone three hours behind ours, we did not have immediate feedback. Instead we had filtered feedback through some emails and through participants who attended the chat the night before. This feedback was filtered, uncomplete and in order to find out the current position the meeting participants where vaguely speculating bringing in their own interpretations about the meetings at hand.

The problem

Overall we did not have a shared understanding of our target, no common understanding of where we were at this very moment. Therefore the problem we had to deal with was a meta-problem. The problem between the position where we wanted to be and where we were was fluent and not-distinguished. Therefore the problem to be solved in that meeting could not be understood and therefore not solved. The problem we had in that meeting had to do with the problem that we failed at the first two steps of problem solving and since this meta-problem was not solved, we could not solve problem.

Solving the meta-problem

In reflection in order to solve the meta-problem here are some alternatives that could have helped:

  • Shift the meeting to a later time, so that our colleagues can give us direct feedback, rather than relying on emails and filtered or biased feedback.
  • Abandon the meeting when you find out the participants are not prepared with the information available at the meeting start. Usually you just need to this once in a learning culture.
  • Have a skilled facilitator, which is prepared and has no hidden agenda. This is difficult to realize in a project, which needs to hit the ground this year in recession times.

When you’re faced with a meta-problem the next time and realize it, pick your favorite from this list.

Leadership, Software Craft, Testing

Responding to Change

2 Comments

During my stay in the US during our vacations this year I was able to collect some notes and reflect on some stuff in the real world and compare it with software development occassionally. Today I decided to do a write up on the “Responding to Change” value of the Agile Manifesto.

While finishing the book The Pragmatic Programmer I got confronted with some concepts that I also noticed in the real world. Early on in the Design Patterns movement I learned to decouple my code as far as possible to allow change to happen. Craig Larman and Robert Martin early on got me into this thought process.

Being a European there were quite a bunch of things different in the US as here at home. Here is a list of things I noticed and I was wondering how hard it would be to change them in our software system. Luckily most of the things I wasn’t able to find at all, whereas most major variation points like currencies or tax systems were also thought on. How does your software respond to change it to the US system? What about selling your software to a European customer? For the testers and checkers among you, would you test that your software supports these? Do you test your software supports these? Does your software support them? Here’s the list, make the test, build up your mind and maybe let me participate in your findings.

Currencies There are a bunch of currencies I was confronted with. Euros of course, Deutsche Mark in the past (does anyone know what a “Groschen” is?), US Dollar, Pennies, Dimes, Quarters, Cents (does your software support the ¢ sign?), Disney Dollars (you can actually pay with it in Walt Disney World ressorts or take them as a gift for your mates at home), …

Tax Maps In the US every single state has a different tax model, even every county can have it’s own. In Germany there are different taxes applied usually, the lower one for food, the higher one for the rest. In Brasil there are 27 states each with their own tax model. Tax laws seem to be the most complex stuff.

Distances Meters, millimeters, centimeters, feet, inches, miles, kilometers, bavarian ells, english ells.

Area sizes Square feet vs. square meters.

Volume Litre, cubicmeters, Gallons to name just some.

Temperatur How many degress Celsius is one degree Fahrenheit? Is 90 degrees Fahrenheit hotter than 30 degree Celsius? What about Kelvin?

Fuel prices How much is 2.59 USD per Gallon in Euros per litre?

Consumption Is a fuel consumption of 28 Miles per gallon the same as 5 litres per 100 kilometers?

Voltages 110V vs. 220V vs. 400V, AC vc. DC.

What did I forget? What hard to change facts do you have to deal with?

Agile Testing, Journal, Leadership, Test Driven Development, Testing

August of Testing

Leave a comment

This blog posting will serve as a catch-all for the web-pages I left open on my tabs during the last few weeks. In case you’re interested in what I did since the beginning of August, it might be worth a read for you.

Back in July Mike Bria posted an article on Test objects, not methods. His lesson boils pretty much down to one single quote that I need to remind myself of:

Keep yourself focused on writing tests for the desired behavior of your objects, rather than for the methods they contain.

Over the past weekend Michael Bolton came up with a final definition on checking vs. testing. Lately I argued whether or not we need a new name for testing. Michael Bolton was able to explain to me in this post that we do not need a new name, but a proper definition. This definition in combination with Perfect Software gives you pretty well insights into what to expect from testing and what to expect from checking. Adam Goucher summarized a talk from Chris McMahon at the Agile 2009 conference with the following insight:

The only reason to automate is to give expert testers time to manually test.

Ivan Sanchez stated that there is another area where a term got lately abused with vague definitions. The term is “done” and he calls for stopping redefining and redefining it. Basically my experience shows that the same is pretty much true to a lot of words in our business. Lean, Test, Done, Agile, …. maybe you have more of these for the comments.

On my way home today I thought over a job profile I read over the past month. Basically when transporting it to my company I would include “You know the difference between testing and checking” in the skill list.

Finally Matt Heusser put up another test challenge. What I loved about it was the fact that I could more or less directly relate the lesson to my daily work. So it’s nothing really artificial if you build the bridge between the abstract challenge and your real-world project. Oh, and of course, for a geek like me it was fun. Wonder, if I could do the challenge in the real-world, once. I love lightsabres. And as a black-belt member of the Miagi-Do school I had to take that challenge, of course. Feel free to exchange some thoughts on the challenge with me if you have taken it.