Brendan Enrick

Daily Software Development

Ball Flow Like Champs

I enjoy the Agile Ball Flow Game. It’s a challenge that emphasizes a lot of what agile practitioners find value. The theme of the game is that you’re working in a toy factory and you create toys by passing them around to the other workers. Each worker needs to touch the toy at least once, no two workers can touch the same toy at the same time, and you can’t pass the toy to the person next to you. As orders come in, you try to complete the orders as quickly as possible. If you mess up one of the toys (drop it), you have to start over creating the toy.

In the game, you want to keep track of when you start making each toy and when each one completes. This lets you track your lead time, cycle time, WIP, etc. From this information, the group can see what works well and what doesn’t. They can determine how to adjust their process to improve their toy-making abilities.

At the Hudson Software Craftsmanship meeting earlier this week, we performed the agile ball flow game. No one there had done it before, so it was a great opportunity to see how they would organize themselves and complete the solution. In total, we had 14 people at the start of the game.

Round 1

I started the group off with 20 multicolored balls. The hollow plastic variety commonly found in children’s ball pits. They’re easy to toss short distances, but can be tricky for a long distance toss.

They first created a circle to facilitate passing. One thing they did very right was passing 1 ball around as a demonstration so that the whole team could practice and get an idea of what they were going to be doing. Much better than just assuming that everything will work as expected!

They completed the full order of 20 in just over a minute and thirty seconds. A few of the balls dropped, but were picked up and reintegrated into the process. Their effective process worked so well, because most of the team had enough slack to not feel overwhelmed.

Round 2

In the second round, the team estimated that they would be able to complete things faster. They estimated the time to complete to be around 45 to 60 seconds.

As part of their retrospective, they realized that their pull model they were using worked effectively, but if they shifted forward and backward a little bit, they could pass more easily. This was their slight adjustment to the process.

It worked! They managed to keep more balls from falling in the second round and really improved their time! They noticed that their issue was in contentious passes around the circle, and they adjusted to account for it. Well done! They were a hair under 40 seconds, which is the fastest second round time I’ve ever seen.

Round 3

Kids these days aren’t just interested in those old-style toys, which means that the challenge needs to change a bit. They’re still fun, but the new thing is dart guns, so now the team needed to also pass around foam darts. With such a well oiled machine, could these darts present a challenge?

The darts are tricky, because one end is rubber and weighs a bit more than the other end. These were obviously more challenging to pass, and the group spent some time discussing how they would work.

The team decided to start with the darts to get the more difficult items out of the way first. At first, this seemed to work, but darts started falling. After starting most of the darts a second time, the group ended up with a time just over a minute and twenty seconds. Not bad, but quite a fall from round 2.

From the retrospective discussion, the group established that they needed to drop the darts into people’s hands. Tossing just wasn’t working well. They also decided that they should probably send multiple darts at a time since they were going to be dropping them, it should be safe to do.

Round 4

Armed with a new plan, the group decided to start the darts 5 at a time, which would mean 2 sets of darts traveling around the group.

Not surprisingly, only 3 darts of each set made the round trip. Still probably an improvement, but it might have been better to have done 2, 3, or 4 darts at a time instead. Perhaps something to try in the future.

This round was full of dropped items and ended with 1 dart making the rounds all alone. In the end WIP was just 1 for the whole group. The time wasn’t bad, but it was obvious that the group could do better. So far they hadn’t made any huge gaffs either though.

Round 5

This round was about being more careful and getting the passing in place as best they can. Perfect answer, team. They knew not to make big changes. What they were doing was working, and they were seeing improvement. A big change here would just upset things.

The group finished on a high note, being one of the more successful groups at ball flow that I’ve seen. They completed the challenge like champs. Not once did they try something crazy like shooting WIP through the roof (I’ve seen it!)

Agile tells us that we need to limit WIP and bring cycle times down. Those are the focuses of the agile ball flow game. It lets the group self organize through planning, spiking, testing, and doing retrospectives. If you want to teach a team about agile, the ball flow game is a great way to do it!

I primarily use Karl Scotland’s method of running the agile ball flow game. Make sure that you also use this spreadsheet template when running the game. It makes tracking times much easier.

Three Years of Software Craftsmanship

Almost three years ago, Steve Smith, Rich Henning, and I founded the Hudson Software Craftsmanship Group (HudsonSC) in Hudson Ohio. We scheduled our first meeting for August 19, 2009 and we had plenty of people show up. Since that time, similar groups have sprung up in NE Ohio and other areas around the country. It’s really neat to watch as the software craftsmanship community grows. There are other groups, dojos, workshops, etc. all over the place.

Our group has been a model of other groups around the area as well. Brian Friesen attended one of our meetings as a bit of research before starting the Knoxville Software Craftsmanship Group. Brian Friesen is quite dedicated, because the drive up to HudsonSC is over 8 hours. What that means is, if you’re in that area and want to attend a meeting with a dedicated software craftsman, check their website regularly they’ve always got their meetings posted.

