Imagine you had an elder brother or sister in your family. (S)He is stronger than you, both physically, and trained in martial arts, and you have not. Recently (s)he started to behave weirdly. What would you do? When would you speak up?
A few months ago, I had the opportunity to join Craig Larman at a client for an informed-consent workshop on Large-scale Scrum (LeSS). Ever since I took his class in 2015, I was interested in how he starts off a LeSS adoption – or potential LeSS adoption, I should say. He asked me to do a write-up.
We had overall four days at the client. The first day was half Legacy TDD and half Impact Mapping. For day two and three we were off-site from the client with about 30 employees from different departments including finance and controlling, organizational development, and the CEO. The final fourth day we spent back at the client answering questions, and a three hours all-hands introduction to LeSS.
It’s been a while since I wrote code these days. Back in late April however I found myself in a Coding Dojo at the Düsseldorf Softwerkskammer meet-up working on the Mars Rover Kata. I have a story to share from that meeting. However, since I tried to reproduce the code we ended up with that night, and I decided to give JUnit5 (and Java8) a go for that, I ended up with a struggle.
Back in the days with JUnit4 I used the ParameterizedRunner quite often to use data-driven tests. I never remembered the signature of the @Parameters function, though. The Mars Rover Kata also includes some behavior that I wanted to run through a data-driven test, but how do you do that in JUnit5? I couldn’t find good answers for that on the Internet, so I decided to put my solution up here – probably for lots of critique.
Please note that I used JUnit 5.0.0-SNAPSHOT which is a later version than the alpha, but probably not the final one.
Usually I don’t write many promotions for other’s contents on this blog as I try to keep it personal and focused on my personal views. Recently I was contacted on the International 2016 State of Testing report, and whether I would like to do a write-up about it. I asked whether it would be ok to post a personal view, so here it is.
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.