Sometimes while reading along song lyrics, I get some silly inspiration. One of these days, recently I listened to Let there by Rock by AC/DC and got the following idea for an Agile version of the lyrics.Continue reading Agile Songs – Let there by Scrum
Category Archives: Scrum
Agile Songs – Hymn
Sometimes while reading along song lyrics, I get some silly inspiration. One of these days, I crossed Hymn from Edguy, and found some Agile adaptation to its lyrics.Continue reading Agile Songs – Hymn
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.
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 Power of the Team
Agile methodologies favor effective team work. Team work is fun to do, hard to grow, and at times unpredictable to nurture. I might be biased here, but I have seen way too few good teams working effectively together. Let’s see what can happen with bad and with good team work in place.Continue reading The Power of the Team
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
Over the past year I ran a couple of Scrum trainings. At first I found it sort of funny to notice that amount of misconceptions that seem to appear in these various classes. Recently I figured that it would be more helpful to clarify some of them. Among one of the larger, and probably more manifested misconceptions regarding Scrum lies in the Sprint Review meeting. Let’s examine that one today. I am quite sure that someone has written about this before. I found that it would be worth to throw in my point of view as well.Continue reading Continuous Acceptance