Our number of attendees fluctuates between highs of 20-30 people down to lows of 5-10 people. We’re usually somewhere between 10 and 20 attendees. These numbers are great for a group like ours. If you get much larger than this, it becomes nearly impossible to have a discussion.

How Software Craftsmanship Groups Stand Out

We’re not eyes-front, pay attention to a speaker kinds of groups. If that’s what you’re looking for, HudsonSC is not for you. There are plenty of groups that meet every month across the world that have this format. We focus on discussions and self-organization. Our members suggest topics they want to discuss. We try to get everyone contributing instead of just taking notes on someone else’s “wisdom”. Everyone in our group has something to bring to the table and adds value to the community as a whole. You can take notes after the meeting.

HudsonSC’s Agenda:

  • Introduction
  • Lightning Talks, Show and Tell, and Opening Discussions
  • Open Spaces and/or Group Discussions
  • Exercises (usually programming)

Our members bring laptops to the meetings so that we can write some code and pair with other people. Our group is not buried in their laptops nor is it tweeting away. When you attend a software craftsmanship group, you participate in the event. You are the speaker!

Third Anniversary

As I mentioned at the beginning of this post, it’s been nearly 3 years since we founded the group. Our third anniversary meeting has been scheduling and you can sign up for it now. The event is going to be held on August 15, 2012.

To celebrate this event, we’re going to have a spectacular evening or talking, discussions, and programming exercises.

I look forward to seeing you at our next HudsonSC. If you’re not in the area, go check out your nearest software craftsmanship group!

Sign up for HudsonSC here!

http://hudsonsc0812.eventbrite.com/

Open/Closed Principle and Reinventing the Wheel

This month at the Hudson Software Craftsmanship group, we had two interesting discussions that were spawned from the NimblePros Software Craftsmanship Calendar. The calendar’s topic for March 2011 was the Open/Closed Principle and the topic for March 2012 is Reinventing the Wheel. Keep in mind that 2011 is a calendar of good practices we want to encourage and the 2012 calendar is full of anti-patterns to be avoided.

This post is a recap of some of the stuff we discussed at the March, 2012 HudsonSC meeting.

Reinventing the Wheel

Going into the meeting, I had the thought that Reinventing the Wheel is obvious when you’re doing it and Open/Closed is less obvious when you’re not following it. Boy was I wrong. The main discussion we had about Reinventing the Wheel was based on “how do I avoid reinventing the wheel in a large, badly organized code base”. We had a lot of very good ideas and suggestions about how we can try to avoid this through tools, communication, and a variety of other methods and ideas. It’s interesting though, because none of them really are the silver bullet that just solves this challenge. If you don’t know if something is already written in the codebase, it can be a real challenge to find.

Open/Closed Principle

For the open closed principle, we discussed how we use it, when it’s used, and whether we should start of our code building for open/closed. I think most people came to the consensus that it’s likely not a good idea to use Open/Closed right away, but that we should refactor to it when we’re changing the code. The thought here is that if we change it once, we might need to change it again, so the next time we need to extend it instead of changing it.

Make the code better now and we’ll save ourselves time later.

Supermarket Checkout Exercise

As our programming exercise at the end of the day, we decided to do the Supermarket Checkout programming exercise. It is an interesting little challenge that involves some design decisions. This is what makes it interesting.

The exercise has the developers writing a checkout system for a supermarket. Essentially, it’s about calculating the price of the items as their scanned. It factors in discounts, selling by quantity or individually, and selling by weight. This information also needs to be presented to the customer on a receipt at the end of the transaction. This means that you need to figure out how to give the user the needed information in a nice, clean way.

As you work on the code, you have to make some decisions on how the code is going to interact with the customer. Should the discounts appear inline immediately or at the end? Is the discount a separate line item or shown in the price? How do these choices affect how you’re writing the code? Some have you returning information immediately and some have you gathering the information later. How do you adjust your design decisions based on this?

You can find a link to this programming exercise and more on my List of Katas and Programming Exercises. And, because I am not a total jerk, I will give you a direct link to the kata pdf in case you don’t want to check out my other blog post.

Supermarket Pricing Coding Exercise (Sample Output)

The Sample Output is optional to use. You can also come up with any sample output that you wish to use for it. Change things up. Or do the kata and then pretend that the business rules have changed and now you need to display the information differently.

July HudsonSC

The Hudson Software Craftsmanship Group will be meeting July 20, 2011 at 6:00 p.m. with people arriving as early as 5:30. As usual, we will be ordering pizza, and some of us will be gathering at Kepner’s Tavern after the event to continue our discussions.

If you haven’t attended HudsonSC yet, I highly recommend the group. We have a fantastic group of software craftsmen who are always trying to improve their skills as developers. If you’re interested, please sign up to let us know you’re attending. We will also not turn people away at the door, so feel free to just show up for the event.

The event is located in downtown Hudson at 102 First Street. When you enter the building, just go to the second floor and turn right. Keep walking straight, and you will arrive in our meeting room.

This month I am going to suggest to the group that we try an AppKata instead of our usual programming exercises. These focus more on real-world scenarios and include changing requirements.

