Recently I was reminded about a blog entry from Kent Beck way back in 2008. He called the method he discovered during pairing the Saff Squeeze after his pair partner David Saff. The general idea is this: Write a failing test on a level that you can, then inline all code to the test, and remove everything that you don’t need to set up the test. Repeat this cycle until you have a minimal error reproducing test procedure. I realized that this approach may be used in a more general way to enable faster feedback within a Sprint’s worth of time. I sensed a pattern there. That’s why I thought to get my thoughts down while they were still fresh – in a pattern format.
Last year, I interviewed Jerry Weinberg on Agile Software Development for the magazine that we produce at it-agile, the agile review. Since I translated it to German for the print edition, I thought why not publish the English original here as well. Enjoy.
During the Agile 2014 conference in Orlando, I talked a lot with Matt Heusser. Over the conference we bounced back and forth one or another idea. In the end, we had an idea for a new book: Save Our Scrum. A self-help book on many of the troubles we see out there happening with this wide-spread approach. We had the vision to base some of the lessons we learned in our consultant work, and see how we may help others with this. That’s the whole vision.
Skip forward one year, and we made some progress. We finished off the first few chapters with a more general introduction to Scrum itself alongside with some of the problems we are seeing. At one point we decided to put out what we had created thus far, in order to receive feedback from the people that are seeking such help. That’s why we recently put it up on LeanPub, so that folks can get access to it, and help us continue the momentum with great feedback.
Matt and I are pretty busy in our consultant work. That slowed down progress a bit in the past months. Right now, though, we seem to be in a writing burst with new content created constantly throughout the week. We started work on getting down the nuggets – that’s what we call the little lessons from all over the world with teams struggling with Scrum.
That said, if you get the book now, you will receive weekly updates – that’s what we promise you. Every week we publish anything that we have created throughout the week. We hope to keep progress flowing. I think this week both of us each worked on getting down at least four nuggets. That’s eight new lessons for you to read. If we can maintain this progress, we expect a good draft finished by end of September.
But, wait, there is more. You can get famous by helping us. We opened up feedback channels. We created a Slack team for open discussions. This is not limited to typos and missed commata, but you may also leave us your thoughts on nuggets that we forgot there, or share struggles that you have to improve our book.
We really look forward to your feedback and ideas and suggestions to advance our book. Hope you will enjoy it. And if not… well, at least you know some channels now to let us know.
In my courses, one or more of the participants almost always raise a question like this:
How do you set up a team across many sites?
Almost always when digging deeper I find out that they are currently working in a setting with many sites involved. Almost always they have a project organization set up with single-skill specialists involved. These single-skill specialists are almost always working on at least three different projects at the same time. In the better cases, the remote team members are spread across a single timezone. In the worst cases I have seen so far, it had been a timezone difference of ten hours.
I will leave how to deal with such a setting for a later blog entry. Today, I want to focus on some tips and tricks for working with remote team members and remote colleagues.
Tripit reported that I was on the road in 2012 for 304 days. I hardly believe that since I stayed at home for our newborn son Nico the whole June back then. (I think they have had a bug there.) But it was close. I have worked with remote team members and remote project teams in distributed companies since 2006. I hope I have some nuggets worth sharing.
End of August two years ago, I announced that I was going for the AST board. I kept my expectations pretty low, and I am glad that I did. Two years have passed, so I figured let’s revisit that decision from back then. Long story short: I won’t go for another two years. Read on to find out why.
Last year, when the Association for Software Testing announced the location for their next annual conference CAST 2015, Grand Rapids, MI, there was an up-roar happening on social media and back channels like Skype and private conversations. To my own surprise, I saw members of the context-driven testing community falling short of their very own principles. Rather than observing and interacting with people, it seemed that some persons preferred to derive their knowledge about Grand Rapids based upon a prior CAST conference there. Experience may be a good resource to start looking at, but I found that I should trust the folks from the local area that I knew to put together an awesome conference – more so since they could explain to me why the past experience was not so well received. When it came to the October 2014 AST board member meeting, Pete Walen, the conference chair, the guy who managed to send in a proposal prior to CAST 2014 so that the AST board could decide upon it, invited us to the conference location, so that it was easy to see for us where we were going with the proposal. Here is what I learned during my two nights in the conference venue – and why I think you should attend.
A while ago I considered adding some new type pf posts to my blog. There are many things that I notice in my leisure time at all the different spots that makes most folks wouldn’t think about, yet I see a relation to some of the stuff that I learned while diving into Agile software development. This blog entry kicks off these new type of posts.
I am not sure about other places on Earth, but in Germany the McDonald’s corporation recently started to re-design their restaurants. (Yes, I admit that at times a McDonald’s is one of my choices to take something to eat while switching trains.) They are now offering two types of counters together with a self-service counter using credit cards or bank cards. The in-person counters a split by the counter where you order and pay for your meal, and the counter where you can then pick your meal. Based upon subjective experiences, I think this move is a dramatic move away from customer friendliness.
What’s the problem?
My observation into many of these encounters was, that I needed to wait way longer to get food than it was the case before this re-design. Waiting times used to annoying to us customers even in the old design, but now with the new design, things got worse according to my personal experiences. Of course, it’s not much of a problem if there are few other customers. But imagine the situation when a full train arrives with hundreds of passengers during lunchtime at a local train station. Some of them at least will walk into the nearest McDonald’s to grab some food.
In the old workflow design, there were usually three to five counters open during such high times. There were several queues forming in front of these counters, you would be waiting in line for your turn, order, pay, wait for your meal to be prepared, and then leave. Overall this had been between 5-15 minutes at times for me.
Now let’s take a look at the new workflow design. You enter the restaurant, see two open counters with lots of folks waiting there, and you see the full list of already ordered meals on the screen above the counter for the pick-up. If you’re like me you check the self-service machines in such case. Funny thing is that in 95% of the times I ran into such a situation, these were out of order.
So, we get in line in front of the in-person counters. We wait until it’s our turn, order, pay, and receive a receipt with a number for the pick-up counter. There you queue up until it’s your turn to pick up your meal. But wait, there is only one guy serving the pick-up counter. So, all the customers from the two in-person order counters end up in a single queue to get their food. It would be even worse if one or more of the three self-service machines worked.
What’s happening here?
As Mary Poppendieck taught me a while ago, whenever there is a queue, there is certainly sub-optimization happening. What’s the sub-optimization here? McDonald’s seems to optimize for cash-flows and sparing personell costs from my point of view. Two in-person counters, and one guy serving the meals is three quarters of the salary they used to pay before the re-design.
Of course, people wouldn’t buy into that without some benefits. The self-service machines and the new fancy restaurant layout seem to be the selling points here. But it seems that they have under-estimated the demand and the necessary queues for such a move.
So, what’s better about the old system?
Did you notice the hand-off between the two counters? Yeah, I think this is the major culprit. On face value, you saved one person’s salary with the new workflow. On the other hand, you made it way harder for people to support each other.
Consider this situation that I observed last week. The pick-up counter was heavily under stress with 5-10 items still in line. At some point one of the in-person counters clerks decided to help them out, move from the counter, and got into the kitchen. Unfortunately the other cashier also had to leave for some reason I didn’t get. I observed five new customers stepping into the restaurant totally confused about where to get food, since none of the cashier stations was served.
The problem is that the new workflow makes it close to impossible for other people in the restaurant to help out the current bottleneck in the overall system. In the past I have observed folks from McCafe stepping in to help out others if there was a need. Now, it’s impossible.
All of this came with the specialization that slipped into the workflow from separating cashing and food preparations. The one additional hand-off made it less likely for me personally to enter a McDonald’s restaurant if I want to use my 15 minutes train switching time to grab something to eat. Maybe my wife will like this in the long, but on face value, I think McDonald’s harmed their overall business more than necessary with this one additional hand-off and specialization that happened alongside.
I certainly don’t know any business numbers from McDonald’s, but I imagine that client happiness with the new workflow restaurants dropped dramatically probably resulting in fewer returning customers.
Now, think what happened when the software industry introduced hand-offs between Analysis, Design, Architecture, Coding, and Testing.
Every once in a while I read something like this:
Yeah, [TDD|BDD|ATDD] is great. But how do you convince [your manager|your employer|your colleagues] to get the time to do it?
In the past week I decided that I need something to point folks to when this questions comes up again. So, here it is.
Continue reading How to sell TDD to <x>?
Since I am publishing this on my personal blog, this is my personal view, the view of Markus Gärtner as an individual.
I think the first time I came across ISO 29119 discussion was during the Agile Testing Days 2010, and probably also during Stuart Reid’s keynote at EuroSTAR 2010. Remembering back that particular keynote, I think he was visibly nervous during his whole talk, eventually delivering nothing worth of a keynote. Yeah, I am still disappointed by that keynote four years later.
Recently ISO 29119 started to be heavily debated in one of the communities I am involved in. Since I think that others have expressed their thoughts on the matter more eloquently and deeper than I going to do, make sure to look further than my blog for a complete picture of the whole discussion. I am going to share my current state of thoughts here.
The other day, I sat down Kishen Simbhoedatpanday in order to talk about ATDD, and eventually an upcoming class on the implementation side of ATDD. We talked about maintainable tests, and how you could refactor tests to yield better tests. Gojko wrote about the anatomy of a good acceptance test a while back, and I think we can be more explicit here. Then it struck me. The Single Responsibility Principle also applies to your automated examples – and why that’s the case. You just need to think on a conceptual level about it. Mixing business domain concerns with application concerns in your examples – and sometimes even with driver concerns (think Selenium) – is a terrible thing to do.
Let’s explore this idea further.