Tag Archives: it-agile-blog-planet

Process in Kanban

Something bothers me for a while about Kanban. These thought re-awakened during James Bach’s keynote at the Let’s Test conference in May. James was talking about the 1990’s movement into process. Processes needed to be everywhere. That’s why he became engaged with what turned out to end as the context-driven school of testing. Here is a quote that I heard in one form or another from the Kanban community:

The process needs to be defined, published and socialized — explicitly and succinctly.

(I got this from here.)

The Kanbanistas keep on confusing me with this. Here is why.

Continue reading Process in Kanban

Which Agile project management tool should we use?

Maybe it’s just me, but the whole “which Agile project management tool should we use” debate drives me nuts.

Maybe it’s just me, who can’t understand what “Agile project management” means to start with. Try to think in products, not in projects. Your product portfolio is the bigger problem, not how you taylor the work to create multiple projects.

Maybe it’s just me, who does not understand a thing about project management, but about software development instead. I don’t know what I want, but I know how I can get it: take small steps, iterate and reflect.

Maybe it’s just me, who heavily remember Conway’s Law:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

(Source: Wikipedia)

Maybe it’s just me, who also understands the other direction of that law. Once you introduce a tool, it will constrain how you think about changing your organization. That said, it will keep you away from meaningful steps once they become necessary.

Maybe it’s just me, but we shouldn’t be talking or debating about Agile project management, or about Agile tools. We should discuss about what makes us successful. Remember: A fool with a tool is still a fool.

Pro-rating Testing Challenge

I am currently reviewing a book on domain testing. While doing that I realized I can put up a testing challenge based on what I annoyed my colleagues with a few years back. I disabled comments on this post in order not to spoilt future visitors of my blog. You will have to find another way to respond to this.

Imagine a service which is rated on a monthly basis like Spotify, Watchever (they don’t pay me for writing this blog), pay-TV, phone lines, or mobile phones. Usually that means that you have a fixed monthly rate.

Now, the business prescribe that you have a monthly fee that you need to pay. For example for Spotify premium this is 9.99 EUR, and something else for some other service. The business rules also provide that you can cancel this service mid-month before payment. Then you will be charged only the pro-rated amount of the monthly fee for the current month. For example, if the payment period starts on the 1st of the month, and you cancel the service on the 3rd of the month on a 30 day month, you will only pay 2/30th of the monthly fee for the final month.

Unfortunately we deal with a larger system. In that system the pro-rating is transporting from the domain subsystem to the billing subsystem via the percentage of the prorating. That means that for the above scenario we will trigger some process on the billing backend with 1/15th in percent, yielding 6,666666666667 percent. The value used here is a double-precision floating point value.

Analyze this program (consisting of both subsystems) for interesting variables, what could go wrong, and how would you test it?

Where are the German testers?

On the bottom of James Bach’s recommendations of people there is a small paragraph:

That One German Guy

Germany has no excuse. There are TONS of smart people there. How is it only one intellectual software tester has emerged from the ISTQB-addled masses to demand my respect with his work? My theory is that Germany has a more command-and-control culture, which perhaps disparages independent thought of the kind required to achieve excellence in testing. This pains me, because I am descended from Germans and I would love to visit and teach there.

Anyway, the one German guy who shines in my community is Markus Gaertner. I’ll do a write-up on him, shortly.

Yeah, it’s about me. From time to time I am asked by James and other people in our community where the German testers actually are. Here are some folks I am in touch with, that have raised my attention, and I think will need some attention from the wider community. There is not only one guy testing in Germany, seriously.

Continue reading Where are the German testers?

Debugging Communication

Here is a thing I learned from J.B. Rainsberger at XP 2012 in May 2012. I used it in the past months quite extensively for debugging communication based upon the Satir Communication model. While doing some research for this blog entry, I discovered that some others have also written about the topic. I especially liked Dale Emery’s Untangling Communication which seems to go a bit deeper than my understanding of the topic. Anyways, here’s my write-up which might give a different perspective.

Continue reading Debugging Communication

The Wandering Book

20130425-200545.jpg

Recently I restarted the Wandering Book. The Wandering Book is a tiny book passed on from Craftsman to Craftsman, fromCmmunity to Community intended to collect the Zeitgeist of Software Craftsmanship. I deliberately decided to start passing this to the German Softwerkskammer user grups. The idea is to collect the different notions, sort of a guest book of all the local events happening all over Germany.

Since the first book seems lost, I decided to put a disclaimer in it at the beginning. Here is the initial entry I made.

Continue reading The Wandering Book

Automated vs. exploratory – we got it wrong!

There is a misconception floating around that Agile Testing is mostly about automated checking. On the other way the whole testing community fights since decades about the value of test automation vs. the value of exploratory testing. I find these two different extreme position unhelpful to do any constructive testing. Most recently I ended up with a model that explains the underlying dynamics quite well, to testers, to programmers, and to their managers. Here’s the model.

Continue reading Automated vs. exploratory – we got it wrong!

My journey with Jerry Weinberg

I came across this blog entry earlier this week. While I also can resonate with most of the books that Soronthar read from Jerry, I felt like to tell my own story with Jerry’s books. Among my colleagues I am most well-known to cite a lot from Jerry’s work – mostly that is because I took the effort to type-copy the references to his meaningful laws on my computer, so that I can pull out Rudy’s Rutabaga Rule from the Secrets of Consulting quite easily:

Once you eliminate your number one problem, number two gets a promotion. (The Secrets of Consulting, page 15)

But that’s not where my story with Jerry started. Here’s the full story.

One word of disclaimer: I know a lot of people that are not comfortable reading Jerry’s books. To most of them I have a lot of respect. And I think it’s ok, if you can’t read his books. I am just going to share, what I learned, and what sticks even years later.

Continue reading My journey with Jerry Weinberg