We are very loose with our agenda, so if you want to bring in something to talk about or an activity to do, go for it. In fact, you can show up and suggest topics and ideas for that day’s meeting.

See you there!

One Year of Hudson Software Craftsmanship

HudsonSC Over a year ago, Steve Smith, Rich Henning, and I met to plan our first meeting of the Hudson Software Craftsmanship group. We decided on a format for the group, planned how we were going to organize the events, and came up with some topics to discuss for our first meeting since we didn’t expect people to arrive for the first meeting with lightning talks and discussion topics prepared. We also came up with the time for the meeting which would be the third Wednesday of each month, and we set up the first meeting of the group.

Since that point we have been very impressed with the core group of members who have stepped up to take part in the group and really help improve their own and others’ craft. We put on a local Software Engineering 101 event in Cleveland where four HudsonSC members, @ardalis, @brendoneus, @kevinkuebler, and @ropog, took the time to discuss some topics and run the group in exercising their skills. The class was a great success and I, as a member of HudsonSC was proud to be a part of it.

The group is always looking for new members, so if you’re in the Northeast Ohio area, please drive to Hudson, Ohio once a month on the third Wednesday of the month. We prefer if you sign up, but you can just show up and we will not turn you away. Everyone is welcome.

Sign up for the August 2010 event now!

Look for more information on the group on the Hudson Software Craftsmanship site.

Fresh opinions, ideas, and technology are always welcome.

Thank you for a great year, HudsonSC!

User Group Fluidity

hudsonsc-logo Last year, Steve Smith, Rich Henning, and I started a local user group called HudsonSC. As a software craftsmanship group, we focus our efforts on improving one’s abilities as a developer. I’m not sure I can say enough about the need for developers to practice and learn to increase their abilities. Developers are providing a service in the form of software development. We should be proud of what we achieve through our efforts.

Our last meeting of our Software Craftsmanship group focused on the idea that software development is not the creation of things, but a service which when provided results in a new thing every time. We have this great topic and great meeting of the group thanks to a great idea and presentation from Michael Falanga. I will say that he is almost as good as Kevin Kuebler at keeping his talks short. Michael’s slides are available on SlideShare.

My favorite part of the talk was the comment that, “we’re not building cars. We are creating something new each time.” This I think is a very important point to make, and I agree with it. I don’t make the same thing every time. I am using techniques I’ve learned, and those aren’t the same techniques as anyone else. We all do things a little bit differently, and we’re all creating different implementations of the same kinds of things.

Our group is free-form and guided by our members. Sure, we have an agenda, but we hardly stick to it. It’s a rough outline for when things don’t spontaneously change.

At StirTrek I was discussing the group with Michael, and he was saying that he wanted the group to get back to the roots of software craftsmanship and discuss some of the finer points of the trade. The consensus of those around us at the time was that the programming exercises at the end of the events were great, but we should also focus more on the “why” we’re doing things the way we are.

If you’re user group isn’t discussing what you want, take the reins and guide it. It worked very well in this case as this meeting was one of the best our group has had.

Anyone can bring a talk to discuss in our open spaces or by giving a short talk, and I believe that this makes for a great user group. The occasional topic from a speaker is great, but I get a lot more out of discussing a topic than having someone tell me a topic. (This of course tells you that there was some debate on certain aspects of Michael’s talk.)

Take charge of your developer community and make it a better place for everyone involved. If you’re in the area, you should stop by HudsonSC and let us know what you want to discuss. We’re always looking for your great ideas.

HudsonSC January 2010 Recap

Last night we had a great HudsonSC meeting. People started showing up around 5:30, and I had the opportunity to meet and talk with a few new attendees during that time.

Lightning Talks

At around 6:00 we got things started. Kevin Kuebler started us off with an interesting talk on BDD where he showed some interesting code using MSpec. As usual, he was unable to keep his talk under 10 minutes. We will not fault him for that though, since he discussed the topic well and showed some cool code.

Following Kevin’s talk, we had a well-timed talked from Yasir Drabu about the Unit of Work pattern, which I in no way pressured him into giving at the last minute. Yasir let us know that he was currently implementing this, and he would show us the eventual implementation at a later meeting.

Open Spaces

Our open space discussions start at the same time pizza arrives, so people can sit around eating pizza and discussing interesting topics. The selected topics of the evening were “How to promote agile practices at your workplace” and “Automated build processes”.

I’ll defer to someone else about how the agile practices open space went, but I do believe the build processes discussion was interesting. Continuous integration, build automation scripts, and database change management were the hot topics of discussion among that group.

Coding Exercises

As usual we finished up the meeting with some time spent pair programming through some coding exercises. This time we took our second group attempt through our customized version of KataPotter.

We had a few interesting solutions to the exercise, and each one handled the optimization for getting the price down differently. They all seem to work effectively according to the unit tests. I know my solution was very different from the previous one I used to solve this exercise.

In Northeast Ohio? Come to HudsonSC the third Wednesday of each month in Hudson, Ohio.