By David Mosley Part of DDC-I's commitment to our customers is to continue to offering improvements and enhancements to our products. With that in mind, we are delighted to announce this new release which offers many improvements and enhancements that we hope will be of value to each program using the DACS product line. The following is a list of some of the enhancements:
For more information about this and other releases, contact DDC-I. The Benefit of Frequent, Small Meetings By Linda Rising In last month’s article, I described, at a very high level, the current agile software development methods and promised that this month I would tell you more about the single component of one process that I considered the most valuable. In the meantime, there’s been another development that I can share with those of you who are keeping up with the agile methods. The proponents of these methods have banded together to form an organization called The Agile Alliance. http://www.agilealliance.org/ That group of seventeen has expanded and will form the Agile Alliance Non Profit Organization, AANPO. I have been asked to serve on the board for AANPO. We have had our first teleconference and have started to work on a set of by-laws and a constitution. For any readers interested in staying up on this, you can read more on the Agile Wiki (a writeable web site) http://www.objectmentor.com/agilenpo/wiki/agilewiki.py The agile process I am most familiar with, and the only one with which I have actual experience, is Scrum. I have co-authored a paper with Norm Janoff about our experiences at AG Communication Systems, a medium-sized telecommunications company in Phoenix, AZ. [Janoff+00]. There is considerable overlap among the many agile processes practiced today and they seem to be becoming more alike. I think this is good. In the beginning there were some clear differences. One component that set Scrum apart—the one that provided the most benefit for our teams—was the frequent, small meeting. No one likes meetings, least of all software developers, who are already under a great deal of schedule pressure. The only reason why many of the teams at AG agreed to sign up for a trial with Scrum and the prospect of more meetings—was sheer desperation. They knew they were in trouble and they were also astute enough to know that communication was a contributing factor. Even though most engineers are introverts, that doesn’t mean they aren’t aware of the problems they have interacting with each other. Every engineer at AG had been given a Myers-Briggs personality test and over 75% were INTJs [Meyers]. Scrum offered a clear process they could follow. When a meeting is part of the ceremony, it makes it easier to go along with it. It also helped that the meetings were defined as short (less than 30 minutes). Scrum defines an initial planning phase followed by a series of short development phases or Sprints that deliver the product incrementally. A Sprint typically lasts 1-4 weeks. During a Sprint, the team holds frequent Scrum meetings. Typically teams meet frequently—daily or every other day. The meetings involve all developers, including those who telecommute. This solved a problem that AG had since many teams had members who lived in different parts of the country, some in different time zones. Frequent, small meetings allowed the team to "synch up" and allowed in-house members to know exactly what remote team members had accomplished. During a Scrum meeting, only one thing happens: the Scrum Master (usually the team leader) asks three questions of each team member:
The Scrum Meeting usually lasts 15 minutes, and occasionally longer but never more than 30-minutes. This provides enough time to address obstacles, but does not allow time to brainstorm solutions. All problem-solving discussion is held outside the meeting with only those involved participating. The goals of the Scrum meeting include:
Since I attended many of the Scrum meetings, it was always an eye-opening experience to see how many developers had a tendency to wander off in the weeds—intent on solving some problem they felt was very important but, even if solved, would not reduce the backlog. In many situations, the Scrum Master had to corral these cowboys and convince them that their very important problem was not going to help the team make progress. Sometimes solving these very important problems involved creating a homegrown tool that would (in the eyes of its creator) solve a recurring problem for teams in the future. It was astounding to see how many closet tool writers we had and how many experienced old hands underestimated the effort it would take to produce a truly useful tool for cross-project use. It’s no secret that most developers are addicted to work. Workaholics can ignore what’s best for the team or organization by resisting the kinds of activities that create group bonding: teamwork, sharing feelings, and playing and celebrating together. Those putting in long hours look so virtuous and seem to be getting so much done that’s it hard to disturb them. Many cultures reward such behavior and tend to ignore its downside. While these addicts look productive, they often waste time on less important tasks because they are so intent on the things they feel are important that they have difficulty setting priorities that best serve the larger whole. [Shaffer+93:241] The following case studies report a couple of our successes with frequent, small meetings in Scrum. A-Team This team had a problematic history. It was created as a support team, made up of people from several projects to create an integrated set of tools. It was unclear where this team should be in the organizational structure and it was passed around from one department to another. Each new "home" provided a new team leader and a new management hierarchy. The members of the team were experienced, tough, independent thinkers, used to going their own way and taking on hard problems and solving them alone. Unfortunately, the team was going nowhere fast. It was producing nothing and kept losing ground each time it was re-org’d. Finally, it came to rest in a new organization with a new team lead who really cared about the team and wanted it to succeed. As his first act of leadership, the new team lead called for a project checkup (a project retrospective held before the end of the project). Several problems surfaced during the checkup, most of them related to poor communication. Checkups and postmortems can uncover a lot of deeply felt emotion, especially if the team members are frustrated by more than the expected change in requirements, too many lost team members, or other disturbing events. The word "chaos" was used a lot. Norm and I offered to give a short Scrum presentation—not a usual part of a checkup or postmortem—because the team was asking for help. They were not especially enthusiastic about using Scrum but they decided to pilot a 1-month Sprint. At this point, the team lead left for a month vacation. Daily meetings seemed too much to tackle, so they set a meeting schedule of Monday/Wednesday/Friday one week, followed by Tuesday/Thursday the next week. I remember the very first meeting. We had to round up the team members who grumbled all the way to the cafeteria, "I don’t have time for this! I’ve got work to do!" Once we started around the table, problems quickly surfaced. The first speaker said, "I’ve been having trouble getting X to work." Another team member responded, "What! I didn’t know you were working with X! I thought I was doing that! We need to talk after this meeting!" Another problem popped up. "I’ve had trouble finding someone who knows about Y." A helpful offer, "Hey! I used to work with Y. I can help you with that. Come on over to my office after the meeting." At the next meeting, most people were there early and eager to learn what the others were doing. It was a 180-degree turnaround from reluctance to enthusiasm. These people could immediately see the benefits and what it meant for their project. The team began to grow together and display increasing involvement in and delight with others’ successes. The team completed a successful Sprint with the planned components delivered on time. The pilot was declared a success and, as far as I know, this team is still enthusiastically following Scrum. What was astounding to me was to see this very dysfunctional team begin to cooperate almost immediately. The changes happened visibly—before our eyes. When one team member shared an obstacle in the Scrum meeting, the resources of the entire team were brought to bear on that problem. The entire team immediately owned every problem. Detailed problem solving does not happen in the meeting, of course, only an offer of help and an agreement to meet after the Scrum Meeting. For example, a team member would say, "I ran into a problem." Typical responses would be: "I had that problem a couple of weeks ago. I can help with that. Let's talk off-line." or "I know who is working in that area. I'll help you get in touch with them." or "I'm having the same problem myself. Let's get together after the meeting and talk about it." I kept thinking that if the Scrum meeting had not taken place, the person with the problem would have struggled long and hard before asking for help and would possibly have created a workaround or another tool that would have contributed nothing to the list of required deliverables. The Scrum meeting allows a developer to "Ask for Help," a fundamental pattern in successful teams that seems to be almost impossible for some developers to apply. [McCarthy+01] The team lead came back from vacation as the pilot was ending. His comment to us was, "I can’t believe it’s the same team." In one short month, Scrum (the frequent, small meetings in my humble opinion) had turned this team around. They were producing quality deliverables on time that their customers were happy to receive. Some comments from the team lead at the end of the pilot:
Our biggest learning from this pilot came in the definition of the Scrum Master's task. We originally thought that this role would be hard to fill—someone, who could facilitate a tight meeting, keep everyone on track and solve problems on the fly. What the A-Team experience taught us is that the team solves the problems—or most of them. The team still needs the guidance of a capable Scrum Master but most issues are addressed and resolved by the team. A successful Scrum Master must be a good facilitator and allow the team to solve the problems—not jump in and solve all the problems that arise. B-Team We tried applying frequent, small meetings to a testing team working on preliminary testing and bug fixing for a B-Team feature. The team was scheduled for four testing times in eight days, so they planned a Scrum meeting before each test time. The test team was on the critical path for delivery. It was imperative that the feature be delivered on time. Testers work strange hours and team members don’t often see one another or communicate plans and results for a test session. The team members were experienced hands used to solving their own problems. Sometimes it caused problems when loads were not ready or fixes had been added but no one had informed the test group. During the meetings, team members could ensure that the proper load was used for the next scheduled test time. They re-defined some testing procedures to make things go faster. The meetings allowed all the testers to hear what was planned and volunteer to work the next test time. The meeting also served to remind everyone of current load problems and events scheduled for the next day. Decisions about the kind of testing to perform in the next test time were made by the group instead of just the tester who worked that time. Fixes that had been added were announced to the group. Information was always sent out via e-mail but seemed to always have been missed by someone on the team. Team members were on so many e-mail distribution lists that their mailboxes were full. They received dozens of e-mails a day and could not keep up with them, so they usually didn’t try. As a result, unless they happened to see someone who could remind them of an update, they sometimes went about their work without knowing critical information. The meetings served to keep everyone together. Important issues were called to everyone's attention. The latest load schedule was announced. Sometimes no one was sure of the load status or other essential data. During one meeting, the team lead had to make a phone call to help decide whether to go ahead with the next scheduled test time. Without the Scrum meeting, without the phone call, without the information, the tester would have worked an entire shift on an obsolete load—a complete waste of time. We saw the regularly scheduled meeting provide the team with an efficient way to share information and track progress. The team met its goal—the feature was ready for integration testing at the end of the Sprint. In Tom DeMarco’s novel, The Deadline, he addresses "Project Sociology." He observes that projects have need of ceremony and suggests that projects use ceremony to focus attention on project goals and ideals. [DeMarco97:275] This precept is addressed by the frequent, small Scrum meetings. The agenda is the same for each meeting: ask the three questions of each participant. This small ceremony is the way most teams at AG began each day after they adopted Scrum. If you were standing on the second floor of the building where product development took place, you would see clusters of teams—GPU huddling in one corner, the IN group in another. Small groups of heads gathering between 8 and 9 o’clock. Team members standing with a cup of coffee, listening intently to the answers to the questions and then, "poof" the meeting is over and everyone is back in her office, working with a clear sense of the direction the team was heading. A good way to start the day. References [DeMarco97] DeMarco, T. The Deadline, Dorset House Publishing, 1997. [Janoff+00] Janoff, N. and L. Rising, "The Scrum Software Development Process for Small Teams," IEEE Software, July-August 2000, 26-32. [McCarthy+01] McCarthy, J. and M. McCarthy, Software for Your Head, Addison-Wesley, 2001. [Meyers] There’s a lot of information on personality typing. The following is a good summary: http://www.typelogic.com/faq.html [Shaffer+93] Shaffer, C.R. and K. Anundsen, Creating Community Anywhere, Penguin Putnam, Inc., 1993. Tech Talk By Johan P. Olmütz Nielsen In SCORE the command list_unit is used to display information about the Ada compilation units which have been compiled into a program library. The list_unit command is equivalent to the SHOW command in the DACS PLU. One thing that may be confusing when moving from DACS to SCORE is that the SHOW command (and indeed the PLU as a whole) has a SCOPE option which allows the user to choose whether only to look (using DACS terms) in the current sublibrary or to look at the whole program library (all sublibraries from the current sublibrary to the root sublibrary) whereas list_unit may seem not to offer the same possibility. But of course SCORE allows you to do the same thing! Actually SCORE provides a more fine grained control than DACS. The program library path specified to list_unit decides which libraries (in SCORE terms) will be processed. Imagine that you have a three level deep library structure
We assume that the default path of Stem is Root and the default path of Branch is Stem. To list information about all units in your libraries (corresponding to the DACS PLU command SHOW with GLOBAL scope) you rely on the default library path built into the libraries and use the command
To list information about the units in Branch alone (corresponding to the DACS PLU command SHOW with LOCAL scope) you override the default library path built into the libraries with a single element path and use the command
To list information about the units in both Branch and Stem but not in Root (this is what older versions of DACS did not support) you override the default library path built into the libraries with a path listing the individual libraries and use the command
|