There are many different kinds of meetings when one follows an Agile process. Each meeting has a particular purpose, focus, and outcome. The various Agile meetings are nested by their time horizon: Vision, Product, Release, Iteration, and Standup.
Sometimes a topic that would be best covered in another kind of meeting intrudes into your current meeting. When this happens we’ve got ourselves a leaky meeting.
Noticing that you are in a leaky meeting is an excellent diagnostic tool: most likely you’ve shortchanged some other activity that you needed to attend to prior to your current meeting.
Some common scenarios that indicate a leaky meeting:
Scenario 1: Imagine that you are in a Sprint planning meeting and your Product Owner says that the business would really like this feature in this Sprint. You’re sure that you’ve already decided that that that feature belongs in the next release.
Scenario 2: Imagine that you are in a daily standup meeting and someone on the team says that they’re not sure why you are working on a particular story.
Scenario 3: Imagine that you are in a Produce Demo meeting and one of the business stakeholders wonders where the release is headed.
Whenever you’re in one of the standard Agile meetings and there seems to be a lack of focus see if you can detect a leaky meeting. If that is happening chances are there is some other activity that needs to be performed so that the topic that is leaking into your meeting can get covered off elsewhere.
October 9th, 2013 in
Here are my notes from a series of Study Group meeting where our group was studying Working Effectively with Legacy Code by Michael Feathers. I described the different Study Group roles in an earlier post.
Introductions: Does everyone know everyone else?
Ice-breaker Question: What do you want to get out of this Study Group?
Time: How long per meeting?
Location: Where can we have our meetings?
Frequency: Shall we meet every 1 or 2 weeks?
Pace: How many pages per meeting? How much time per reading? Do we want to be speedy to get through the material or do we want to go deep?
Focus: To what extent do we want to stick to the text of the reading during our meeting?
Expectations: Is it okay to come to the meeting if you haven’t completed the reading?
Roles: Shall we choose to follow the suggested roles?
Assigned Reading: Preface, Introduction, and Part I (Chapters 1-5).
Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.
- Does it make sense to create locked down APIs? For example, final classes and concrete classes hidden behind factories?
- How does duplicate code affect our ability to preserve existing behavior? To add new behavior?
- What dependencies in our current code base are going to give us the most problems?
- Legacy Code (xvi)
- Edit and Pray (9)
- Unit Test (14)
- The Legacy Code Change Algorithm (18)
- Sensing and Separation (21)
- Seams (30)
- Mock Objects (47)
Read the rest of this entry »
February 27th, 2011 in
I thought I’d share my response to this e-mail from a colleague:
I find myself having huge arguments with someone at work about how to write unit tests. In particular, things like having ifs and loops in tests. I am wondering if you could send me resources about the format of writing unit tests.
The definitive resource is xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. I’ve often used the book to influence people: if you don’t agree right now I will club you with this book that I’m holding. Kidding.
Most of the book is online. In the part of the book that describes test smells, Meszaros calls out Conditional Test Logic as a code test smell. There is a section of the Result Verification chapter that describes how to Avoid Conditional Test Logic.
I prefer to write test code that is straight line code: no conditional logic whatsoever. I suggest you adopt this guideline and see how it works for you. I would be interested in seeing any of your tests where you felt that conditional logic was needed.
January 30th, 2011 in
Eclipse is the IDE that I use for most of my software development. I’m very comfortable using Eclipse. I’ve learnt many shortcuts, techniques, and tricks that allow me to create code with very little friction between my thoughts and what I see onscreen.
I’ve noticed that not everyone I pair with uses Eclipse like I do. So I share what I know whenever I pair. In return I’m always picking up new shortcuts, techniques, and tricks.
If you use Eclipse and you don’t have a pairing partner to teach you shortcuts, techniques, and tricks then you might want to look at Eclipse on E. I highly recommend it.
September 21st, 2010 in
I’m introducing unit testing to a group of developers that are new to unit testing.
Here is the list of stories that I’m using as a guide:
- As a developer I need to run all the unit tests before checking in.
- As a developer I need to understand where unit testing fits into my day-to-day work.
- As a developer I need to know what counts as a unit test.
- As a developer I need some reference tests and example tests to get me started.
- As a developer I need to understand what tools to use and how to use them.
- As a developer I need to see code coverage for my unit tests.
- As a build support person I need to configure the build to run all the unit tests.
- As a development manager I need to see the that unit tests are being created.
- As a developer or a development manager I need to see when a build has a failing unit test.
Supporting learning is necessary feature of any agile transition. I always advocate the creation of one or more study groups.
When my kids were in middle school they learned a technique for reading and discussing a book called a Literature Circle. They taught me the technique and I’ve used it to create a study group work agreement that I’d like to share. This particular work agreement was for a study group that was reading Working Effectively with Legacy Code by Michael Feathers. Feel free to adapt it for your own study group.
Study Group Work Agreement
All meetings will be scheduled for Tuesdays from 12:30 to 2:00. During the first 30 minutes we will eat lunch together. All members of the Study Group are expected to be present by 1:00. If we all arrive earlier we may choose to start the formal part of the meeting prior to 1:00.
To amplify our effectiveness we have chosen to assign the following roles: Discussion Director, Code Connector, Key Concept Illustrator, and Technical Vocabulary Enricher. Roles will be rotated each meeting and may be assigned to more than one participant. We won’t be assigning the typical meeting roles of Facilitator, Timekeeper, and Scribe—it is everyone’s responsibility to discuss the material in a respectful and timely manner.
As Discussion Director your responsibility is to develop a list of questions that your group might want to discuss about the material. Don’t worry about the small details: your task is to help the group talk over the big ideas in the material and share their thoughts. You are expected to post your questions to the study group wiki.
As Code Connector your responsibility is to choose one or more examples of code from your respective project that relates to the material. The Code Connector is also responsible for making positive changes to their project code base using techniques from the material just covered and to present their results at the next meeting.
As Key Concept Illustrator your responsibility is to choose a few special sections of the material to talk over. The idea is to help members of the group remember one or more the important concepts from the material. Once you have made your choices decide how to share the material. You might draw a UML diagram on a white board or tell a relevant story from your own work experience.
As Technical Vocabulary Enricher your responsibility is to be on the lookout for especially important technical words that your group needs to understand such as the Expose Static Method dependency breaking technique. Other examples from Working Effectively with Legacy Code are Sprout Method and Effect Sketches.
In addition to these roles you may also want to assign the role of Snack Supplier. As Snack Supplier your responsibility is to provide your study group members with a small inexpensive snack. For example, during the study group pilot the members of the study group were treated to Maple Syrup Pie and Lindt chocolates.
Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising
Pools of Insight: A Pattern Language for Study Groups by Joshua Kerievsky
Learning to write valuable unit tests is tough for any team. The first hurdle is to create consensus on the team as to what exactly counts as a unit test.
The two definitions that I always share with any team that I’m coaching are from Michael Feathers, A Set of Unit Testing Rules, and Mike Hill, They’re Called Microtests.
Blogger have changed their infrastructure and no longer support ftp hosting.
Please be patient while I transfer my old blog posts.
Can you believe that I passed up a beautiful August weekend, at a cottage on a pristine lake just outside Algonquin Park, to spend the day back in the hot, humid city writing code for 45 minutes at a time and immediately throwing the code away? I can hardly believe it myself.
The code retreat started at 8:30am, bright and early, on Saturday, August 8. The retreat was hosted by Mike DiBernardo at the PlateSpin office and led by Joe (J.B.) Rainsberger and Corey Haines.
Corey needed a place to stay in Toronto so I offered him a place chez moi (lots of room because the rest of my family was, naturally, at the cottage swimming in the pristine lake). Early Saturday morning Corey and I took the Red Rocket from my place in Kensington Market to Platespin.
After some bagels and coffee, Corey and Joe introduced us participants to the structure of the code retreat: work in focused sessions of 45 minutes; use Java because it is a straight forward language that most everyone understands; develop the code in pairs (or triples); switch pairs after each session; pick at least one thing as the learning objective for each session; and, finally, throw the code away after each session.
What? Throw away the code after each session? Delete the code from version control too?
Yep. I found it quite difficult to throw away the first session’s code. However, by the end of the code retreat I was happily throwing away my code.
The goal of a code retreat is to practice programming rather than to accomplish a programming task. The structure of the code retreat cleverly supported this goal in the following ways:
- Starting as 8:30 in the morning on a summer Saturday guarantees only keen participants who wanted to learn;
- 45 minutes is too short to complete an implementation of Conways’s Game of Life;
- While one participant characterized Java as a “baby” language, I think the choice was a good one because we didn’t spend a whole lot of time getting past basic understanding which we might have done had we chosen some other language;
- Pairing and frequent pair switching are practices that emphasise learning rather than immediate productivity;
- Because every pair was asked to choose one learning goal for each session the programming in each session felt like deliberate practice;
- Throwing away the code each time was liberating because I could start a session with a new pair without either one of us having to understand the code that we had just written in the previous session.
Here are some of the deliberate learning goals that my pairs and I chose: don’t use if statements, work inside out by implementing the survival rules for a single cell, write tests using mock objects, and work outside in by writing tests using a DSL to describe the transition from one generation to the next.
Most of the code that I wrote with my pair was awkward and not worth keeping. But that is okay. As Chad Fowler writes in his book, The Passionate Programmer, if I sit down to practice coding and nothing but elegant code comes out, I’m probably sitting near the “center” of my current capabilities instead of the edges, where a good practice session should place me.
The code retreat reminded me how important it is to make time for deliberate practice. That is, make time where it is okay to ignore the strong pull of completing tasks and instead give myself a chance to experiment, learn, and practice my craft.
September 1st, 2009 in
I’ve been reading and enjoying these beautiful O’Reilly books: Beautiful Architecture, Beautiful Code, and Beautiful Teams. I have yet to read these other titles from the collection: Beautiful Data, Beautiful Security, and Beautiful Testing.
Those books will have to wait because the O’Reilly book that I’m reading right now is Masterminds of Programming. I want to share something that Tom Love wrote on page 248:
I just handed out to some of my friends this week a big pile of buttons with the word REQUIREMENTS and a red slash through it like a European road sign. On the back of the button are 14 acceptable alternatives to that word. Lots of discussions go on between individuals or between groups of the form of “I couldn’t do this work because you didn’t give me the requirements yet,” or “We need to have a group of people that goes out and gathers the requirements for this new system.”
The term is simply too imprecise. You need to have more precise terms as an alternative. On a big project that I’ve been involved in we have imposed a requirements tax. If anybody uses the word “requirements” standalone, they have to add $2.00 to the entertainment fund. If they want to talk about use cases, or if they want to talk about story cards, or they want to talk about performance metrics, or they want to talk about business cases or business process models, those are all acceptable terms. They don’t incur a tax, because now if you say, “I need to have the use cases or the functional specification, or a mockup of the application that needs to be developed,” that’s a precise request.
Let it be known that I will no longer use the word “requirements” standalone. If you catch me, I’ll buy you a beer. Now if you use the word “requirements” standalone, I’m likely to just get angry. Dear reader, you have been warned.
August 26th, 2009 in