Dear Friend,

Welcome to this issue of the Process Edition of The Coad Letter.

In this issue, special guest David Anderson will look at the value of a "Morning Roll Call" as part of the development process.

Naturally, David draws some attention to the SCRUM process, as this methodology heavily promotes using a daily meeting of sorts.

During my days running professional engineering services for a Department of Defense consultancy, we used daily "stand-up" meetings during the (harried) proposal preparation process. Here, the idea was to make the meetings as brief as possible (hence the standup part -- no getting comfortable in a big chair <g>). The meetings were designed to quickly keep everyone informed of progress, to highlight any problems, and to provide cross-team collaboration.

As you'll see from reading David's article (and references on SCRUM), these types of meetings can have very beneficial effects on a development project.

Let us know if you try similar meetings and what works/doesn't work for your team.

-- Jon Kern

PS #1. David Anderson is currently Director of Engineering at 4thpass, http://www.4thpass.com in Seattle, WA. You can reach David at david@thecoadletter.com. You'll be hearing more from David over the coming months, here in The Coad Letter: Process Edition.

PS #2. A note from Jon Kern: I continue working as an independent consultant, while I determine my next position of service in this world. Working on something truly great? Write me at jon@thecoadletter.com

PS #3. How do the industry's best application development tools stack up? Find out in a free independent lab report by Hurwitz Group. Learn more about why Hurwitz believes that Together ControlCenter's usability and technical capabilities are superior to their competition. http://www.togethersoft.com/hurwitz/summary.jsp?c=146

Morning Roll Call

by David Anderson, david@thecoadletter.com

The "morning roll call" was a name that I gave to an FDD process enhancement I introduced 15 months ago, with my development team at a large mobile phone company's Internet business unit.

This is not a new technique, in fact I had used it before - see footnote #1. It is also a known technique in at least one other Agile Process method - Scrum, see footnote #2.

The project we were building was the small end of medium in size - about 10 people, 3 months, for the development stage. About half way into the project our FDD Features Complete metric was telling us we were going to be late. We had been dependent on another team delivering infrastructure and they hadn't delivered. We had lots of Features blocked. We needed to run fast to catch up. It was a highly visible project with lots of political capital at play.

For some of the team it was their first FDD project. The others had done only 1 - the previous quarter. So we had new process, new technology and some ambitious technical objectives. Getting the project back on track was going to take an extra special effort. How could I focus them, raise the pulse of the project, and get that extra performance?

The answer was the Morning Roll Call. I modeled this after the opening sequence in an old, American, TV police drama, "Hill Street Blues", where the sergeant would go over the recent events and allocate patrols and tasks for the day. I was hopeful that this would focus the team, and squeeze out any accidental slack which might have crept in during the early part of the project. The best kind of managers offer coaching, direction, leadership, support, and then get out of the way and let their staff show off their ability. So, the precise definition of Morning Roll Call was developed by my team. Here is a brief outline of how it worked.

Morning Roll Call Process

