Category Archives: Scrum

Scrum

My view on the current state of Agile

Stick along long enough in software development, and you may have come along the ride for Agile software development practices, methodologies, and/or frameworks. Stick along long enough in that community – ok, that might be a reach too far, given that community only exists about 30 years or so. All of the above said, I notice some developments lately around the term Agile, and need to get my thoughts down. Not that I think I have a particular relevant perspective to start with. But maybe I can offer some perspective to one or another reader.

If you know me, you probably know that I have a tendency to look back on where did we come from to better understand things happening in the present. If you are not that kind of understander, maybe this blog entry might not be for you. So, be warned before moving on.

Continue reading My view on the current state of Agile

Team interaction pattern: the ambassador

A couple of times, I found a particular pattern of interaction from a team with some other group (or team) useful. I would not recommend it all the time, but there appear to be appropriate use cases every now and then. Since I didn’t cross similar thoughts in the Team Topologies book, I thought it useful to write up as inspiration for others. Let me introduce the ambassador to a team.

Continue reading Team interaction pattern: the ambassador

Informed-consent workshop on LeSS with Craig Larman

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.

Continue reading Informed-consent workshop on LeSS with Craig Larman

Testing inside one sprint’s time

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.

Continue reading Testing inside one sprint’s time

Save Our Scrum – Tools, Tips, and Techniques for Teams in Trouble

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.

Scaling Agile – really?

There seems to be a buzz around scaling agile around lately. A couple of weeks ago I saw a tweet from Gabrielle Benefield that made me think.

Screen Shot 2014-03-06 at 19.28.03

Why is everyone hell bent on scaling Agile when they have trouble even getting one team going?

That question reminded me about a lesson I learned from Don Gause, and Jerry Weinberg in Are Your Lights On? What’s the problem? Who has the problem? And who should fix it? Let’s see.

Continue reading Scaling Agile – really?

The Curse of Refactoring

Last week I sat in a meeting with a ProductOwner, a ScrumMaster, and the Development Team. The team works on a legacy code base with about 2 million lines of code together with 13 other teams. Thus far there has been little to decouple the various components. In that meeting the topic of refactoring came up. The bottom line was that the Development Team needed to ask the ProductOwner for time to refactor their code for each story.

What a waste of your time.

Personally, I believe that if you have to ask your ProductOwner to plan in time for refactoring, the ProductOwner should stop all work on the product, and send you on a class on working effectively with legacy code if you are an internal employee. If you are an external employee, your client should fire you immediately.

Wait, what? That’s harsh? I don’t think so.

Let’s take a look at the underlying system dynamics.

Continue reading The Curse of Refactoring