• 9:15am Morning Roll Call - all hands on the project, attendance is mandatory. [ 9:15 was chosen as an acceptable compromise. A few team members had to get in a little earlier than usual. Everyone else was already there. Some started at 7 am. The idea was to be as early in the day as was reasonable and still get full attendance. ]
• The meeting was a "huddle" (or standup meeting, so that people did not get too comfortable and spend more time than was necessary). It as held in an open area near the developers' cubes. The manager was not present. [ Actually, the team often used my office. I wasn't there - purposefully. I always had other meetings to attend. ]
• Duration 15 minutes - maximum 30 minutes - never longer.
• The Norms [#1] :- Honor the rules - turn up on time, keep focused, take lengthy issues and resolve them outside of the meeting, keep things moving.
• The meeting was chaired by the Chief Programmer, or the most senior of several Chief Programmers.
• In the event that the CP was absent, the Process Coach (or Mentor) would run the meeting. [ The role of the Process Coach in the adoption of FDD across a team or organization may be the subject of a future Coad Letter. ]
• Each CP would run through the Features on the current Chief Programmer Worksheet. Developers were asked for: Features they had completed since the last meeting; status of Features in progress; when they expected to finish and if they needed more work to do. The whole team could make an assessment of whether each Feature was on track.
• Developers were encouraged to ask for help, if needed. Sometimes the team would suggest that they might need help. If help was needed, a more senior and experienced developer was assigned to help out for that day.
• Technical discussion and debate about solutions was banned. The whole team would see to it that the roll call only took 15 minutes. Developers wanted to get the meeting over so that they could get to "real" work. Colleagues were asked to take debates off-line.
• Issues with requirements, environments, test plans or anything else out of the immediate control of the developers were noted by the CP who would have a separate discussion afterwards with the Project Manager / Project Secretary to log the issue. The PM would be responsible for chasing down the issue or assigning it to someone. When closure occurred the CP would be informed and work could restart on that Feature.
• Developers who expected to finish current work that day or next, would be allocated more work. They always knew a day or two in advance what was coming.
  

Did it work?

Yes, it did. A project which initially looked as if it was 50% - 100% behind schedule was delivered into System Test close to schedule. Face was saved.

How big does it scale?

Obviously a Morning Roll Call on a very large project would be impractical. So, how large is practical for a Morning Roll Call? I would suggest that the team working on a single Major Feature Set, meets together for a Morning Roll Call. At most, you could stretch this to two Major Feature Sets [See Footnote #3]. What if some developers need to be at more than one Morning Roll Call? They have a clash because they are working across Feature Teams which are working on different Major Feature Sets. There is a simple solution - stagger the start times of the Morning Roll Calls for each Major Feature Set where a schedule clash occurs.

I have seen Morning Roll Call successful with up to 20 or so people. Typically, we used it with around 10 to 12 people. If you have more than one Major Feature Set but less than 12 people, it is perfectly reasonable just to hold a single meeting. Remember the ground rule - 15 minutes, maximum 30 minutes.

When to Use Morning Roll Call and Why

Morning Roll Call was initially used as a process for recovery because the FDD Features Complete metric was suggesting that the project was going to be late. It served the purpose of keeping people honest and making them accountable for their work. They had to stand in front of their colleagues each morning, look them in the eye, and state how they were getting along with their piece. The process was stopped about two weeks after the hand over to System Test, as the bug count dropped off and the work on the project wound down.

Morning Roll Call served a second purpose. Some of the team were new to FDD. They were also new to several technologies such as XML and XSL. They had a lot to learn all at once. Morning Roll Call helped them to get over the hump with FDD and gave them a forum to ask for help on technical issues such as XSL.

Since the end of this project, the team has found that Morning Roll Call is useful for team communication. They have adopted it as a regular process. Morning Roll Call is now a daily part of life on an FDD project.

Footnote #1 - Why I hadn't used a roll call meeting for over 3 years?

So why did it work this time? I believe that an underlying process structure is required on which to hang a roll call meeting. In the early days in Singapore, we were struggling to define process and build adoption. FDD was emerging but did not fully exist. There was no daily, automated Feature tracking going on. When you have metrics, fine grained task definition and automated reliable tracking, I believe that the roll call meeting has a focus. It is objective. Without a fine grained, iterative process, a roll call meeting is subjective and loses its bite. Hence, the reason it was previously ineffective.

Footnote #2 - Scrum

I have only recently learned about the Agile method known as Scrum. Scrum puts a daily roll call style meeting, which is referred to as "the scrum" at the core of its process. [ See http://www.controlchaos.com/ ] . The scrum is a ritual during a 30 day development cycle called a "Sprint". It appears that Scrum bears a lot of similarity with FDD. A "Sprint" is similar to a Chief Programmer Worksheet but the cycle time in Scrum is 30 days, as opposed to 2 weeks or less in FDD. Scrum was a name adopted to mean "a process for bringing the ball back into play". It therefore appears to have been a method born out of a need to recover projects which had fallen behind. Precisely the reason for adopting Morning Roll Call with FDD. With the addition of Morning Roll Call, FDD begins to show a strong similarity to Scrum, at the developer level.

Footnote #3 - Scale of Morning Roll Call and differences from Scrum

In their book explaining Scrum [#4], Schwaber and Beedle suggest that it is possible to have different shells of Scrums. They talk of a Scrum of Scrums, and even a Scrum of Scrum of Scrums. The Scrum of Scrums is used to gather project status on larger projects. The Scrum of Scrum of Scrums is used to report to senior management or executives.

I do not believe that FDD requires these shells of Morning Roll Calls. I believe that we must look to the purpose of the Morning Roll Call, which is: to keep the development running efficiently; to keep programmers busy; to identify issues early; to provide expert assistance where required. Morning Roll Call is a tool for the Chief Programmer. It is intended to avoid down time in the fine grain of Feature development. It is not needed at higher levels such as project management.

FDD is grounded in the notion of automated progress tracking. Where automation is not possible, a weekly meeting with the Project Secretary is held for Chief Programmers to manually report progress. It is essential to see this as a manual step, being used to supplement a deficiency in automation. With automation FDD projects can be tracked daily. Without automation, weekly or twice weekly will suffice.

In FDD, Morning Roll Call is used only to avoid downtime and inefficiency at the coal face where the code is cut.

Acknowledgments

I would like to thank my old team at Sprintpcs.com for their contribution to this article. My Chief Programmers: Neil Lowrey; Dan Vacanti; Sei Ng; and Chris Bock. My Process Coach: Vahid Nabavizadeh. Together they developed the Morning Roll Call enhancement for FDD and have used it with great success, on many projects, over the last 15 months.

Thanks also to Jon Kern and Stephen Palmer for their review comments which contributed to making this a better article.

David Anderson

References

 

Ref #1

The Coad Letter #40 - Lessons Learned From Fred, Peter Coad, 1997

Ref #2

Peter Coad, Eric Lefebvre and Jeff De Luca
Java Modeling in Color with UML : Enterprise Components and Process
Prentice Hall, 1999.

Ref #3

CLS - Commercial Lending System, a.k.a "The Singapore Project". The original name of a project conducted in Singapore between 1997 and 1999, at a large locally owned bank. During this project, Jeff De Luca, Peter Coad, Stephen Palmer, David J. Anderson, Paul Szego and Phil Bradley all worked together. It was the first project to use UML Modeling in Color with Archetypes and Feature Driven Development.

Ref #4

Ken Schwaber and Mike Beedle
Agile Software Development with Scrum
Prentice Hall, 2002.

 

---

The Coad Letter is a service provided by Peter Coad and colleagues.
Feel free to share this issue with others.